Work Item management in the Control Room
Our vision for work items, in short, is "Built-in robustness, connectivity, scalability, analytics and reporting to ANY automation use case ".
Multiple aspects need to be taken into account when building business-critical RPA processes. Just having the robot to run is only a part of the bigger picture, and typical questions that arise during development and delivery are, for example:
- How do I input data to the robot or get out results?
- How do I scale the workload efficiently over multiple Workers?
- How do I send the failed items to be processed manually?
- How do I automatically rerun only the failed data items? I don't want to rerun everything.
- How do I integrate system X with process Y?
- How can I be sure that the robot has processed the right information?
- What happens when the robot execution crashes mid-run before the log file gets generated?
- How can I be sure I don't lose any data if the robot crashes?
- How do I measure the value generated by the process?
- My process executes 500000 transactions in a month. How can I stay on top of what is happening?
- I would like to know how many X, Y, and Z the process has gone through today. How do I do that?
Typically finding solutions to all these questions would take a lot of time and resources. Instead of having to develop custom libraries, setting up databases, monitoring systems, analytics software, and figuring out how to use and maintain all that in the future, Control Room work item management in conjunction with RPA Framework provides a standard and best practice answer to all of these questions with a minimal effort from the user.
Work items in a process
Work items can be individual pieces of data that your process handles — invoices, URLs, or customer support tickets. By using work items to handle every data item processed in the process by work item basis, the state of processing can be kept always up-to-date. Even if the robot crashes unexpectedly, the state of each work item stays known and can be re-processed or handled manually.
In the Control Room process overview, you have visibility to the state of all the work items in your process, in addition to all the process runs and their states.
The process graph contains the following sections for work items:
- Inputs, this section contains all the “New” state work items in your process that are waiting to be processed. Nothing is shown if the process has no “New” work items.
- Work items in Steps, these sections contain all the work items that have been processed by the step (done, failed) or are currently processing (in-progress), or are in queue to be processed (pending).
- Outputs, this section contains the “Output" work items that have been created from the last Step to be the process Output. Not all processes create “Output”, so this section can be empty.
If we click any of the highlighted work item counts, we will be directed to the work item management view with the correct filters applied.
Work Item management and handling exceptions
The Work Item management view contains all the work items in the process, and you can apply different filters based on what you want to see. You can also customize and resize columns to better see the data that is important to you.
In this example (based on the Web Store Orders example in Portal), we will handle a failed work item manually. To do that, we click the “failed” section on Step 2 (Process Orders), since we want to get those orders processed successfully.
After clicking the failed items, we will land on the work data manager. What we see here are all the failed work items in this step and more data about them. Each one of these work items represents one order in the business process.
By glance, we see some Business exceptions and some Application exceptions (see Exception Types), which have been marked by the exception handling code done by the robot developer along with an exception message.
Let’s open a work item with a Business exception by clicking it to see what could be the reason.
Aha, it seems that there was an error in the input data, so the robot couldn’t process the order successfully. Let’s fix that and retry the item.
By editing the work item payload data (you can also use JSON editor if you like that more), we have fixed the typo, and the data should be good.
We can now save and retry the item by using the controls at the bottom of the screen, and the item will be retried in the context of the same process run after the click of the button.
We can now see from the process page that the work item we just fixed is now being processed again, and should be processed successfully.
In case of technical exceptions, it is useful to expand the step log to be visible on the side by clicking the eye icon next to the log.html. This way, we are able to troubleshoot execution details without needing to dig deeper into the step runs and run artifacts.
In case you want to retry or mark multiple items as done at once, mass actions are also available by selecting multiple work items.
Work item states
The work item is waiting in the process input, and not being processed at the time.
The work item is part of a process run, and queued to be processed in the next step.
The work item is currently being processed by a robot in a step.
There has been an exception in processing of the work item, and it needs further action.
The work item has been processed successfully by a robot in the step, or has been marked explicitly as done.
Work items created from the last step in the process are considered as process output work items. They can be conveniently be accessed for further usage if needed via UI or API.
- Development guide for using work items
- Keyword documentation for RPA.Robocorp.WorkItems
- Example Robot — A robot showing the producer-consumer work item model on the Robocorp Portal