Suppose we use a trigger to execute 10 jobs at the same execution time.
In orchestrator the first job is put in running state and the rest in pending state.
The trigger was set to stop scheduling the job after 3 hours.
If the job in the running state is delayed for any reason, Orchestrator stops and kills the job.
So what happens is that the other 9 pending jobs are finished because the time elapsed since the start time of the trigger elapsed more than 3 hours.
This is a big problem, because there should be an option so that the configured time to end execution of a scheduled job only starts counting when the status is running.
The reason why setting multiple jobs to run at the same time is very simple. These jobs do not have a fixed completion time. It can be 10 minutes or 30 minutes. The only thing we know for certain is that the 10 jobs never exceed 3 hours in total, when they all finish successfully.
We want to optimize the triggers and this is a very good practice but orchestrator does not allow it for the reason that I have commented.
If you want that instead of setting the end time for trigger. Why dont you use queue triggers and add 10 items to queue so that bots will stop only after completing all the 10 items
And the trigger also will happen only when queue items are added
And for adding queue items you can just set one trigger to add all items to queue
When I create a new queue-based trigger, I can only specify a process name only.
If I create 10 queue triggers, each with a process name, executing them all at the same time does the same thing as the time-based triggers.
I’m back with the same problem.
I want to schedule a task to run several processes at the same time, but the time configured to end or kill the process name only starts counting when the job in orchestrator status is running.
These processes are independent and complex projects that do different things. They are published as processes.
Okay now got your issue. SO you have 10 different processes and 10 triggers are given with start and end times as same on same bot… SO all start and stop at same time but if first bot takes more all will be closed.
So for this. I believe you wont have any solution directly using orchestrator. You have to save the start time of the bot from your process it self and check for 3 hours completion and stop the bot accordingly
Then you wont be configuring when to stop. You will configure only start in trigger and the stop of bot is counted from start time of the bot when it actually starts in the machine
Thanks for the reply.
Now you know my problem.
Your solution requires modifying all my processes and managing numerous activities and logics to achieve the same effect.
There are times when the delay is caused by unexpected behavior of the bot. For example, in web page automations, new situations or loops that make the process enter a loop, etc.
It would be much more effective, clean and safe, to have an argument or question in orchestrator that allows starting the completion timer only when it is in the running state. Maybe the developers will keep it in mind for future versions.
Greetings and thanks for your interest.
Agree with your point that it helps.
Yes we need to modify each process but the logic or managing numerous activities is not something that we need to do. There are only 2 steps
- Save the start time of bot in a variable
- Where you see send stop signal in the Get transaction data and in Initialization include one more condition to check if the saved time and current time difference is 3 hours or more