I will talk about one of the most interesting things I've seen on Blue Prism, we're talking about multi-robot and task concurrency.
As you already know, to build a process on Blue Prism, you have to use one or more queues, which are built to manage concurrency between multiple robots.
The question is: how to optimize concurrency among multiple robots?
The answer is in the process design.
Let's think about the typical producer-consumer model we deal with when we tipically work with multi-thread and let's imagine three robots up and running.
Like you see i defined a main flow which references two subprocesses: producer and consumer.
The main flow is a infinite loop that will be started from the scheduler, to stop the loop you can use a decision stage that checks a finish time, written on an environment variable.
The first subprocess is the producer and populates the work queue.
It's kinda best practice to put a environment lock before the producer starts in order to have just a robot at a time working on the producer process.
This is due to the fact we want to avoid multiple robot to do concurrently the queue population process and not so useful checks on already existing queue items.
Consumer it's a simple loop that iterates on the queue until the queue itself it's empty, no lock here, because Blue Prism deals with concurrency and locks the work item itself.
I know it's a very simple process but this is the baseline for other stuff, right now i'm working on a process which has something like 2 producers and 3 consumers, playing with environment locks on producer processes i can optimize concurrent robot performances.
I heard someone who preferred to pre-assign work item to different robot but i think this is not a good idea, this is because you cannot be sure a single work item requires the same amount of time.
For example, in one of our project we had some work item requiring up to 7 hours of robot effort.
If you work the items with pre assignation you will have this work duration
Robot 1: 13h
Robot 2: 3h
Robot 3: 4h
This means you'll have very low efficiency on Robot 2 and Robot 3. Applying the multi-robot model you'll have something like this
Robot 1: 7h (1)
Robot 2: 1h (2) + 6h (4)
Robot 3: 1h (3) + 2h (5) + 3h (6)
As you can see you will have a workforce that dinamically take in account a queue item and tries to process item as fast as possible.
If you also have more than one process (i hope for you so) on your BP server, you can also think about a main process that plays with all registered processes in order to use robot workforce in the best way.
As you already know, to build a process on Blue Prism, you have to use one or more queues, which are built to manage concurrency between multiple robots.
The question is: how to optimize concurrency among multiple robots?
The answer is in the process design.
Let's think about the typical producer-consumer model we deal with when we tipically work with multi-thread and let's imagine three robots up and running.
Like you see i defined a main flow which references two subprocesses: producer and consumer.
The main flow is a infinite loop that will be started from the scheduler, to stop the loop you can use a decision stage that checks a finish time, written on an environment variable.
It's kinda best practice to put a environment lock before the producer starts in order to have just a robot at a time working on the producer process.
This is due to the fact we want to avoid multiple robot to do concurrently the queue population process and not so useful checks on already existing queue items.
I heard someone who preferred to pre-assign work item to different robot but i think this is not a good idea, this is because you cannot be sure a single work item requires the same amount of time.
For example, in one of our project we had some work item requiring up to 7 hours of robot effort.
| Item name | Assigned to | Avg duration |
|---|---|---|
| 1 | Robot 1 | 7h |
| 2 | Robot 2 | 1h |
| 3 | Robot 3 | 1h |
| 4 | Robot 1 | 6h |
| 5 | Robot 2 | 2h |
| 6 | Robot 3 | 3h |
If you work the items with pre assignation you will have this work duration
Robot 1: 13h
Robot 2: 3h
Robot 3: 4h
This means you'll have very low efficiency on Robot 2 and Robot 3. Applying the multi-robot model you'll have something like this
Robot 1: 7h (1)
Robot 2: 1h (2) + 6h (4)
Robot 3: 1h (3) + 2h (5) + 3h (6)
As you can see you will have a workforce that dinamically take in account a queue item and tries to process item as fast as possible.
If you also have more than one process (i hope for you so) on your BP server, you can also think about a main process that plays with all registered processes in order to use robot workforce in the best way.
