In this next instalment of the Robotic Process Automation Implementation Lifecycle series, continuing our focus the Development phase, we will discuss about 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 align 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.
Development Framework Approach for Unattended Automation
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 – Start up 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 tear down 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.
Development Framework Approach for Attended Automation
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> – <Automation Name> <Attributes>
Where <Automation Name> can be represented as <Application Name>_<Action><Entity>
Different commands or activities that can be performed by a personal software robot can be:
- Searching for an existing automation either from an internal automation library within an enterprise or from an external marketplace
- For example, to search for an automation to create a ticket in a Zendesk application – SearchAutomation-Zendesk_CreateTicket
- Requesting for information about an automation that the personal assistant can access such as–
- Type- Attended or Unattended
- Automation interface- UI or API
- Application name
- Average Execution time
- Input data requirements
- Failure rate
- Execution requirement – User Desktop or VM
- For example, ViewInformation-D365_CreateCase Type
- Executing an automation in real-time
- For example, ExecuteAutomation ServiceNow_CloseIncident
- Scheduling an automation to be run later
- For example, ScheduleAutomation ServiceNow_CloseIncident 10/06/2020 05:00 AM
Similarly, the personal robot may also send specific text messages back to the user such as-
- Greeting messages- Hello, Bye, etc.
- General information messages – Weather, Time, etc.
- Information about the state of the RPA platform
- Previous day’s activity statistics of the user– No. of bots executed, how many passed/failed
- Reminders pertaining to RPA– execution needed for a specific automation
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,
- How to ensure that a user does not go off track in a conversation with the assistant?
- Can a user go backwards in a conversation with the assistant?
- How does a user “cancel” an activity during a conversation with the assistant?
- What if the user realises that the assistant is unable to understand the user’s request?
- What if the robotic assistant identifies that the user inputs as incorrect?
- What if the robotic assistant becomes unresponsive due to a technical problem?
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.