well it was addressed, delete was implemented, you just dont like the way it was done… anyway only 2 votes from that, means no one was very interested on it…
actually I am quite interested in it. Any queue that is set up with Unique reference, cannot have the same queue item uploaded until and unless that “In Progress” item has been dealt with. There is no way in orchestrator to deal with it apart from deleting and recreating the queue.
Dear UI Team,
I echo the same. There should be some way to delete the In Progress queue item.
I agree on this.
Please let us manually delete an in progress queue item. It is not good practice that you should delete the whole queue to get rid of one item. You loose all history of transactions which are often used for statistics.
Is it easier to implement a solution where you can flag an “in progress” item as failed/abandoned?
@bcorrea I think this thread adds to the two votes you are referring to.
Dont forget that i am not against you in any way, i am an UiPath user just like you, the work i do here is voluntary… But i just dont see that enormous need to actually remove an item from the queue, just because it failed… Even when you talk about statistics, remove an item from the queue also messes up the statistics…
We (@otico and I) are recent converts from BluePrism. In BP an in progress queue item can easily be first stopped / aborted and then it can be deleted by the user. The database / queue will retain these queue items. This saved us a lot of time when debugging both during development and production.
We looked at this thread and we want to help with a workaround. Our approach is -
Get Queue Items: Get all your queue items with status “InProgress” - Inumerable output
For each QueueItem (Inumerable)-
Set Transaction Statusto “Failed” with a given
Reasonin properties tab
Get Queue Items: Get all your queue items with status “Failed” - Inumerable output
For each QueueItem (Inumerable)-
Delete Queue Item
We tested it on Orchestrator On-Prem v20.04 and it works . The deleted queue items still showup in the Orchestrator Queue, which is exactly how it should be. It is always best to have this traceability. We did not have to delete the queue.
Here is the solution file: DeleteInProgressQueueItems.xaml (8.2 KB)
This is a workaround using official queue activities, that said, please ensure that you do not run this flow when one of your robots is running a dispatcher / performer process linked to the same queue. Also, if you use this approach at the end of REFramework (to keep the queue clean), ensure you have necessary routines to identify which items need to be sent to the queue next time the dispatcher runs.
If you want to get the ItemData for the deleted items and add them to the queue as a new Queue Item, this is possible too. All you have to do is parse the inumerable resulting from Step 1 or Step 3 and get the data associated with the failed/deleted item and pass it to the
Add to Queue activity accordingly.
Hope this helps!
I second @postwick on the notion that “In Progress” queue items should have an option to be “Removed” just like Successful and Failed queue items.
I find it frustrating to have to delete my entire queue multiple times because my queue item with unique item reference can’t be recreated, due to the hold on an existing in progress queue item. @UiPath please consider enabling the “Remove” menu option for “In Progress” items.
I don’t want the item to be taken from the queue after removal, just move it to a “Deleted” state.
Even had the misfortune of having to explain this to the client because I couldn’t simply delete the in progress items. They queried me why there are “in progress” items on the queue, while my process isn’t even running (at the time) following an process exception which couldn’t set the items to Failed.
I can confirm, that @jeevith’s way is a good way to handle items with status ‘in progress’. I must confess, that it would be easier if there would be a way in Orchestrator to change status or delete them, but if it is not possible, I did it another way:
I used some similar steps, I just wanted a way to “restart” them, when they are in progress and the bot failed somehow. So I
- Get Queue Items with filter ‘in progress’
- For each item I set the status to ‘new’
- Get transaction item and run the bot again
I use the same process but it still is a pain that it’s not built-in Orchestrator. Every time I run tests, I have to run my workflow to delete/reset all in progress transactions which is a pain when I could simply open Orchestrator select all in-progress transactions and click a delete button or similar.
We are glad it was of help to you.
We feel your pain. Out approach currently is to use the suggested workflow as one of the functions in our
Debugging Suite. A debugging suite makes it easier for us to maintain robots in production.
Other functions in the
Debugging Suite can be use are Encrypt / Decrypt, adding dummy data to test versions of application, testing API etc.
Can you please explain your debugging suite in terms of Orchestrator terminology? I would like to consider such an idea in my org.
I also second that it’s inefficient to constantly have this invoked workflow file to clean up any in progress queue items created while developing in studio.
I would also say the original post could have been written nicer. UiPath’s development and community engagement isn’t as bad as Microsoft’s, but this definitely a much requested ask as this product becomes more citizen-driven.
The idea with the
Debugging Suite is to have various useful workflows packed into a single process already linked to the same tennant/folder on Orchestrator. This way Debugging Suite will have access to the production assets and credentials. The Debugging Suite will only be for Debugging and not developing or editing workflows. This comes in handy when Production robot has exceptions and it makes fire fighting a little easier!
Depending on the process you are working with, you can decide what kind of debugging workflows would be necessary to minimize the downtime on a production robot.
Lets say you have a process which stores customer data in the queue item data and you use the Encrypted string of Customer Account Number as a reference.
An exception on a queue item will provide the Encrypted string of Customer Account Number
You can then use a workflow from the Debugging Suite lets say “DecryptCustomerAccountNumber.xaml” and find out the Customer Account Number for further debugging
A queue item is stuck at In Progress and you want to set it to new.
The workflow used in the thread, which converts such items to New
You need to quickly make an API request using the data from the Queue Item
You could have a workflow “DebugProductionAPi.xaml” which is already connected to your orchestrator and can get the required credentials and you as a debugger only need to be provide the required parameters. For example, the API call required Customer Account Number
So having a
Debugging Suite is a great way to be prepared for exceptions during Production.
And you are speaking of attitude? Interesting!
I am using an enterprise edition, which is $$$paid and I am still finding it frustrating to not being able to remove “InProgress” transactions, especially in the lower environments such as DEV or QA.
Please mark this as a Solution to this thread as long as there is no “official” way to deal with it. @postwick
I’ll consider it solved when there IS an official way to do it.
I agree with @postwick
Business and Support teams should be able to manage this through Orchestrator like everything else. They can’t/shouldn’t write code to do this.
If you can add queue items through Orchestrator, you should be able to remove as well.
This is totally unaceptable… perhaps you have checked if that user is a paying customer, and maybe he is not, but he can be working in a company that have paid for UiPath licences. Anyway… paying or not you should receive any critic about the product always as a opportunity to improve it.
I can’t either understand why we should wait 24 hs for a “in progress” transaction status to become “abandoned” in order to perform whatever we want to do with our data.
Same thing with the restriction of selecting a robot in queue triggers.
I agree the in progress thing is visually unappealing. Perhaps an explanation on why it just gets stuck there would be helpful for end users to understand (since even if you restarted the process in Studio, those in progress items don’t get picked back up ever again)
Your note of selecting a robot in queue triggers has been corrected in Orchestrator 21.4.0 (latest version recently released) to some degree:
You can add multiple user/machine pairs per job for 1 single trigger. (If you add three pairs, you then will run 3 jobs on those 3 robot users and the applicable Machine(s))
Making it so complicated wasn’t a good solution for the queue triggers. They need to just make it work the same as the time triggers.
Any ETA on this feature? Seems extremely basic, very necessary, and has been missing from the Orchestrators for years.