I am currently working on a workflow to generate invoices based on multiple carriers. For each carrier, there is a set of document entry details that need to be processed individually.
I would like to implement this using the Parent-Child Queue concept in UiPath, where:
The Parent Queue contains the list of carriers.
The Child Queue holds the related document entries for each specific carrier.
My questions are:
Is the Parent-Child Queue structure natively supported in UiPath Orchestrator?
If yes, could you please guide me or share references on how to configure and work with it?
If it is not supported, what would be the best practice to handle this kind of hierarchical or related queue design using two related queues (e.g., CarrierQueue and DocumentEntryQueue)?
How can I ensure the linkage between the parent (carrier) and the corresponding child (document entries) is maintained effectively?
Any suggestions, examples, or best practices would be greatly appreciated.
It’s not natively supported. You can implement this but will make your bot complex unnecessarily.
I would advise to rethink about the solution to maintain two queues. As per basic idea from your description, I think you can have a single queue with transaction having a field to identify carrier.
If possible, you can share your high level solution here so we can suggest something.
Instead of maintaining two you can leverage reference in queue which will define which carrier it belongs to and the docs can be added as specific content
And the get transaction item can be configured to retreive only those queue items which matchh the reference as well
This way thw items are present in same queue but also seggregated based on carrier
Here’s the high-level solution I’m currently following:
I’m using the REFramework.
In the Init state, I add the Carrier list to a queue and open the required applications.
In the Get Transaction Data state, I retrieve one carrier at a time from the queue.
In the Process state, I write a query based on the current carrier to fetch the list of document entries (DocEntry) associated with it.
I then loop through those document entries using a For Each loop, performing the required SAP actions and updating the report in Excel accordingly.
So essentially, each queue item (carrier) leads to a set of in-memory child items (DocEntries), which are processed in a nested loop within the process state.
I initially considered using two queues (CarrierQueue and DocumentEntryQueue) to separate the levels, but it seemed to add complexity with tracking relationships between items and managing statuses across queues.
Would appreciate any suggestions on improving this structure or handling this use case more efficiently.
As stated queues work independently, but I wouldn’t say this type of pattern isn’t supported, its just that you need to implement the pattern and its not all queue based.
I consider two approaches here.
One is a Dispatcher, Performer approach.
You can have the dispatcher grouped by the carriers, and then fire off queue items for the document entry, however this is only good if you want to ‘fire and forget’ and not group all the document entries back to the same carrier.
What I’d personally do is have a dispatcher start an Orchestration Job for each carrier (doesn’t have to be Maestro, infact Studio performs better for this).
The Orchestration job will hold the details of the carrier and all the document entries and fire off queue items for each document entry and use persistence to suspend the job and wait for all the queue items to be completed.
Once they are all done the Carrier Orchestration job can wake up, and will have the updated details of all the queue items it created, which it can then use for and reporting or further processing.
