From the course: Complete Guide to UiPath RPA Development

About queues - UiPath Tutorial

From the course: Complete Guide to UiPath RPA Development

Start my 1-month free trial Buy for my team

About queues

“

- [Bryan] Before we put our hands on queues and queue items, I wanted to give you an overview in case you're not familiar with the concept of a queue. A queue is really just a container to hold items of work. And you can think of it as being similar to our Excel input file that we've used in previous sections. So you can see here I've got multiple rows of data that can have one or more values. And if you imagine the queue as a container or pipeline where we could put these items in order as separate objects, you can imagine somebody using an attended robot to fill our queue up with these items. And when that user was done, maybe some time would pass or maybe not, and then maybe an unattended robot would come along whose job is to process the items in this queue. Of course, that robot would have a looping mechanism and it would call out, next. And the first item in the queue of the appropriate status would be processed by the robot in whatever way the robot was designed to work. Once it was finished with that queue item, it would set the status to either success or failure, and it would ask the queue for a new item. It would process that item as well, according to the business rules it knows about, and then ask the queue for another item. It would work on that item and mark it as success or failed. And since it doesn't know how many items are in the queue, it would simply ask for the next item. Of course, if the queue is empty or all the items in the queue have already been processed, then the queue will simply return nothing and you would program your robot to stop when it gets nothing back from the queue. Queues can be created in Orchestrator, and we're going to see that in a lecture coming up. But as a preview, if you click on any folder in Orchestrator and go to its Queues tab, you can use this Add Queue button to create a new queue or even link from other folders. So if I click on this button, you could see the various properties we have, and the most important properties are going to be the queue's name, whether to enforce unique references, whether certain fields should be encrypted. And when you hover over this i, you see that the fields encrypted will be specific data and output data. And also whether any system exceptions will be retried and how many times they will be retried. The rest of these settings are more advanced and won't be the focus of this course. The queue names are case insensitive, and I think queue names are another opportunity to make use of our Pascal casing instead of having any spaces in the name. But that's up to you because queue names can have spaces. These work items that are placed into the queue can only be created by a robot, and we just use a UI path activity to do that. And as a quick update from the future, this one is no longer true. It is possible now to upload queue items manually. To do that, you would go into your folder, Queues, and find the queue and then click on these three dots and use this Upload Items option. This allows you to add a CSV file that has the appropriate fields and values and dates that match the formats articulated here. The work items can be prioritized or postponed or have a deadline. And the way we postpone or add deadlines is to use a .net function, like AddHours or AddDays, and provide the appropriate value according to your business rules. Once they're in the queue, these work items can be processed by more than one robot in parallel if you choose to do so. And of course, any robot that asks the queue for an item, the queue is going to return higher priority items first. And we'll see in a future lecture that the priorities are low, normal, and high. Items that are started by a robot but never finished automatically become abandoned. So Orchestrator has the ability to prevent a queue item from being stuck forever. Orchestrator also provides features that allow humans to review any failed items, and the human can mark them as verified or even set them to be retried again by another robot down the line. As I just mentioned, the work items can be retried if they fail, and this can be automatic or manually set. When you're creating a queue, you have the choice to specify whether those items will be auto retried or not, and you can even tell it how many auto retries to do before it gives up. And finally, Orchestrator provides really nice charts for work that has been done. And this can be useful for getting a visual sense of the volume that's being handled by your robots. And also, like this legend says, the total number of items versus how many the robot was able to handle versus what's called business exceptions or application exceptions. When you hover over these dots, it shows you the totals of any given type on any given day, and you can change the chart to show the last day or the last week, or even all activity for the last 30 days. And on this Orchestrator landing page, it shows charts for all of the robots combined. So again, those aggregated charts are available when you click on any folder and go to the Home tab. Near the bottom of that page is where that chart will show up. But if you want to monitor a specific queue, you would, again, make sure you select the desired folder, then click on the Monitoring tab, then click on Queues. And now you've got a timeline dropdown here with one hour, one day, one week, and one month. And all the charts and grids on this page pertain to the queues in this folder. So hopefully you're excited now and you have a better sense for how important queues and transactions are going to be for enterprise robots.

Contents