UDC_Digitalization in several stages with Robotic Process Automation

Digitalization is currently one of the most important topics in any organization. How can RPA support and accelerate this process?

We know from our own experience as a service provider in IT consulting: The public sector – as well as the financial sector – has the problem that systems are often outdated or cannot be easily replaced by new ones. If, for example, technical interfaces do not exist or individual applications cannot be exchanged, efficiency and the quality of data might suffer.
Here is an example:
Suppose there is a government agency that maintains the data of its supported users in multiple systems. This can be a web application in the form of an intranet/extranet for address lists, a business system on a mainframe with MVS, data in a CRM system and users in an ITSM software. If a user calls the user help desk of this authority and wants to have his or her personal data (name, address, telephone number, bank details) changed, the employee in the authority must maintain this data redundantly in the systems mentioned above as examples. This is not only cumbersome for the employee and costly, but also prone to errors due to the higher probability of a typing error, for example.
Since either no technical interface exists or the implementation would be too expensive or time-consuming, it is not feasible to implement an application in which this data is changed centrally, and all other systems are updated automatically.

Nevertheless, how can RPA to solve this problem of digitalization?

RPA - Robotic Process Automation - is currently in great demand. There are various providers in this field, including UIPath, Automation Anywhere and Pegasystems.
Think of RPA as small robots that are loctedsit in the workstation computer or on a server and take over simple, repetitive steps that were previously done by an employee.

Attended versus unattended Automation

By taking over these simple repetitive assignments, a robot in the form of Robotic Desktop Automation (also called Attended Automation) can assist an employee and realize tasks such as copying data from an Excel sheet into an application. If we return to the example above, an RDA offers, for example, a form through which the employee of an authority adjusts the personal data of the user, and the robot (after confirmation) calls up all subsystems and enters the values - as the employee would do - individually. Here the employee "supervises" the robot, hence "attended".

On the other hand, there is also Unattended Automation, which runs in the background, e.g., on a virtual machine or on a physical server. Here the important difference is that the robot can work without the human. Let's refer to the previous use case of a citizen wanting to change their data. In this implementation, let's imagine a government agency that is more advanced in digitalization and has mapped and automated its processes using a platform solution by pegasystems, but also still uses older systems without technical interfaces.

Now the user logs on to the pega platform of this authority, starts a process (case) "personal data change", and enters the new data. After the user or an authorized person checks and confirms the data, the process continues to run and perform various tasks until it reaches the stage where the subsystems or older systems are to be updated. Now the unattended robot picks up the task from the queue and updates the person data in the older systems, just as an employee would do. Of course, in this process (a so-called case) a confirmation may also be sent to the user telling them that their data has been updated successfully.

Value added by Robotic Process Automation

Understandably you might now be asking yourself, what added value RPA offers. However, this question is not easily answered because the answer depends on several factors. Here, for example, it plays an important role which application landscape and cases already exist, and which costs arise with a modernization or an implementation on a technical interface basis. In addition, it must be determined to what extent RPA can be considered a solution. After all, in the case of very dynamic user interfaces that change daily/weekly and contain elements that cannot be firmly assigned by an ID or certain properties, RPA may not be the ideal solution.

RPA provides a first level of digitalization, though it should not be viewed as a "superficial solution". As an IT guy or developer, one is clearly aiming for a solution where applications communicate with each other via technical interfaces (API's), securely, encrypted, etc., without simulating user interfaces. Nevertheless, RPA is an important step in the right direction and brings many benefits such as cost/time savings and higher data quality.

Development in the world of Pega RPA

In the current version 19.1 (as of November 2021), pega RPA is developed in the MS Visual Studio environment. Pega provides either a plugin for Visual Studio or a complete package for this purpose. As far as the IDE is concerned, pega is on the same path as the UIPath solution, which also develop with an MS Visual Studio plugin.

So, what is the best practice or standard way of development?
After a thorough analysis it should be known which technologies an application uses and how exactly it is positioned in the business process.

According to this information, adapters must first be connected, such as the WebAdapter for applications that run via Internet Explorer, the UniversalWebAdapter for applications that are accessed via Chrome or Firefox, or the WindowsAdapter for local Windows applications. In these adapters one configures exactly how the respective (web) application is accessed, which properties it has, etc. Like an adapter of a phone charger that adjusts voltage and electric current values, in this case it adapts the access to the application, thus forms an interface to the application.
Depending on the adapter, the interrogation (the process of inspection and recognition of UI-elements in pega robotics studio) also differs, as these are different in each application. From a technical perspective a button in a Windows application is not the same as a richfaces button in a web application, so an appropriate adapter must be used to ensure that the elements are recognized accurately.

Figure 1: Object Explorer. Source: PEGA Academy

The next step is to interrogate the UI controls (buttons, text fields, drop-down menus, etc.) and create the corresponding tree structure in the Object Explorer (Fig. 1). For these elements, or their properties/methods/events from the Object Inspector (Fig.1), one drags corresponding tiles into an empty field in the Designer, connects them and thus creates a flow and process (Fig.2). The entire process resembles a BPMN.

Figure 2: Process illustration. Source: PEGA

As an observation: everything that has to do with Windows, .NET and corresponding applications/forms works well, while development for web browsers like Firefox and Chrome is a bit more cumbersome, as you need plugins/add-ons for the browsers  and access them differently (different adapter) than Internet Explorer.

However, Pega has already introduced and released a proprietary development v21 of its IDE. A preview version is available. With the new version, it is clear to see that they have moved away from MS Visual Studio and thus simplified many things that had to be accounted for with MS. Also, the interrogation of the UI elements as well as the topic of the adapters have been improved. It remains exciting, and for sure: There is still a lot to discover in this world!