What happens if bot is still running and Orchestrator tries to trigger the same bot again?

Help Orchestrator
1

Hi,

We have a unattended workflow that interacts with an app and it can take up to 30 seconds to process a file, so we we schedule to bot to be triggered every 5 minutes and there are a couple of files to process, it would take a minute to process them and it would remain idle for 4 minutes before being triggered once again

If we had 100 files to process, it could take 50 minutes so what would happen in this scenario?

  1. Does orchestrator try to launch another instance of the bot?
  2. Does it terminate the existing bot running and create a new instance?
  3. Does Orchestrator send the “Stop” command and the bot finishes processing the current transaction and then it closes and a new instance of the bot is triggered?
  4. Does it ignore it while it is busy and will only trigger a bot again if not busy.

Ideally, I would like (4) to be the valid one but I just need confirmation. If it isn’t, is there a way to achieve this?

I’m just concerned that things could get messed up if terminated by orchestrator or if multiple instances are launched.

Thanks.

Thierry

2

No

No its not terminate the running process

No its not send the stop command for stop the current running process by default

Yes then its goes to queue, when the jobs are queued, in a pending state. The Robot executes the queued jobs in chronological order

Refer the following you will get the entire idea

3

@Maneesha_de_silva Apologies for the late reply and many thanks for the detailed answer.

I’m still not convinced as there is one remaining issue in our process which is throwing up an unhandled exception where an element cannot be found in SAP and unfortunately, as a result of the first unhandled exception, a second unhandled exception when it’s trying to move the relevant file to a failed folder.

What i’ve noticed is that the element it cannot find is the main grid displayed in SAP (FBL3N) which get opened as the SAP application is opened and the only time is is closed is when we’ve finished processing all the relevant information or when you try to launch SAP again and it is still opened, so by the looks of it, though not 100% sure yet, I can only assume that it is still trying to process transactions in the workflow while the SAP application somehow got closed.

Another thing that’s pointing me to believe that SAP got closed too early (i.e. by the workflow and by orchestrator) is that the trigger was originally set to 5 mins and the unhandled exceptions started to occur around the 5 minute mark. I then changed the trigger to 10 minutes and it appears that now the exceptions starting to occur after 9/10 minutes… This would be too much of a coincidence I think.

I will increase the trigger to 30 mins and see if the same occurs again and I might contact UiPath in the meantime.

One last thing that I’m not sure about but we’ve just changed our mode from User to Service in order to use Orchestrator RDP sessions with the LoginToConsole but I’ve noticed that the UiPath agent is still on the machine. Should that be the case? Originally when my colleague made the change, I thought the Agent had been removed as a result of using the Service mode but it is visible and I’m wondering could Orchestrator and the Agent be running at the same time and somehow both are trying to trigger the same workflow causing SAP to close while the other workflow is still busy processing transactions. Just a thought??

Thanks.

Thierry

1 Like