With the rise of Robotic Process Automation (RPA) as an antidote to dealing with the increasing workloads and inefficiency in helping humans complete their digitally-based tasks, there will inevitably be the case where a bot fails. If your bot is simply handling pulling data from other sources, and the bot is well-written—e.g. supports appropriate exception handling—then the user will simply get a notification that the bot did not complete its task and it can be re-run.
But what about scenarios in which the bot was updating systems and the bot stalls or fails in the middle of the updates? This is a tricky scenario. RPA is essentially non-transactional, which means that it cannot roll-back changes that have already been made in the middle of a bot execution if the bot cannot complete its tasks. We see this scenario growing not only around RPA but also in the rise of microservices design that calls a sequence of application programming interfaces (API) to update multiple services as part of a single task.
Planning for the Worst
There are solutions to this problem, but they take some planning and foresight to implement. If you need to update multiple systems as part of a complete transaction, for example, Salesforce.com and SAP, then you should design your bot to implement state management. I discuss how this can be done with Automation Anywhere in the blog post Handling Long-Running Tasks in Automation Anywhere. With a state management design, you will need to capture the activity and the last known state—either completed or failed. You will also want to capture (and appropriately store) the inputs for the bot to be able to compare later should this bot restart with the same data.
When a state management designed bot starts, you should attempt to pull identifying data from where you stored your state and see if this transaction has already been seen. In attended mode, this likely means “when a human is sitting there watching and it”, so if it fails, they are able to just run the bot again. In unattended mode, the bot may have been triggered via a schedule to start iterating over a data set or reading emails. Since the bot did not complete the task previously, the triggering data may still be stored – giving the bot the opportunity to re-run the task with the same data as the previous run. If this is the same request and it is marked as having failed, you can identify which was the last step completed and jump to the next step in the process. If prior steps provided input into this step, that should be saved as part of state management.
Taking a Creative Approach to State Management
If your business is uncomfortable leaving data in an indeterminate state, an alternative may be using the state management data to perform a rollback operation. If you decide that rollback is the approach you want to take, then you need to save the original data prior to your update from each of your prior states. At this point, each system will provide you with one of two options:
- Just update the record again, this time with the original data.
- Issue a compensating transaction.
A compensating transaction is a unique action that negates the prior update. For example, if in accounting you made an entry using a bot to debit $20, then the compensating transaction issues a credit for $20. This may be required for auditing purposes so that financial and human resources data cannot be manipulated.
Conclusion
Using RPA to update disparate systems can alleviate a lot of tedious labor-intensive and often error-prone activities for humans. However, this takes planning as no technology is perfect and anytime you’re communicating with another application, there is the potential for failure. With proper planning, you can add steps to your bot to remediate failures and ensure that your data stays consistent and accurate.