Link Bots with Specific Queue Names

#1

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

Robot1/User1 -> Queue1
Robot2/User2 -> Queue2
Robot3/User3 -> Queue3
Robot4/User4 -> Queue4
Robot5/User5 -> Queue5

I know I can use Config or an asset to link users/robots with queuenames.

Is there a way to do this at run time?

Supposedly the process owner wants to use different robots/users to consume queues, is there a way to make sure the following

Robot6/User6 - Queue1
Robot7/User7 - Queue2
Robot8/User8 - Queue3
Robot9/User9 - Queue4
Robot10/User10- Queue5

Any help ideas will be appreciated. Thanks.

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.

#2

Hi @msangha80

I have hard time understanding your scenario.

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.

#3

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.

#4

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.

#5

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.

Regards.

#6

Really appreciate the time you guys devote to answer the queries.

  • I agree single queue would be my preferred solution but not working at the moment due to restrictive Orchestrator version.
  • If the items in my dataset takes longer to process and due date is breached then the whole process is buggered
  • Plus I believe we’ll still have to feed an asset/bot to pick due date every time you run the bot.
  • what I’ve done now is feed an asset/bot to pick the queue, I’ve named my queues as Process1Queue[N] with N being 1, 2, 3 etc
  • this way the process owner still has flexibility to choose bots depending on availability
#7
  • So you mean update assets using Set Asset, correct?
  • Suppose I have assets defined as
    Asset1 = Open ( 1 ties to Queue1)
    Asset2 = Open ( 2 ties to Queue2)
    Asset3 = Open ( 3 ties to Queue3)
  • So we trigger three bots to process three queues. All the bots check iteratively if Asset* = Open, with * being [1,2,3 … MaxBots]
  • if Asset1 = Open, start processing items from Queue1 but use Set Asset to change Asset1=Used
  • when no items left in the Queue1, use Set Asset to change Asset1=Open
  • This way rest of the bots will not touch Queue1
  • Sounds promising to me, this will work i think
  • I’ll need a universal asset for the whole process that says max bots to use. example - MaxBots=3
  • the process owner do not have to worry which bot to allocate which queue
#8

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.

Regards.

1 Like
#9

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.

Let us know on your progress thanks