1. Introduction to RPA¶
1.1. What is RPA?¶
RPA or Robotic Process Automation are software base solutions designed to mimic the same “manual” path taken through applications by an end user. It is typically used to automate repetitive tasks previously performed by a humans as an effective way to cut costs, eliminate keying errors, speed up processes and easily link applications together. These tasks can be successfully modeled and converted into a business process and then automated using a combination of (UI) interactions, connectors to client servers, mainframes, database, web, and others.
1.2. Tools (OpenRPA/OpenFlow/NodeRED)¶
There are many tools available for automating processes using RPA such as UiPath, Automation Anywhere and blueprism. Our stack of tools (``OpenRPA, OpenFlow and NodeRED``¹) has many advantages and is obviously our suggestion for you. The reasoning for this recommendation is revealed in the next chapter, for now we will cover what each of these tools do and their outcome.
¹ - We’re going to refer further to the OpenRPA, OpenFlow and Node-RED stack as OON.
This tool is basically the main environment where the processes are mapped and designed to fulfill the inherent task at question. Think of it as an
IDE - Integrated Development Environment for creating workflows. It is where all previously mapped activities will be implemented - such as clicking a message on a mailbox, typing content into an input form.
It is also the software you’re supposed to use to export all your workflows into a repository that will manage orchestration and input. The software we’ll use for that is OpenFlow, which comes next in this discussion.
OpenFlow can function as both a centralized and a decentralized platform that exposes a secure database, by enforcing Access Control List on all objects and offering on the fly encryption to those. It can also function as an orchestrator of Node-RED instances when run on Kubernetes and a lightweight orchestrator of robots. When an OpenRPA robot is connected to OpenFlow it will store all data (workflows, detectors, credentials, and state) inside OpenFlow. The same also applies when a Node-RED instance is connected to OpenFlow: it will store all data (flows, state, session, and credentials) inside OpenFlow as well. Finally, OpenFlow also offers many different ways to add human interaction to the table, either by using the built in Form designer (and calling them via Node-RED workflows) or by remotely invoking OpenRPA workflows directly on the website.
Node-RED is an event based workflow engine original designed to handle telegram messages in an IoT installation, but the big community around Node-RED has expanded the functionality to also integrate to traditional automation like PLCs, and more than 2500 IT systems and cloud offerings. When run as part of OpenFlow, we add easy orchestration, load balancing and enhanced security feature to the platform. Node-RED also functions as the orchestrator of OpenRPA robots via OpenFlow. Node-RED allows robots to interact with all the IT systems supported by Node-RED (hardware devices, APIs, online services, much more!) by simply wiring flows together. Lastly, OpenFlow also makes use of Node-RED as its backend to run flows for the forms created by the Forms designer.
1.3. Why OpenRPA/OpenFlow/NodeRED?¶
Our reasons for using the OON stack are presented in-depth below.
1.3.1. Low code concept¶
Low code concept means there is no technical or programing knowledge required to perform a desired task, i.e. you can simply just drag a box and input a few parameters for it to become fully functional.
low code refers to platforms that resort mainly to GUI-focused interfaces which assist users in the development of a BPM without necessarily requiring basic programming knowledge. These applications use heavy visual modeling in favor of coding to aid in the process of designing and implementing processes.
Low code development platforms have a very gentle learning curve and are often designed with UX-oriented practices in mind. It is a fact that it also helps the user to advance rapidly and design and deploy working processes with few caveats.
² - From now on, we’re going to refer to low code development platforms as LCDPs.
1.3.2. Time to market¶
The length of time between a product being conceived until it’s completion and deployment is significantly higher using a common application development process in comparison to LCDP. This occurs because there are far less steps involved in this cycle when LCDP is used. As an example, code-related unit tests are not needed, since all the parts of the software used to build the application are already tested and integrated within the framework.
In our stack, this also means it’s easy to prototype and creating something actually functional - due to LCDP programming - and the migration from prototype to an actual production product can be easily achieved. This is provided by the OON stack framework native integration and easiness of use.
1.3.3. Framework vs “extra work”¶
The OON stack significantly minimizes the amount of work needed to be done to implement a final product. This is due to the many features embedded within it, such as privilege and access management, embedded MongoDB database, safe credentials and form. Which is now discussed.
22.214.171.124. Privilege and Access Management¶
OpenFlow provides a readily integrated privilege and access management interface which is further discussed in the Roles chapter in the OpenFlow’s section. It makes possible for the administrator to create users and assign roles to these users which limit - or expand - the features they can access. There is no need to configure an user for every workflow and set the permissions accordingly, you only need to create a role and assign their given permissions.
126.96.36.199. Embedded MongoDB Database¶
The fact that there is a central database to the stack provides an easy way of creating KPI - Key Performance Indicators, reports and dashboards, graphs, and records of the data processed by the agents. It also measures the effectiveness of robots and their accuracy but remember you can only manage what can be measured.
You can also save files in the cloud and use them as shared files - such as a form presented in a Word file. It also has methods for saving files for future usage - as an example, for tasks that take too long or tasks that are fragmented between many steps/workflows. This provides a centralized way of handling file management.
188.8.131.52. Safe Credentials¶
Our safe credentials management system provides an easy way, to share, insert, update and delete credentials between systems and robots using the
SecureString class¹. Everything is automatically managed, so if you need to store a specific credential used by a workflow, you do not need to worry about the security of the storage system.
OpenFlow also provides forms, a user-friendly way of sending input to a workflow by creating dynamic webpage. It gathers all the input a user should give so the robot can use it for its processing and execution. This means you do not need to create a webpage just to gather data from the robot but you can create a form and make it public - or give its acess only to a few roles - so the end user can enter the input.
184.108.40.206. Message Queuing¶
Using the AMQP functionality exposed by OpenFlow, NodeRED is able to work with queues and tasks in the OON stack. This is used for distributing workload among many NodeRED instance and/or many robots, that needs to run the same workload. This makes the workflow more resilient by giving higher fault tolerance (removing single points of failure) and more elasticity by making it easy to add more nodes/robots to help run the workload, all automatically.
220.127.116.11. Built-in Functions¶
Many universal RPA activities are already shipped built-in inside OpenRPA - ready to use. For example, reading an excel file, opening a file, browsing a webpage.
1.3.4. How the tools integrate¶
The development process flows through OpenRPA -> OpenFlow -> Node-RED.
In OpenRPA you design the workflows which will execute the desired RPA process.
In OpenFlow, you manage them and also create forms for external input for the user.
In Node-RED, you wire both of them together in a way similar to building a flowchart.
Think of it as the OpenRPA workflow represent the players in a concert, OpenFlow is the maestro, or conductor, and Node-RED is the sheet music.
Scaling products with the OON stack is much easier than usual. Given that orchestration is directly managed by OpenFlow and assisted by Node-RED. It is also much easier to deploy, verify and provide maintenance to robots.
When you deploy a new change on any of the three applications (OpenFlow, OpenRPA or Node-RED) they are instantly applied to the whole environment - online robots will fetch the changes automatically and offline robots will do it the next time they get online, the same for all information used by NodeRED (such as workflows, permissions, forms, etc) - worry free. This is due to the main repository from which the robots & applications gather their data from: OpenFlow.
OpenFlow can handle a limitless number of robots thanks to RabbitMQ¹. The required technical specs for the server running OpenFlow/Node-RED it are intensely low.
OpenRPA agents can scale up by installing OpenRPA on different physical or virtual machines, or by using HDRobots extension where a windows terminal machine can run many users/instances simultaneously. Now, if a given process requires no GUI - in other words, all processing can be done without the need of keyboard, mouse or image recognition, a single instance of OpenRPA may run many workflows in parallel.
1.3.6. Security/No exposed code¶
No code is exposed to the end-user or agents, since there is rarely any code written (thanks to LCDPs) and viewing of the code itself can be disabled if needed.
For credentials, OpenFlow supports username/password, OAuth and WS-Federation to authenticate users. NodeRED uses WS-Federation to authenticate users from OpenFlow. Using OAuth/WS-Federation will usually improve security a lot, since it allows you to better manage and control the identities of the users in your favorite IDP solution.
There is also no hard limitation on the number of existing of user or agents, hence each robot or OpenFlow user may have its own username/password credential - as many as you may need.
Credentials may also have differents level of permissions (read/edit/remove) for each object (workflows, projects, forms, etc) and, last but not least, each password is well encrypted by using cryptography ciphers, which makes it even harder for someone to attempt an authentication attack.