From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.

Tarcio - thanks for your response. Pretty much confirming what I'd deduced - but thought worth checking. I must admit though I'm a little surprised as to the random element of the queue management - I would have expected to be some sort of ordering in play - ie age of the instance on the queue.

From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.

The sorting takes place within each queue. Since each step is its own queue, it's possible that step 1 of new instances will be processed before any instances in step 3 are processed.
As I mentioned above, if you don't need to separate the steps into different groups of computers, it may not be necessary to introduce this level of complexity into your process.

All you need to do is create a bot and call different scripts (one for each "step", to keep the business logic clearly separated), so that each bot/instance will run from start to finish.

Tarcio - thanks for your response. Pretty much confirming what I'd deduced - but thought worth checking. I must admit though I'm a little surprised as to the random element of the queue management - I would have expected to be some sort of ordering in play - ie age of the instance on the queue.

From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.

Again Tarcio - thanks for responding. 

I understand that as there's no prioritisation between steps in a process so yes step 1 of new instances can be processed before step3 of existing instances. But what is the ordering within the queue of a step? We are currently seeing that there appears to be a randomness about this as well. Ie some instances may sit at step1 for a long time where as 'newer' instances might come in and be processed before the older instances - I suppose I would have expected at least a first in first out approach to queue management.

The sorting takes place within each queue. Since each step is its own queue, it's possible that step 1 of new instances will be processed before any instances in step 3 are processed.
As I mentioned above, if you don't need to separate the steps into different groups of computers, it may not be necessary to introduce this level of complexity into your process.

All you need to do is create a bot and call different scripts (one for each "step", to keep the business logic clearly separated), so that each bot/instance will run from start to finish.

Tarcio - thanks for your response. Pretty much confirming what I'd deduced - but thought worth checking. I must admit though I'm a little surprised as to the random element of the queue management - I would have expected to be some sort of ordering in play - ie age of the instance on the queue.

From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.

The "first-in, first-out" principle does apply, but only within each queue (step).
However, there is no "ordering" between the queues.

Each computer needs to "monitor" all the steps it is associated with.
Imagine the scenario:
The computer may be associated with "step 1 of process 1," "step 2 of process 2," and "step 3 of process 2"
In this case, the computer has to look at 3 different queues (one for each step it is associated with). 

Here lies the randomness, because there is no order of priority among the steps, only among the items within each step.

I understand your frustration, but this feature was designed for this type of scenario, where a computer (or group of computers) is responsible for a part of the process that another computer cannot perform or that acts as a bottleneck in the process.

In both scenarios, the "order" doesn't matter that much, as long as you can optimize the runtimes of each computer as much as possible (which is the intention of this feature).

Again Tarcio - thanks for responding. 

I understand that as there's no prioritisation between steps in a process so yes step 1 of new instances can be processed before step3 of existing instances. But what is the ordering within the queue of a step? We are currently seeing that there appears to be a randomness about this as well. Ie some instances may sit at step1 for a long time where as 'newer' instances might come in and be processed before the older instances - I suppose I would have expected at least a first in first out approach to queue management.

The sorting takes place within each queue. Since each step is its own queue, it's possible that step 1 of new instances will be processed before any instances in step 3 are processed.
As I mentioned above, if you don't need to separate the steps into different groups of computers, it may not be necessary to introduce this level of complexity into your process.

All you need to do is create a bot and call different scripts (one for each "step", to keep the business logic clearly separated), so that each bot/instance will run from start to finish.

Tarcio - thanks for your response. Pretty much confirming what I'd deduced - but thought worth checking. I must admit though I'm a little surprised as to the random element of the queue management - I would have expected to be some sort of ordering in play - ie age of the instance on the queue.

From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.

Tarcio

I think you misunderstood my last point. We are not even seeing as far as we can tell a first-in first-out principle within a queue. We had a situation last week where an instance languished at step 1 in the process for about 2 days whilst over instances came in and were processed before it. There was a criticalness to getting this instance processed and I couldn't work out why it was not being progressed through the steps - and it was this situation that made me raise this query.

The "first-in, first-out" principle does apply, but only within each queue (step).
However, there is no "ordering" between the queues.

Each computer needs to "monitor" all the steps it is associated with.
Imagine the scenario:
The computer may be associated with "step 1 of process 1," "step 2 of process 2," and "step 3 of process 2"
In this case, the computer has to look at 3 different queues (one for each step it is associated with). 

Here lies the randomness, because there is no order of priority among the steps, only among the items within each step.

I understand your frustration, but this feature was designed for this type of scenario, where a computer (or group of computers) is responsible for a part of the process that another computer cannot perform or that acts as a bottleneck in the process.

In both scenarios, the "order" doesn't matter that much, as long as you can optimize the runtimes of each computer as much as possible (which is the intention of this feature).

Again Tarcio - thanks for responding. 

I understand that as there's no prioritisation between steps in a process so yes step 1 of new instances can be processed before step3 of existing instances. But what is the ordering within the queue of a step? We are currently seeing that there appears to be a randomness about this as well. Ie some instances may sit at step1 for a long time where as 'newer' instances might come in and be processed before the older instances - I suppose I would have expected at least a first in first out approach to queue management.

The sorting takes place within each queue. Since each step is its own queue, it's possible that step 1 of new instances will be processed before any instances in step 3 are processed.
As I mentioned above, if you don't need to separate the steps into different groups of computers, it may not be necessary to introduce this level of complexity into your process.

All you need to do is create a bot and call different scripts (one for each "step", to keep the business logic clearly separated), so that each bot/instance will run from start to finish.

Tarcio - thanks for your response. Pretty much confirming what I'd deduced - but thought worth checking. I must admit though I'm a little surprised as to the random element of the queue management - I would have expected to be some sort of ordering in play - ie age of the instance on the queue.

From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.

Are you saying that an "instance X" was left waiting to execute step 2, while other instances created later had their step 2 executed?

If that's the case, it could be a bug, or there might have been an error when adding that instance to the step 2 queue.

Tarcio

I think you misunderstood my last point. We are not even seeing as far as we can tell a first-in first-out principle within a queue. We had a situation last week where an instance languished at step 1 in the process for about 2 days whilst over instances came in and were processed before it. There was a criticalness to getting this instance processed and I couldn't work out why it was not being progressed through the steps - and it was this situation that made me raise this query.

The "first-in, first-out" principle does apply, but only within each queue (step).
However, there is no "ordering" between the queues.

Each computer needs to "monitor" all the steps it is associated with.
Imagine the scenario:
The computer may be associated with "step 1 of process 1," "step 2 of process 2," and "step 3 of process 2"
In this case, the computer has to look at 3 different queues (one for each step it is associated with). 

Here lies the randomness, because there is no order of priority among the steps, only among the items within each step.

I understand your frustration, but this feature was designed for this type of scenario, where a computer (or group of computers) is responsible for a part of the process that another computer cannot perform or that acts as a bottleneck in the process.

In both scenarios, the "order" doesn't matter that much, as long as you can optimize the runtimes of each computer as much as possible (which is the intention of this feature).

Again Tarcio - thanks for responding. 

I understand that as there's no prioritisation between steps in a process so yes step 1 of new instances can be processed before step3 of existing instances. But what is the ordering within the queue of a step? We are currently seeing that there appears to be a randomness about this as well. Ie some instances may sit at step1 for a long time where as 'newer' instances might come in and be processed before the older instances - I suppose I would have expected at least a first in first out approach to queue management.

The sorting takes place within each queue. Since each step is its own queue, it's possible that step 1 of new instances will be processed before any instances in step 3 are processed.
As I mentioned above, if you don't need to separate the steps into different groups of computers, it may not be necessary to introduce this level of complexity into your process.

All you need to do is create a bot and call different scripts (one for each "step", to keep the business logic clearly separated), so that each bot/instance will run from start to finish.

Tarcio - thanks for your response. Pretty much confirming what I'd deduced - but thought worth checking. I must admit though I'm a little surprised as to the random element of the queue management - I would have expected to be some sort of ordering in play - ie age of the instance on the queue.

From what I understand about your process, using orchestration might not be the best idea in your case.

Let's break it down:
1. Orchestration works with queues. Each step is an "independent" queue. Each computer needs to monitor ALL the steps associated with it, and since each step is independent, IBM RPA does not prioritize finishing one instance to start another. All this monitoring is dynamic and random. The purpose of orchestration was to allow each step to be distributed across different groups of computers so that the user can assign more machines to a part of the process that takes longer. Or to limit computer usage for access-restricted scenarios (when only certain VMs have specific access and only they can execute that step of the process).

2. Currently, we do not have step prioritization. It is possible to queue an instance with a different priority for the next step (according to business needs); however, the Azure Storage queue (used in SaaS) does not currently support this, but you have the option to use other queue service providers such as IBM MQ, for example.

3. We also do not currently support automatic step retries. This feature might be of interest for the product and could be requested on the Aha portal for prioritization by the Product Managers.

Perhaps for your scenario, it makes sense to simply create a bot and use a `do/while` loop to retry a specific section of code if it has failed.