Hi All,
I am looking to build a Performer to process many queues while using the Action Center and Document Understanding Activities.
When I reach the activity ‘Wait for Classification Validation Task & Resume’ the Process pauses and waits for the human to respond to the task that’s created in the Action Center for this queues item.
My question is:
What is the best way to get the project to continue on with processing the next queue item while waiting for the human to respond to the current item.
Then once the human responds to the action item, how does the bot go back to finish processing that queue?
Does anyone have a sample project for this sort of case?
Thanks in advance. 
Generally in this scenario..wait for resume is used with paralle for each so that multiple are created and the job waits for multiple and starts even if one is completed for that specific task
And after resume it is ideal to add the data to separate queue which triggers the remaining prr of the process as a separate job as a separate process instead of continuing in the same
So process 1 - pick queue item, create task, in end state use parallel for each and wait for task activity ,after wait add quwue item ti a different queue
Process 2 - queue trigger once process 1 adds an item to queue, process the remaining data, get form tasks can be used to get the data of the tasks
Cheers
There are tons of posts on this, as well as UiPath documentation available online - everything and everyone will explain that processes that wait for anything (action center task, queue item, etc) should not be designed as looping automations.
Here is an example of a process I recently completed…
Dispatcher - loops through items on a web page and creates items in the “performer” queue
Performer - on a queue trigger, loops through items, looks up data in mainframe, makes comparisons and if comparison fail it creates a queue item in the “actioncenter” queue
ActionCenter - processes one item and stops, because in the middle it suspends waiting for the Action Center Task. This process is on a queue trigger that starts multiple jobs, one per queue item
1 Like
Thanks for that feedback.
When you say “creates a queue item in the ‘actioncenter’ queue” do you mean create the task to be handled in the Action Center, or create a second queue to be processed in another job?
From your response, this is what I understood from that, please correct me if I’m wrong.
-A queue trigger is set to run a job to process 1 queue at a time.
-Job processes a document
-If human in the loop is needed
-Yes. Task is created in the Action Center and job pauses until task is completed. Meanwhile, another job starts.
-No. Current job finishes processing.
Thank you!
No. I have one queue for the performer. The dispatcher creates items in that queue. Then I have a different queue for the actioncenter process, and the performer creates items in that queue. When an item is added to the actioncenter queue, the trigger kicks off a job. The actioncenter process creates the task then waits (suspends).
Dispatcher → performer queue
Performer → actioncenter queue
When I say actioncenter process, I literally mean a separate project. So I have MyBusinessProcess-Dispatcher, MyBusinessProcess-Performer, and MyBusinessProcess-ActionCenter as separate projects/automations. The first two loop, the actioncenter one does not.
That’s not correct. You don’t wait for one job to finish before starting the next job. You set up the Trigger to create MULTIPLE jobs at the same time (for the actioncenter process). That way if 5 items go into the queue, 5 jobs are started.
I usually set this, also:
Just makes sense to me (for permissions and other reasons) to have it resume under the same robot/server. But in the end that depends on your needs and environment.
So you end up with multiple jobs suspended waiting for the task to be completed:
How many jobs it creates is up to you, your licensing, etc. However keep in mind when a job suspends it is NOT using a license.
Pauls setup using single jobs is the correct one, however I personally differ on some architect and triggering mechanism as I dont think queue triggers and using queues for them are the correct way.
The way I have solved this for years and advocated for is via ‘process orchestration’.
This use to be harder, but we have alot of options now, we have either the ‘Long Running Automation’, or now Maestro.
In the long run I think Maestro will become the better method to do this, but its currently quite buggy and not feature complete as its still in public preview.
The long running workflow would actually orchestrate your process end to end.
I’ll take Paul’s example as a comparison and suggest the Architecture I’d do instead.
Please note, the architecture style I propose has been possible for about 5 years now, but the tooling for it etc is only now becoming widely available and popular.
So, if we had this
Dispatcher - loops through items on a web page and creates items in the “performer” queue
Performer - on a queue trigger, loops through items, looks up data in mainframe, makes comparisons and if comparison fail it creates a queue item in the “actioncenter” queue
ActionCenter - processes one item and stops, because in the middle it suspends waiting for the Action Center Task. This process is on a queue trigger that starts multiple jobs, one per queue item
I would instead do this.
Dispatcher - Loops through items on a web page and starts an Orchestration job per item, passing details of the item directly to the job it starts (you can optionally track these jobs in the dispatcher for reporting).
Orchestration - This is a long running process and will suspend several times during the execution, which can take several days, it takes the details from the item and creates a queue item for Performer 1 to start and then suspends, waiting for that item to be done.
Performer 1 - This functions as a normal performer, triggered by a queue trigger and will process queue items made from any Orchestration job.
Orchestration (resumed) - Once the queue item from performer 1 is compelted the Orchestration job is triggered automatically to wake up, it can read data from the queue item as necessary and do the next step. In this context that is the human in the loop, the orchestration process already supports persistence as we just had a ‘robot in the loop’ so we can do this directly with no issues.
After this we can continue processing if neccessary, maybe there is a second performer we need, and that can be used in the same way as the first one.
This is a strong design pattern and one that doesn’t rely on one performer being hard coded to trigger another in a ‘daisy chain’, which can help significantly reduce complexity in your performers, it also centralises alot of the major business logic in one layer making it easier to understand than ‘chaining’.
This will be the design pattern Maestro enforces and due to the way we can also resume maestro workflows from an error state it will also become very strong, but for now, you can try this using the template I propose.
1 Like
Great! Thank you for the detailed response. I really appreciate it.
I do have one more question based on this.
Could I just run multiple jobs of the 1st Performer (your MyBusinessProcess-Performer) and not create queues in there for another project?
I’m having trouble understanding the purpose of the 2nd Performer for the Action Center, or is that just your preference for handling these cases and it could be done without?
So that way I’d just have:
Dispatcher → performer queue
Performer → no looping
Thank you, again.
If you follow @Jon_Smith method then you dont need a second performer else you need one as wait for resume works in main xamls only and also parallel for each to be used for multiple items to be paused at once..this architecture would be supported with having second queue only or else it cannot wait for multiple at all
Cheers
1 Like
Thank you for your detailed response, I really appreciate it.