Queue Triggers with time window

Feedback Orchestrator
, ,
1

Hello,
we use some queue triggers and are missing a restriction here.
Because our service provider installs software updates at night, runs batch processes and also carries out other maintenance, it is allowed to run robots up to 8 p.m. at most. So it would be very helpful here if these queue triggers can also be limited in time. By that I mean that we would like to define a time window, e.g. 6:00 a.m. to 8:00 p.m., in which this trigger should be able to start robots. Outside of this window, the trigger should not start anything.
Kind regards

1 Like
3

Hello @martinN , what process pushes the message to your queue? Can you either restrict that process to not push the message to your queue based on timestamp or restrict the process that is based on this queue based trigger to end process immediately (based on timestamp) and not proceed further if it is in between 8.00 to 10.00 pm? I see that you can handle this in code.

4

What do you mean? My post was a suggestion for improvement, not a question of a solution. To be more clear:
We have a special process that runs every 30 minutes. This robot reads all delivered data into the queues. Sometimes there are 30.000 items for one queue. It takes a few days for our robots to process all these data. So this process cannot be triggered by a queue, because there is usually data in this queue. We can use time slot based triggers here only.
We also have functions in our processes, which are checking the time and stop running if the actual time is outside of a slot. But if a process checks the time, it is already running (and has opend e.g. a rdp session) and thats the point I want to pervent. Nothing should run outside of the time slot. So it would be nice if a queue based trigger would not fire commands outside a defined time slot.

1 Like
5

Hey @martinN

I guess currently we only have non-working day restriction.

So its good to have time based as you need for your scenario.

Cool
#nK

6

ok got your point now @martinN . I guess you need to tag this post as part of the suggestions category then. Tagging @Yoichi
BTW, will distributing this data across multiple queues help ? e.g. queue1, queue2 etc. Again, just a suggestion in order to get your queue emptied faster and distribute the items across. If this does not work then it will probably need to go as a suggestion.

1 Like
7

I see no advantage in using multiple queues here. you? In my opinion, this does not mean that the process is processed any faster. We are working on this queue with a number of robots. Each data set takes its time.

8

Hey @martinN

Thank you for your feedback.
I saved your suggestion in our internal tracker for our Orchestrator team to consider in the future.

In the meantime, I could only advise an additional process that will use Orchestrator API to manage the queue trigger to disable/enable it according to the desired schedule. I think this could help you prevent processes from running within the maintenance window.

4 Likes
10

I’m in the same situation, as our CRM system has nightly downtime for maintenance.

The API call is a good idea, but may not be the easiest to schedule in.

My idea is to check an “off time” setting (probably an asset but could be in a config file) against the current time, and if it has passed then the process postpones transactions to until an “on time” value. Obviously the off-time must be a comfortable way before the systems go down, or is checked when you can’t perform a login operation.

Would that work?