In this instalment of the Robotic Process Automation Implementation Lifecycle series, we are continuing our focus on the Development phase, we will explore Development Framework & Exception handling best practices-
In a previous article, we examined the differences between Attended and Unattended Robots and how that relates to the Automation vs Robotics dynamics. We talked about how the scope of unattended robots more closely aligns with the idea of an “Automation script” being executed as a high-transactional back-office end-to-end process needing minimal human collaboration. How attended automation instead provides a much broader scope to justify the three necessary components for Robotics – i.e. Sense, Compute and Act, paving the way for ‘Personalized Software Robots’ that collaborate with humans in real-time to assist in day-to-day task executions.
From a development framework approach perspective, these two RPA robot types have many different requirements. We will discuss each of them in turn in the following sections.
For unattended robots, in particular, the main purpose of a development framework is to facilitate the effective processing of a collection of business transactions pertaining to an end-to-end process. Major RPA vendors like UiPath and Blueprism offer ready-built development templates that can cater for this specific need. Such templates act as an overarching framework to develop and execute batches of end-to-end process transactions which are either scheduled to run overnight or are posted into execution queues which typically have execution triggers based on number of transactions waiting to be processed.
The idea of such template frameworks is to provide a consistent basis for applying best practices around execution, exception handling, solution architecture, and results logging. The framework template on the top provides a high-level abstraction for a process transaction in the form of a few key components only such as – Startup and Tear down components, Transaction Data Set Up component, and the main transaction process component as shown in this example template based on Blueprism RPA tool –
By having common set up and tear down steps for multiple transactions, execution of transactions can be made more efficient unless there is an exceptional situation which demands an explicit teardown and re-set up following an execution from a failed transaction. A common mechanism for transaction data set up allows executing a batch of process transactions sequentially in a loop in a controlled way, for instance from a queue until all pending transactions have been processed. The main process component, represented as a few high-level process steps, can then be further divided into a process layer and an application layer. Process layer contains the fuller business process workflow for each high-level process step represented as one or more business process components or sub-processes. The application layer then contains an object-orientated implementation for each business process component in the process layer.
Objects can be developed on a per-application basis or per technology integration basis. An application object is implemented with a modular structure with methods, or functions, to cater for common UI interaction steps performed on a screen or a module within an application. By keeping the process layer and application layers separate in this way, any changes to the process does not then impact the object layer or vice-versa.
An exception can either be a System exception or a Process exception. A system exception may arise due to technical reasons such as synchronisation issues due to the delay in loading an application page, or some application object becoming unresponsive after a computational step. If any of the sub-processes encounter a system exception at an application layer level during an execution, it is recommended to implement retry loops so that in case the issue is a one-off then it can be isolated and resolved at the individual sub-process level. If after retrying at an application object layer level does not prove successful, then a system exception is raised at the overall transaction level. A business exception is to be raised at a process layer level in case there is a problem in the transaction processing. For instance, a problem due to changes in an application’s behaviour or due to issues in the transaction data. Business exceptions are not retried, and the overall transaction is terminated in such case to proceed to the next one.
To cater for the real-time processing of task-based automation requirements, while keeping the fuller scope of Personalised Software Robots into consideration, with the “sense” and “compute” capabilities being exhibited by a software robot rather than just the “act” capabilities (automation), it requires a level of intelligence to be built into the robot by applying AI technologies such as Machine Learning and Natural Language Processing. A level of intelligence that can also improve over time to personalise interactions with humans via channels such as text chat while working on office equipment or voice while on the go through personal devices. This is an area which is fast developing, having to converge Chatbot and RPA technologies in a specialised way. A conceptual framework to achieve such requirements using text chat is presented below-
A personal robotic assistant that accepts text input from users can parse that input using regular expression matching or natural language understanding APIs. To execute RPA automation via chat, asking specific questions can simplify the scope of potential activities a personal software robot would need to perform, thereby decreasing the complexity of the logic necessary to parse and understand in the interactions.
A user may type specific commands with a consistent syntax that is easy to learn for the robot and the expected outcome of each command is clear. A simple example pattern for commands like interactions for RPA activity can be in the following form-
<Command/Activity Name> –
Where can be represented as _
Different commands or activities that can be performed by a personal software robot can be:
Similarly, the personal robot may also send specific text messages back to the user such as-
A typical chat conversation with the personal robot would then be in the form of a series of messages to provide all the information needed for processing of a specific task.
There may be a number of scenarios and exceptions that the personal robot would need to cater to while interacting via a chat interface. For instance,
In the case of an exception that may arise out of interactions due to the incorrect input by a user, the robot may try a few recovery scenarios. For example, the robot may insist that the user answer the question correctly or disregard everything that the user had done previously and start from the beginning again for an activity.
It may be necessary for the personal robot to maintain state so that it can have more meaningful conversations by remembering certain things about the user or a previous conversation. The robot may look to maintain the Conversation state for tracking the context of the conversation. For example, if the robot has interacted with the user previously about an activity within the day, and has saved that previous information, then it does not need to ask the same information again from the user. The robot also may look to keep track of the User state, i.e. general information about the user such as name, preferences, reminder settings and so on.
Regardless of how much artificial intelligence the robot possesses, there may still be times when it becomes necessary for the robot to hand over the processing of an activity back to the user so they can perform it manually via the RPA platform. This may happen either because the bot does not understand the user inputs or if the request cannot be processed due to some technical exception in the robot’s processing engine.
Beyond the sense and compute capabilities, to process different types of activities, a personal robot would need different activity handlers. Such as an activity handler for searching an existing automation which would require the handler to query RPA platform’s database that contains information about all existing internal automation within the organisation, or to perform a search on an external marketplace by making an API call as an example.
For executing an automation, the bot would be required to make a call to the API of the RPA platform to either start the execution as attended automation on user’s desktop via the robot agent in the background, or to schedule the automation to be run on a specific VM, or to put the execution into an unattended robot queue to be processed overnight.
The below sequence diagram models how a personal robot, comprising of a Framework Service (sense and compute) and Activity handlers (act) can execute activities like, searching an automation with an internal automation factory and then executing that automation as a background process on the user’s desktop-
Read the other articles in this series from here:
The Robotic Process Automation Index
Contact us at SQA Consulting, to see how we may assist you in developing the necessary skills needed for implementing RPA projects.
