Robot Creation (RPA) with AutoTest Tools

Authors: Lebedev A., Nazarova E. The

need to use robotics arises for various reasons: the need for new applications to exchange data with applications that do not have an API, the rapid integration of heterogeneous applications, the automation of routine processes with a minimum of costs, etc.

Traditionally, robots or RPA (Robotic process automation) are built on the basis of ready-made frameworks. Here, the leaders are, in our opinion, products from UiPath, Automation Anywhere, Blue Prism, NICE. These are proven platforms that allow you to make quality decisions. However, not cheap. You need to pay for licenses in the number of future jobs, pay for customization for your specific task and commissioning. In some cases, you can get cheaper. We managed, and are ready to share experience.

Some time ago, in one of the banks, the Agile transformation began. New approaches to developing applications for the needs of the bank. To show others the way, they formed pilot teams to develop new products.

The bank has traditional key systems for conducting accounting and operational activities. Work with the products of the new teams was implemented in the form of microservices, which should exchange data with key systems. And development in teams started pretty quickly. But the problem is that traditional approaches to the release policy of key systems did not fit into this pace. And the API for the new microservices was in the plan for the future.

It turns out, like Pechkin’s, “I brought you a package, but I won’t give it to you.” In these conditions, representatives of the pilot teams addressed our auto-testing team with the idea of ​​using UI auto-tests of similar processes to create robots.

Naturally, we first discussed the risks. The fact that when using autotesting tools they are, that the reliability of software solutions for testing requirements is lower than for payment system applications, it was announced immediately. But driven by the Agile wave, teams took risks.

The toolkit was used traditional and free: Java for development, assembly through Maven. To work with the browser, Selenium was used (the application where it was required to enter data has a web interface).

The main distinguishing features of the robot in comparison with the UI-autotest of the same process is the need for the correct handling of error situations and exceptions, integration as a subsystem via file exchange.

For the robot to work, a virtual server was allocated, a technical domain account, and a separate user was created in the system where the data was entered. With authority, like a living employee who performs similar actions.

A Jenkins agent was installed on this server, which allows you to run the robot. The report on the work of the robot was formed both in the form of a log of execution and in the form of an Allure Report. Both are available in Jenkins and do not require special permission to access network resources.

The work of the robot was structured as follows: a file with data for entering the system is placed in the input folder on a network resource and the robot is launched through Jenkins; it compares the records of the input file by the key field with the service file, where all the already processed records are stored, and selects only those that have not been processed yet. Next, the array of records is processed in a loop. Moreover, at each processing step of each record, exceptions and errors are processed (try ... catch) and process “drops” are noted in the resulting file. At the same time, the processing of the input array does not stop, we just go to the next record. As a result, when the processing of the entire array is completed, the input file is deleted, in the output there are all processed records with the result and runtime. Allure Report displays as information about the processing for each record,and a general list with the processing results of each record. This makes it easy to evaluate the result and localize problems, if any.



In addition, in the process of using the robot, it turned out that the flow of applications on peak days is quite large and in order to meet the acceptable processing time, a larger number of concurrent users are required.

The system has created several more users. Parallel execution was implemented using threads (Thread). The entire array of input records is distributed equally between the streams, in each of which processing is carried out under its own user. The results are written in one file and the report is also single. It's comfortable. At the same time, a single Selenium Server was launched, which can cope with the parallel launch of several browsers (according to the number of working users). We worked with the Chrome browser, respectively, chromedriver was used.

This is surprising, but during the nine months of operation, the problems were only due to incorrect input data. Technical problems arose only at the commissioning stage and were associated with the coordination of the encodings in the log and the expansion of the memory used when starting Selenium Server (delivered 1G).

After some time, for the same Agile team, another robot was developed. Its feature is that it does not start on demand, but works continuously by scanning the input folder. When an incoming file appears, it takes it into processing. Accordingly, the Jenkins agent is not used. If the process is successful, the input file is moved to the folder with the successfully processed files, otherwise, to the folder with the erroneous files. Unlike the previous robot, Allure Report is absent, but the execution logs are written to a separate file for analysis in case of any problems. And one more feature - the browser is forcibly closed at the end of processing and starts when the user needs to log in.

Thus, in some cases, when creating an RPA, you can get by with a noticeably cheaper way using the autotesting tools.