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.
Does a Time Based Trigger support Postponed transactions ?
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.
Is there a chance of transaction items being left unprocessed using Time Based Triggers on a queue with Postponed Transactions ?