I have a process with REF design with input coming from queue1. Once bot reach point A, bot push item1 into queue2, and business would need to approve/reject in Action Center.
Queue2 is to monitor item1 status is Approved/Rejected on Action Center.
Lets say that item1 is approved/rejected, bot would need to sent notification email which is point B.
My question is:
How can bot resume straight from point B once item1 is approved/rejected in Action Center?
Would bot be stucked with item1 until action is taken on Action Center? What’s the idea for the bot to be able to continue process next item2 from queue1?
just complementing Anil’s, within our DU projects we use the parallel for each activity and inside that for each we put the Create Action Center Task and the Wait for Task and resume activities (we need those 3) the parallel activity will allow us to process all the documents at the same time, it means that if 2 of 10 documents require validations, our process will process the first 8 documents that not require any kind of validations and the other 2 will go to the action center, the bot will get a suspended state until the user validate it, once validate the bot will process the document automatically
based on your input, let’s say all 10 documents need to be validated in Action Center, then bot would be suspended forever until 1 of the documents is validated, right?
I think of creating another discrete process for point B (from my initial question on this post), which would be triggered based on approval/rejection on Action Center. This way, the main REF process can process all items from queue1 without being suspended.
Interesting, I have definitely had issue with using parallel as it makes too many API calls to the Orchestrator at once and will break as when one thread wakes up (say a Queue item or job resumes) all the threads will ping the Orchestrator. If you have 500 threads in your parallel loop and 499 ping the Orch after the first is done you end up the Orchestrator blocking the request as being spammed by too many requests at once.
There are definitely issues with some of the loop types, I think the looping over rows in a table doesn’t resume properly, but a normal loop does.