Prallel for each collides with queue trigger

Help Studio
, ,
1

Hi, I have an Orchestrator process. There I use “Add queue item and get reference” activity inside a “Parallel for each” activity.
The queue items are basically new emails, which means the number of queue items added to the queue is different every time I run the Orchestrator process.
There is a process that needs to be done on each queue item. So this process is triggered by queue items in the queue.
Since the “add queue item and get reference” is inside a " parallel for each", all queue items are added to the queue at once. But the process is triggered only once, which means only the first queue item gets processed. Then another queue item gets processed every 30 minutes. This kind of collides with the whole idea of parallel processing.
I can of course change the queue setting so x number of queue items can be processed/pending at the same time. But as I said since the number of queue items is not constant, I would have to guess the x.

Is there any solution? Why Can’t Orchestrator handle all the New queue items one after another as long as a robot is availble to do the job? Why does it have to wait for 30 minutes?

2

So parallel isn’t all at once, it is still sequential.

But your problem seems to be how you have set up the worker process, it should be working a queue item then picking up the next one if there is one available?

From your comment it appears you using triggers to run the bots, so does your main process stop the job after you work it or does it look for another queue item?

Are you using the ReFramework?

3

Hi,

As I mentioned it’s an Orchestrator process. I’m using the example given in the lecture provided by UiPath Academy (UiPath Academy).

The whole point of using Orchestrator process and “Add queue item and get reference” activity is to be able to handle every queue item as a separate thread which can be handled separately. If I were to use normal dispatcher and performer bots, I would have to use “get transaction item” in a “for each” loop. This means that one queue item must get thoroughly handled so the bot can get another queue item. So if the result of one queue item is sent to humans for verifying, the rest of the queue items and activities must wait until the human user responds. This is the challenge an Orchestrator process is trying to overcome.

Best regards

4

Have you looked at long running workflows?

That is used when there is human in the loop, which enables you to continue working other items whilst the original item is waiting for human involvement?

5

Well, the Orchestrator Process is actually a long-running workflow. Problem is it takes 30 minutes for Orchestrator to pick up the next Queue item and process it unless the Queue is set to process more than one Queue item at a time (let’s say n). Question then is if we are not sure how many Queue items we might have per day, how can we set n?