I see that you have implemented Set Transaction Progress in the new version! I haven’t looked at it too closely yet but assuming this is the progress update that we asked for a while back??
Me again. It seems that the Transaction Progress is not persistent once the status of the queue item has been changed. E.g. if set back to New or postponed any update to the Transaction progress is lost.
Could you check this please and amend for next version?
There is a lot to improve when it comes to queues. I need to manage workload and I cannot use half of these activities… I am a bit disappointed with UiPath, because I really enjoy programming with the tool and doing RPA.
you cannot set a transaction to “In Progress” unless you use the activity “Get Transaction Item” (which only supports random choice of queue item - the first in the queue)
the only activity that allows filtering the type of item u extract cannot set a transaction to “In Progress” (“Get Queue Items”)
transaction progress is only relevant for the RPA administrator/auditor. The robot cannot make any use of this data
Removing an item from a queue on orchestrator does not delete it, it just changes the status to “Deleted”. If you want to remove it, you have to delete the queue an create a new one with the same settings
Im sure I would find other issues if I kept on going. I dont want to be disrespectful to the hard work of UiPath’s employees as im sure I would not do better, but this is almost useless the way it is right now (the queues package in UiPath studio)…
If I am wrong, please enlighten me, as it would be very useful for my current project. I really want this technology to be successful, because I see potential in it and I hope to benefit from this opportunity. Otherwise, one year of my life has been wasted.
You can do things to ensure that the item you place in the queue gets picked first, e.g. use priority. Not often that you need to do this but there is a way.
What do you mean by filtering? There are ways in which can use the APIs to do things that you perhaps can’t using the existing activities.
The transaction progress was something I requested a while back but when it was implemented it wasn’t persisted to the database, this will be updated in a future release
Why would you ever want to delete an item? This removes auditability. If you do want to do this then you can run SQL statements against the database - however, you risk breaking the dependencies between underlying tables.
The problem is this activity does not change the status of items from “New” to “In Progress” when it extracts them from the queue.
3
Transaction progress is not the same as transaction status. I was talking about transaction status.
4
Because if the item fails and I want to retry the item by running the automation again, the automation inserts the item back into the queue. But this time it fails because of the unique reference constraint of the queue. So the queue has to be changed to non-unique.
Now imagine the robot retries and inserts the same item twice (due to a bug). Now that item is processed one time too many.
Getting this back to the original topic a second. It seems that the persistence of Transaction Progress is now fixed in the latest release BUT (I have been told) if you postpone the queue item it wipes the Progress. Can you consider whether actually it would be better to retain this information? For example, I’ve done steps 1 and 2 but need to wait X days before I can continue. However, I need to restart from Step 3.
If you have retries on the queue then Orchestrator will automatically retry the case and reset that item to new. You shouldn’t be adding the same item to the queue.
Sorry, if I’m not understanding perhaps if you could provide a specific example of what you are trying to do that may help.
Ultimately the queue mechanism has worked for us in many real projects and is flexible enough to achieve the results we need.
Also, there is now an activity for get All Queue items which allows you to run queries - this may be useful to you.
Hi there @richarddenton,
You are absolutely correct.
The feature is soooo close to being perfect, but has one minor oversight.
Setting the progress and failing the item (granted queue retries are applicable), creates a new case, with the same information/history, which can be pulled and its progress retrieved!
This means we can more accurately perform retries, directing the case to the relevant segments of the process.
BUT, as you’ve noted, postponing the item does not achieve this
If you set the progress and then postpone, the item is reset to ‘New’ and the progress is lost.
Outside of this, the features now works fantastically and will potentially alter how we design/develop
Hi, I am trying to use this “Set transaction progress” feature, but my problem is I am unable to read it back to the process. I just did a little test where I use Get transaction item and then Set transaction progress, followed by a message box to display the progress of the transaction item (I have tried with transItem.Progress and transItem.Progress.ToString). My problem is that even though I can see in Orchestrator that the progress has been altered, if I click View Details for the transaction item, then the message box does not display the progress (just an empty string). I also tried giving it a few seconds waiting time after setting the progress in order to let it refresh, didn’t work.
Unfortunately Progress as mentioned is reset as soon as the status is updated to anything other than InProgress.
A work-around could be to set a progress attribute in Output and change Transaction Status, you can use this to pick it up and work with it.
If you wish to delay this at a given level of progress, you can also Postpone Transaction just after the setting the status and it will retain the Output table. However, you can’t extract the Output table from the QueueItem object from the VB.net object they’ve made. However you can use the API to extract it as follows in the HTTP GET request Orchestrator activity:
"odata/QueueItems?$filter=Reference eq '<<<insert reference value here>>>'"
Then deserialize the JSON using the UiPath Web Activities module then filter down to Output using:
jsonDictionaryDeserializedVariable("value")(0)("Output")("<<<Output field value>>>")
Is there an endpoint that can be used to set a Transaction status to “In Progress” via the API? There are requests to Set Transaction Progress, but this requires the Transaction to be “In Progress”.
Ideally I’d like to be able to start a Transaction and then report the Transaction as Successful or Failed via the API… I’m not sure if I’m missing something or if it’s just not supported.
EDIT: Nevermind, I figured out that I need to use the odata/Queues/UiPathODataSvc.StartTransaction endpoint and the Robot Identifier is the queue item Key and the Name is the Queue Name… The Documentation I was looking at felt a little misleading with this.
I thought that worked based on the response, I was too quick to assume it was right. It instead created a new Transaction in the queue in question rather than setting an existing item to “In Progress”
I think there may just be a misunderstanding of the purpose of this. Originally, the problem was that when the workflow encounters an error, any information that has been obtained and stored in a variable is lost. e.g. “processed application, saved customer details, send staff email”. This is really useful information to send to the end users.
The hope was that using Set Transaction Progress would send this information to the database periodically (i.e. add multiple set transaction progress activities throughout), and then after the error has been thrown in the Main.xaml use this information in any report or alternatively be able to reference this information in Orchestrator. However, the only way to access this information after it has been submitted is via an API call to the database.
Yeah we can use Get Queue Items…but it’s a bit hacky. Josh’s idea above was that you could reference queueitem.progress property but not sure whether data will be committed to the db at this point…