I don’t think you can use a cron expression in a Queue Trigger. At least not that I know of.
If you really want to use queue triggers, I guess one of the solutions that I can think of is to check the time at the beginning of your process. If it is out of the hours you want to, just set the transaction item to nothing and let the process finish without processing anything.
I am doing this exact thing already. However, it pollutes the KPI’s of our processes as the jobs will start and stop succesfully during those hours of the night, which in hindsight is not the best thing for measuring performance IMO.
It seems it would be a nice feature to have added, if it was possible to manage active hours of a queue based trigger.
100% agreed. If you are using the orchestrator API to get the data for the KPI’s, something that you could try - but probably would give you some work to do it - is to filter the jobs you are getting using the OData filters or filter the results in the backend by the creation time.
I know if might be a considerable workaround, but that at least if would not impact the metrics as much as having X jobs as successful when they are not really processing anything.
I’m indeed using the orchestrator API’s. I have considered this, but there are other processes that do not use the discussed system, in the same hours that i do want to measure. I have thought of excluding everything that runs less than 15 seconds within those hours though. It’s just a long way around the root of the problem.
Thank you for your time and help.
I’m hoping that the UiPath Staff will consider the possibilities of making the calendar hourbased or perhaps adding a function to control hours on Queue based triggers! It would be a nice addition to Orchestrator!
In my opinion, the best way to achieve this is to check the time in the process as others have suggested, but instead of not doing work if it’s outside of the processing time, you should throw and handle a special exception that postpones the queue item to the opening of your next working window.
That way, you won’t have processes continually running because there are queue items triggering a start. Added benefit here is it won’t muck up your KPIs because the queue items won’t appear as having been completed.