Queue Build:
I’ve a bot that accepts an asset (NumberOfQueues) to add items to a number of queues.
QueueNames: Queue1, Queue2, Queue3, Queue4, Queue5 (if NumberOfQueues = 5)
ConsumeQueue: Assume it accepts the same asset NumberOfQueues = 5.
I need to run on 5 different bots/usernames and make sure each bot/username processes items from only one queue.
Example
Reason I’m using multiple queues is that I want to avoid multiple bots updating the same file at the same time. I’m using Orchestrator 2018.3.2 and I cannot retrieve queue item by reference.
I believe using assets is still valid, no? You could have an asset with queues available per each robot/user and you could check for it at the start of the process based on the username.
I’ve done exactly that. Issue with this solution is that it appears inflexible to the third person. Simply because the process owner cannot simply run the bots on any machine and still process default queues.
I was hoping to tie the queues with usernames at run time without using assets. If there was ability for me to somehow process transaction items based on reference I wouldn’t have to build multiple queues in the first place.
I wonder, would it make sense to have an asset for each queue to mark if it is being ‘used’ by a process?
You could then start the process by checking these queues by their flags and only process items from a queue that is ‘open’ (=not used by another process). Then, after choosing a queue that isn’t used, you update its flag, process an item and then mark the queue as open again at the end.
I am not sure how well this would sync together, but might be worth trying out.
One thing I recently learned is that Get Transaction Item picks items first by “Due Date”. However, I have not had a chance to test this, which I should be today cause it’s something I need… the ability to alternate and prioritize items by data sets (ie multiple users using the same process).
Also, ideally, a single process would share the same Queue. But, that’s just my opinion. And, I understand if you only want to separate each data set by robot. If using Due Date to alternate the items across each robot works, then that might be a viable option.
Be careful about using the Asset solution. What will happen is if 2 bots get to the “Get Asset” at the same time, they will both think it’s Open.
One way I have accomplished this in the past was to have a controller Asset which allowed the bots to look at and change the Asset one at a time. At the start of the process, you store a timestamp for that robot (like yyyyMMdd.HHmmss.fffff), and store that into the controller Asset which gives that bot permission to look at the other asset. Then, change the controller back to 0 when it is done. - In order to use the controller effectively, you would need it in a Do While that checks if it is 0 before changing and waits until it equals the timestamp for that robot, with also a delay in case a second robot sees the 0 at the same time.
But, maybe there’s a way to use Assets to manage multiple robots without some kind of controller. I think you would need one though so the robots don’t step on each other.
Dear @msangha80
not easy to solve and 2018.3.2 give some challenging limitations as well.
We do have the lack in this version that we dont have the control on which particular Queue Item we want to work. Unfortunately I didnt had a chance to RnD it, if we can set the transaction status by using Orchetrator Rest API. (a 50/50 chance)
Would this work then maybe following things could be used:
1 or more Work Queue Items are grouped via the Reference e.g. Set-2019-09#001,2,3…
These Items will have an additional Item as Representative with Reference name: JOB#Set-2019-09#001
** same Work Queue or additional Control Work Queue
Now it is looked if a dateset is to process (options)
with get Work Queue Item (Control Work Queue)
get Queue Items and filter: reference starts with JOB and status is new
Rest API
Indicating that now a free dataset is in work:
get Work Queue Item on JOB Representative Item is doing this by changing the status
** or get Queue Items + REST API if its possible
Lets do the work with the Queue Items: Set-2019-09#001-1, Set-2019-09#001-2 …
Prerequisite: it can be done via REST API
The Status of the set can be reflected on the JOB Representative Item
Progress Info can be reflected via Set Progress on the JOB Representative Item
Other risks are named by @ClaytonM as well Concurency fetch etc. and need some tricks additionaly
So its a variation from above and need for sure some more things.
I did some playing to overcome the missing control of getting particular Queue Item to in progress by:
get Queue Items and filter:
creating a duplicate with add transaction item (this is bringing the item to in progress) and working with this TI, the old one I set to sucessfully and ignored. This was working for me on very special situation. Work/Control Queues used as named above.