Based on my understanding of what you’re asking, I might try using queue-based triggers and the RE Framework as a starting point.
Consider the following example.
- Create a Queue named Q1.
- Add a Trigger to Q1 named MyProcessTrigger-Q1.
- Configure MyProcessTrigger-Q1 as follows:
a. Process name: Your process built on the RE Framework.
b. Under Arguments, set the value for in_OrchestratorQueueName to Q1 and save.
NOTE: in_OrchestratorQueueName is an argument exposed by Main.xaml in your RE Framework project. By providing a value for in_OrchestratorQueueName you will override the value coming from Config.xlsx - see the Initialization state in Main.xaml.
c. Make an appropriate robot/machine mapping (or allow dynamic allocation - whichever your use case requires).
d. Add the trigger. - Repeat these steps for each subsequent queue (e.g., Q2, Q3, …) you need to create - use the same process and update the input argument with the corresponding queue name.
Passing the name of the queue into the automation as shown above has two benefits. First, the RE Framework will follow all existing logic to process queue items - no changes required. Second, you can use the value in a Switch activity to determine the sub process you need to execute (see image below).
This setup should allow for parallel processing as each queue trigger would initiate its own job; however, there are a few assumptions:
- A sufficient number of runtime licenses have been allocated.
- A sufficient number of (high-density) machines have been configured to handle the load.
- An appropriate number of robot identities have been created.
Hope this helps get you started.