I have an issue where I am confused as to the logic of queue items being added in the Orchestrator Queue. I use an “Add Queue” Activity to insert items in the Orchestrator Queue from an application row by row, and I have a unique reference for every single item.
Initially I thought that when I load them into the Orchestrator Queue they are added one after another. First item is added, second item is added above the first, third above the second and above the first etc., and when the robot works each item it works them from the first one added to the last (so from oldest to newest, FIFO).
However by using the reference field I noticed that the Queue Items become rearranged and have different orders. This causes the robot to jump across tickets in the application and not work them sequentially.
Has anyone else encountered this issue before? Is there a way to remove this “sorting” capability for the queue transactions?
@ovi any idea on this one? If the reference field is sorting automatically then it changes the first in first out nature of the queue (priorities etc aside)…this is not right in my opinion.
When items are processed the order should always be FIFO. What you noticed about different order may be caused by AutoRetry. So, if an item failed and it’s retried another identical item will be generated with status New. But it will be placed at the end of the queue. Is this your case? If not, please let me know to further investigate.
I understand that part and that is fine, as this happens when items are being processed.
This issue is happening when items are loaded into the queue using the “Add Queue Item” activity and the reference field of it. When they are loaded in the queue, Orchestrator arranges them differently and they are not in the FIFO order, one after another.
I had to raise a service request as well and they said that this is a known issue and it was raised to the product team who are working on a release. Do you happen to know when a fix might be released?
Yeah, so basically when the Load process runs it loads tickets row by row from a datatable. But then Orchestrator rearranges the queue items, and when the Work process runs it no longer grabs the tickets in order, it runs them in the order that Orchestrator has “sorted” them.
Granted it’s not ideal, as eventually it will work through all cases, but when dealing with short SLA’s and hundreds of tickets it might become a problem.
No. I’m not using priorities or due date. It’s just a regular “Add Queue Items” activity which inputs a Subject and Timestamp and the reference is Subject + Timestamp.
It doesn’t look like FIFO though and can’t quite figure out a pattern as well.
Create a queue called QueueTest with Unique Reference set to Yes and run the process a few times and change the strSubject from Process 1 to Process 2, 3 etc. and you’ll see that after 2-3 queue items added the order of items becomes different.test.xaml (6.0 KB)
Is there any documentation to this ? I understand Queue uses FIFO concept to process the queueitems. I do not have the data to challenge it yet but want to know from you if it is documented somewhere that Orchestrator Queue process data in FIFO order ?
Hi Mayank, this info wasn’t explicitly put in the docs before, but we updated it in this section and now it stated that if the items have the same priority, the order is First in, first out. Check it here: About Queues and Transactions
Any documentation for 2018.4 as to how queue items are processed? Running into the same issue as queue items are rearranged and processed not in the order required