Yes, GetTransactionItemByReference would be enough to fight for a desired item. That would be great if if this field would be updatable and be able to put back to the queue for later processing.
PostponeTransactionItem puts back and item to the queue to a certain time and not to the end of the queue. If GetTransactionItem returns nothing, the robot can not decide whether the queue is empty (so all items are processed) or there are items that are postponed and the currently issued GetTransactionItem is too early to get those items.
My problem is that current queue management system in UiPath considers transactions as “atomic”. If a robot gets a transaction item, it must process it 100% and the result can be either success or failed. However in most of the cases every item in the queue must pass several steps (do something, save in erp, do another thing, save in erp, do third thing, save in erp, send an email an then done, and this is the point where it can be succeed.) After saving on the first screen the item can not go back anymore to the first screen.
What to do now if the processing fails at step 2 for watever reason (gui timeout for example). The queueitem is set to failed and then it gets back to the queue for retry. Next time when it becomes a TransactionItem again (by another robot maybe by another time) the robot will not know that this item already passed the first screen and needs to go to the second.
In my oppinion this could be handled by an updateable field (e.g. milestone) in queue management:
Get Transaction Item, check its milestone, based on do the processing at the right step.
When that step succeed
If this was the last step, set transaction to succeed
If not, then set the queueitem’s milestone to the next and
…Put back to the queue or
…Continue its processing on the next step.
If failed by AppEx, leave the milestone as is. The next time it will point still to the missing/failed step.
In some other cases transactions can go to the next step only if some other items already passed the n.th step.
These cases can now be handled by
- Keeping an excel file and there we update and maintain statuses. In this case the job can be executed only by 1 robot at a time since it can not be read/open simultaneously.
- Using multiple queues for each milestone.