As we know, the Industrial Age from 1760 to 1840 paved the bricks for the information age. The mechanization of production using steam and water power led to mass production and urbanization in the industrial age. The need for improvement in various aspects of the product development cycle in the industrial age raised the demand for newer better technologies. Then came computers. The widespread use of computers and various communication technologies helped in the creation, storage, processing, and transmission of data. Thus, the origin of the information age. The time from the 1950s is generally categorized as information age. Not everything in the information age is perfect, there are still things to be improved. So new technologies and ideas to make it happen started to emerge in various parts of the globe. One of which is called RPA, Robotic Process Automation.
Robotic Process Automation, as the name suggests, is a technology that uses robots or bots to automate various tasks. Yes, you read right. Robots. But it's not the typical mechanical robot as you might imagine. But software bots. A software bot is a computer program that does some tasks as per the commands received from a human. So, not a physical robot! We can use the software robots in RPA to automate high-volume repetitive tasks, that are generally rule-based and trigger-driven. An example would be sending customized mail to all customers of an organization.
There have been a lot of tools developed in recent years in the domain of Robotic Process Automation, like UiPath, Blue Prism, Automation Anywhere, etc. UiPath is the leading one among them. It uses a graphical drag-and-drop interface which can be used to automate even the hardest challenges. There are a lot of features that are included in the UiPath platform such as Optical Character Recognition (OCR), Machine Learning, Computer Vision automation capability, API accessibility, etc. UiPath also provides a lot of templates to choose from, when starting new automation, to make the RPA-coding, testing, execution, debugging, etc. easier. One of which is the ReFramework or Robotic Enterprise Framework. ReFramework is a template that is available in UiPath that includes the best practices involved in development. We can use this template to automate the simplest to the most complex tasks.
The ReFramework Architecture…
As mentioned earlier, ReFramework is a template that is available in the UiPath RPA tool, that follows the best practices in RPA code development to execute repetitive tasks that follow certain rule-based and trigger-driven characteristics automatically, using software robots or bots. We can use this framework template to automate small to huge automation processes that may fall under various levels of complexity. It is a reusable and extensible process automation template that uses a concept in computer science called State Machines.
State Machines or Finite State Machines (FSMs) are widely used in various programming languages, like Python, and RPA to efficiently design and implement solutions for a wide range of requirements. In RPA, as in any programming language, the tasks that are automated using State Machines can also be automated without them. However, state machine provides a wide range of benefits such as enabling the possibility of structured automation, better error handling and recovery mechanisms, improved scalability and reusability, etc. State machines are utilized in RPA to automate repetitive tasks and business processes mainly because they provide a structured approach for defining different steps, decisions, and actions involved in completing a task.
The key elements in a state machine of RPA consist of States, Transitions, Actions, Conditions, Start State, End State, etc. The States are different phases in the automation process that contains actions or tasks to be performed. The Start State as the name suggests is an initial state from which state machine execution starts. It is where the Automation process starts. The End state similarly as the name suggests is the final state at which state machine execution ends. It is where the Automation process ends. This state also indicates that the process has been successfully executed and the desired output is achieved. Transition is the element that enables the flow automation processes based on certain triggers or outcomes. They are used to define the rules for moving between different states. Conditions check specific criteria to determine whether the transitions should occur.
There are 3 parts in each State (except for the Final state), Entry Block, Exit Block, and the Transitions.
The final state just has 1 part, Entry Block. Once the process reaches a state, the entry block is executed first. Then, the conditions for initiating transitions are checked. If any one of the conditions is met, the exit block of the state is executed, after which the process moves to the state based on the successful transition condition. However, in the final state, as the name suggests, there is not going to be any State after the final State as it is the end of the process. Thus, once the process reaches the final state, the Entry condition is executed, and the program ends. The ReFramework utilizes these elements in a state machine to design and implement efficient and reliable automation solutions. Along with this the state-of-the-art exception-catching mechanism greatly helps in identifying and rectifying the errors.
ReFramework is capable of operating based on a wide range of data sources, like data tables, lists, orchestrator queues, etc. However, amongst all the accepted input, ReFramework provides strong integration with Orchestrator queues. The main advantage of using an Orchestrator Queue input is that we can assign deadlines, prioritize certain items, etc. along with the option to retry failed transactions. This makes orchestrator queues way more efficient. It also makes way for processing transactions using different computers or machines. Two particularly interesting topics related to queues are Dispatcher and Performer. Dispatcher and Performer are necessarily just bots with a glorious purpose. As the name suggests, a Dispatcher is a bot, that dispatches the items to be processed. This means the dispatcher is assigned the task of adding items to the orchestrator queues, assigning priorities, etc. What comes after data is added to orchestrator queues? Yes, Processing it! Thus comes the performer. A performer as the name suggests performs some actions. Performer retrieves the queue items as needed and processes them. The ReFramework template is integrated with the capability of a performer. Dispatcher functionality however is added to the ReFramework template as the need arises. The main advantage of having a separate dispatcher is that we can add more queue items even when the performer has started processing existing queue items.
The Implementation…
The 4 states in a ReFramework template are Initialization State, Get Transaction State, Process Transaction, and End Process State. The Initialization state is the state where data is read from the config file and stored in a dictionary named config, assets are read from queues, applications are reset and initialized as required, etc. The Get Transaction Data state is tasked with the duty of fetching transaction data from queues or other data sources. This state also checks if a Stop request is received from the control. If there indeed is a Stop request, the code moves to End Process. The Process Transaction state is tasked with processing the transaction items, setting the status of transaction items, throwing and capturing exceptions, incrementing transaction number, etc. The End Process state includes steps for tasks such as logging out, closing applications, etc.
One other important part of the ReFramework template is the Config file. The config file is an Excel file in the Data folder of the ReFramework code that is used to store information regarding various configuration settings of the ReFramework code that we are developing. The necessary data, like the orchestrator folder name, queue name, logging details, max consecutive system and business rule exceptions allowed, assets, etc. are stored in the sheets Settings, Assets, and Constants of the config file. Other necessary information like folder paths, file paths, application paths, and other necessary information that corresponds to the current code that is being developed is also stored in the Config file.
As mentioned earlier, the ReFramework template is capable of working based on a wide range of input. But the most common type of data inputs are Queues and Tabular data. However, the ReFramework template is designed to work based on queues. Due to this, while going through the template, we will be able to see a lot of activities, arguments, and variables that correspond to orchestrator and orchestrator queues. Thus, developing a code that works with queues is much easier than a code that works with tabular data.
Going through the Initialization State, we will be able to see various activities and invoked workflows. One amongst them is the invoked InitAllSettings workflow. This is an integral part of the ReFramework code. This workflow is tasked with reading the config file and storing the data in variables. The config dictionary and asset variables based on the config file are created in this workflow. After this invoke activity, we will be able to see a few activities that correspond to the orchestrator. If we are developing our ReFramework code based on tabular data we can delete those activities. We can then see an invoked KillAllProcesses workflow, which originally won’t have anything other than a log message activity. It is recommended that we add code to kill all Windows processes representing applications used in this business process to ensure that the execution starts in a clean state in this workflow.
Another important invoked workflow in the initialization state is the InitAllApplications workflow. All the necessary initial steps to be taken care of, like opening applications, and logging in, if necessary, etc. are added in this workflow. We can also see a check to determine if the maximum consecutive system exceptions have exceeded or not in the initialization state. If it is exceeded, an exception is thrown and the state transitions to End State.
If the Initialization state is successful, the bot proceeds to the GetTransactionData State. The purpose of this state as mentioned earlier is to fetch a transaction from the list of items to process. By default, it is designed to work with Orchestrator Queues. The activities corresponding to this, are arranged in the workflow, Get Transaction Item, inside this state.
A GetQueueItem activity is used to retrieve one queue item from the corresponding orchestrator queue. But if was are designing a ReFramework template to work with tabular data(without using the orchestrator queue), we will have to replace the GetQueueItem activity with other activities. There is also another part in this workflow where transaction ID, transaction fields, etc. corresponding transaction items are assigned. An important thing to remember here is that if you are using queue items, to extract a particular field, we have to use the format, transactionItem.SpecificContent(“field name”). But if you are using tabular data, you just use the transactionItem(“coloumn name”) format. If there are no new transactions, or no more transactions left in the queue or the tabular data, the bot moves on to the End State.
Then the bot processes each transaction item in the next state, Process Transaction State. All the necessary steps that each transaction data has to go through are set in the process workflow of this state. The process workflow is arranged inside a try-catch activity, such that if errors or exceptions occur during the run time, it is handled properly. The two kinds of exceptions that are caught are business rule exceptions and system exceptions. Based on how the process workflow operates, the transaction status is also set. This is done in the SetTransactionStatus workflow.
In the case of the queue-based ReFramework template, If the process workflow executes successfully, the queue item is marked as successful, the transaction number is incremented and the bot continues with the rest of the transaction items. If a business rule exception is caught in the execution of process workflow, the queue item is marked as failed and the transaction number is incremented. The bot then continues with the next transaction item. In case of a system exception, however, the bot will mark the transaction item as failed and retry the transaction item as per the maximum consecutive system exceptions allowed by the user. If the maximum consecutive system exception allowed is reached bot moves to the End state.
If finally, no more transaction item is left to be processed, the bot moves to the End state, where as mentioned earlier, tasks such as logging out, closing applications, etc. are done. Thus, the automation ends.
Let’s Summarize…
As we have discussed in this blog, ReFramework is a powerful utility available in the UiPath RPA software that can have a great impact on our automation. It will greatly help in improving efficiency and reducing the errors and exceptions in our projects. The main components of ReFramework such as dispatcher, performer, queue, transaction, exception handling, etc. will help us automate even the most complex tasks easily and with provisions for automating across multiple systems simultaneously. The ease of use and integration of ReFramework with various other technologies make it a perfect solution to all our needs, making it the most reliable and scalable automation solution.
For further details, use the following links:
– UiPath ReFramework Documentation: https://docs.uipath.com/studio/docs/robotic-enterprise-framework
– UiPath Community Forum: https://community.uipath.com/
– RPA Training Resources: https://academy.uipath.com/courses
Augus Noble Thomas
RPA Engineer, Chisquare Labs
Comments