Skip to main content
Question

Need insight on my approach!

  • May 19, 2026
  • 2 replies
  • 18 views
M

Hey, Good Morning!

 

Couple of days ago, I asked about live logging feature on AA. I kind of found a workaround on how to view live logs (especially business). Here’s my approach, let me know if there’s a way to improve it.

 

  1. We trigger 3 bots simultaneously, in the pool of 6 machines via Jenkins.
  2. Each bot needs to create a logs file for the current run, ex - Bot_1_machine_1_timestamp.txt
  3. This particular file will be created in a shared folder, accessible to all the bots, in all 6 machines.
  4. Once this is created, an email will be sent to business with the below content, where they can click the PowerShell file, which opens the terminal with live logging.

!--scriptorstartfragment-->

@echo off

powershell -command "Get-Content '\\SharedDrive\Logs\Bot_1_machine_1_timestamp.txt' -Wait"

pause!--scriptorendfragment-->

So, any changes in the file, like appending of txt, will be immediately reflected in the terminal, so that business can view it.

 

I also have a couple of questions.

  1. Does writing to the file present in shared folder create any delay, big enough to notice?

I’ll be using AA’s activity - “Write log to file”, where the log would be in the form of JSON. The behavior of the above activity will be reliable enough to proceed further? (I mean, graceful closing of file, after writing the logs each time, without creating “file in use” error).

 

Thanks!

    2 replies

    Lu.Hunnicutt
    Pathfinder Community Team
    Forum|alt.badge.img+9
    • Lu.Hunnicutt
    • Pathfinder Community Team
    • May 20, 2026

    ​@Vatsy

     ​@ChanduMohammad_S ​

    ​@Tamil Arasu10 

    Let's Connect! www.linkedin.com/in/lu-hunnicutt-1290jan
    Tamil Arasu10
    Most Valuable Pathfinder
    Forum|alt.badge.img+6
    • Tamil Arasu10Most Valuable Pathfinder
    • Most Valuable Pathfinder
    • May 20, 2026

    Hi ​@ManojYadav,

    How to make it robust 

    Option A — Keep your design but reduce write frequency

    • Log meaningful milestones (start/end/each portal action)
    • Avoid writing for every tiny step unless needed

    Option B — Best reliability pattern: local log + periodic copy/append to share

    This is the most resilient approach in enterprise environments:

    Bot writes to: C:\BotLogs\run.txt (fast, no network dependency)

    • Every 5–10 seconds, bot appends new content to the shared file (or copies if small)
    • Business watches the shared file

    OR

    Keep your current approach, but:

    1. Use -Tail 50 (instant open) "Get-Content '\\SharedDrive\Logs\Bot_1_machine_1_timestamp.txt' -Wait -Tail 50"!--scriptorendfragment-->!--scriptorstartfragment-->
    2. Ensure one JSON per line
    3. Add heartbeat every ~60 seconds
    4. (Optional) Write locally + sync if you expect network instability

     

    Does writing to a file in a shared folder create any noticeable delay?

    Usually not noticeable (typically milliseconds), but it can be noticeable if:

    • the network share is slow / congested
    • antivirus or DLP scans the file on write
    • the share is remote (VPN / cross-site)
    • the bot writes very frequently (e.g., multiple lines per second)

    What you’ll observe in practice:

    • For human “live viewing”, even a 200–500 ms delay feels “live enough.”
    • If you log very chatty (hundreds of writes/minute), SMB + scanning overhead can add lag.

    Best practice to reduce latency:

    • Batch writes (write every 1–2 seconds or every X events) instead of every micro-step.
    • Or write locally and “sync/append” periodically (more on that below).

     

    Is AA A360 “Write log to file” reliable enough? Will it gracefully close the file each time without “file in use” errors?

    In most cases: Yes, it’s reliable enough.

    Most “write log to file” style activities are implemented as:

    • open file (append)
    • write line
    • close file

    That means file locks are usually very brief, and readers like  Get-Content -wait  can still read as the file grows.

    When “file in use” can happen

    You can still hit “file in use” issues if:

    1. Multiple processes write to the same file at the same time
      • (You avoided this by using per-bot/per-machine/per-run files — excellent.)
    2. The activity holds the handle open longer than expected (rare, but can happen depending on implementation)
    3. Endpoint security scanning locks the file briefly after each write
    4. The share occasionally “stalls” and AA retries writes

    I hope this helps..

    _Tamil_
    Terms & ConditionsAccessibility statement