I have faced a need to setup Job Trigger in a “better way”.
I have a process which is running more than 24h, three times in a week (Mon,Wed,Fri), on two machines, from which one is being reset on Tuesday midnight, the other one on Wednesday midnight.
I need to make sure, that started jobs stop before the scheduled machine maintenance - I used Time Triggers (6 in count) to do so, from which two has a specific ending time, and are being revoked after maintenance with another trigger once again.
But sometimes there are random errors during processing in workflow, that lead to job end but there are still items in the queue left. It is good behavior, as the process could not pass through Init state.
Question here is: how to set up trigger, which will constantly revoke max 2 jobs, while there are still queue items left, but which will not fuss with scheduled machine maintenance? If I put simple Queue Trigger, it may start just before midnight maintenance (it’s checking queue every 15min) and I will lose the data when machine is shut. Is it possible to narrow Queue Trigger to not start under specific time of the day or so?
I already checked that I cannot create for the same queue two Queue Triggers, each one referencing to different machine. For one queue, only one queue trigger can exist in Orchestrator.
Or any other option what to do, to not have to start these job manually afterwards?
I just come to an idea to maybe check inside workflow which day and time it is, and if it’s really close to scheduled maintenance - the process should just end?
Managing job triggers and ensuring that they don’t interfere with scheduled machine maintenance can be a challenging task in UiPath Orchestrator. Here are some suggestions to handle this scenario:
Check Time Inside Workflow:
- As you mentioned, you can add logic within your workflow to check the current day and time. If it’s close to the scheduled maintenance window, you can gracefully end the job, making sure to complete any necessary cleanup tasks.
Queue Trigger Time Window:
- While you mentioned concerns about using a Queue Trigger, you can still make it work with some adjustments:
- Set the Queue Trigger to run every 15 minutes, but configure your logic inside the triggered job so that it only processes items when it’s not close to the maintenance window.
- Add a condition in the beginning of your workflow to check the time, and if it’s within a certain time frame before the maintenance window, simply exit the job without processing any queue items.
Custom Job Trigger:
- You can create a custom job trigger using the Orchestrator API. This trigger can be configured to check the time and, if it’s within the maintenance window, it can gracefully end running jobs. However, this would require custom coding and possibly a separate service to manage.
Prevent Queuing Close to Maintenance:
- As a preventive measure, you can educate users not to enqueue items too close to the maintenance window. This way, even if a job starts shortly before maintenance, it will have a limited number of items to process.
Orchestrator API Monitoring:
- You can develop a monitoring system that uses the Orchestrator API to track running jobs and check their progress. If you detect a job running close to the maintenance window with a significant number of unprocessed items, you can intervene programmatically to end it.
Scheduled Queue Item Addition:
- Instead of relying on automatic triggers, schedule the addition of queue items to occur at times when you are certain that they won’t interfere with maintenance.
Remember that each approach has its pros and cons, and the choice may depend on the specifics of your use case and available resources. Combining multiple strategies, such as a Queue Trigger with in-workflow checks and custom API monitoring, might provide the most robust solution to handle this scenario while minimizing manual intervention.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.