Using a Postponed Transaction item in a Queue with attached Time Based Trigger

[riverrat437 (Sean O'Neill)]

We have reached a point in our design where we need to be able to run workflows on specific Robots within a specific datacenter. There are three DCs.

First, we are using Classic Folders (unfortunately in this case). Our current design is an external application pushes postponed transactions into a queue. This queue has a Queue Based Trigger on it. At around the “postponed” timeframe, this queue fires off the linked process and it grabs a transaction flagged for around that timeframe (typically but not always … there is an Orchestrator bug here unfortunately). That process takes that transaction item, processes it, and creates one or more new transactions in another queue. That other queue also has a Queue based trigger which runs them immediately and the linked process fires and processing starts up.

Unfortunately, this doesn’t work well for Robots in other DCs needing to run the same workflow. Goes to Classic Folders, Environment setup, you can’t have the same named workflow associated with multiple environments, and Queue Based Triggers don’t allow for “Execution Target” specification.

Let me ask about Time Based Triggers using Postponed Transaction Item.

1. Does a Time Based Trigger support Postponed transactions ?

2. If a postponed transaction is added to a queue and the time based triggers fires, how does Orchestrator handle these types of transactions. Say the time triggers starts running at 4pm ET every 5 minutes.

   • Postponed time which is already in the past like say 3:30pm ET - will this transaction be picked up ?
   • This scenario will always happen for us as we are intentionally not allowing one REF running workflow to “drain the queue” like REF is setup OOTB.

3. Is there a chance of transaction items being left unprocessed using Time Based Triggers on a queue with Postponed Transactions ?

[codemonkee (Tim)]

@riverrat437

1. Does a Time Based Trigger support Postponed transactions ?

Postpone / DeferDate and Deadline / DueDate are queue features and not so much Trigger features. So when a process runs and it asks for a queue item, Orchestrator will look to see if any items are available which includes current time being equal or passed the defined Postpone stamp.

@riverrat437

If a postponed transaction is added to a queue and the time based triggers fires, how does Orchestrator handle these types of transactions. Say the time triggers starts running at 4pm ET every 5 minutes.

• Postponed time which is already in the past like say 3:30pm ET - will this transaction be picked up ?
• This scenario will always happen for us as we are intentionally not allowing one REF running workflow to “drain the queue” like REF is setup OOTB.

In this regard, a Time based Trigger or Queue Based Trigger behaves no differently. In both cases a Process is fired off and within that process it is checking for a Queue Item that matches the criteria. If one does not exist, the process will End.

Postpone specifically is the date after which the queue item may be processed. So if you start the process at 16:00 and there is an item in the queue for 15:30, then yes it would be picked up by running the process.

@riverrat437

Is there a chance of transaction items being left unprocessed using Time Based Triggers on a queue with Postponed Transactions ?

Not that I am aware of, if you can describe the bug that you are experiencing maybe someone can shed some light. In my experience of using Queue based Triggers there can be a grey area of when a process starts depending on your Queue Trigger configuration, which is why Orchestrator by default checks Queues every 30 minutes to determine if the trigger needs to fire off.

A way around that grey space if you don’t want to chance waiting the 30 minutes is for the process that adds the item to the queue to also check if at least one job for the process is running and if not to kick off the job right away.

One scenario I haven’t tested is if using Deadline / DueDate as well, if that Deadline has passed will it assume that the transaction no longer needs to be processed.