Share
Report
164We have a pretty good process for automation on our team. We now have a number of desktop bots that are built for unattended runs. Typically, the desktop flow is made with an input variable to supply the exact SQL Query for the work to handle. That query is run by the desktop flow, return records are looped through and on each record some subflow will do the prescribed actions to do the necessary automation work.
A cloud flow will get created providing the scheduling and pass in the query. (Incidentally, passing in the query is really helpful so you don't have to edit the desktop flow when the business changes some basic details that just need a tweak to the where clause.) So on occasion, we find a bot hung up. Maybe the flow typically run from 7pm for 1-3 hours. When I start work, I see one of my machines is still running a job. I can remote into that machine using the same user configured. I see the browser hung up on something. Sometimes it is something I can spot that I can improve error handling for. Sometimes it is just something we get with this.
So how to make it better? One of our team members started adding to the cloud flow, add a parallel path, in the path he adds a timer for longer than you would expect this process to take. Then send a message, more wait, then use a terminate action to kill the desktop flow.
The problem I have with that is the flow usually has some logging of summary statistics at the end which wont run. If I see the message, log on to that stuck machine, close the browser, included error handling finishes up and the bot logs stuff and closes.
I don't see anyway to have the desktop flow itself catch anything stuck for too long. I don't always have time to find the one-in-a-million weird spots it hangs up and add some extra error handling. I would love some universal catch where, if it is on an action step that doesn't have it's own timeout parameter, a universal one can kick off a subflow after being stuck for x seconds.
All responses (
Answers (
