In the main we concern in the RPA area with automation in administrative environments, like finance, controlling or human resources. This is right and good, because there are many “treasures” to be discovered here. Furthermore there are other business processes that are less the focus of RPA at the moment, e.g. in software development.
UiPath has addressed this issue with its Test Suite. In addition to the three core components, Studio, Orchestration and Bots, there is a fourth component, the Test Manager. It offers the possibility to realize test automation with RPA, for the RPA workflows themselves and for other software developments. A logical step in my opinion.
The Test Suite offers a lot of possibilities to handle test automation for that kind of requirement, not all are realized so far.
In particular the Continuous Integration (CI) and Continuous Delivery (CD) options allows a connection to the “classic” development process, to support it. While we are still at the top of the test pyramid today, I believe that RPA will also offer opportunities to infiltrate the pyramid in the future more.
In my post One Size Fits All I describe the possibility, with different examples, to integrate applications via their Command Line Interface (CLI) into an UiPath workflow. This form of integration is just as valid as via an UI. This means that we can also use applications from development environments in this context.
Here are, more or less, two exceptional experiments:
FASM is a very powerful assembler. “It was designed primarily for the assembly of x86 instructions and it supports x86 and x86-64 instructions sets with extensions like MMX, 3DNow!, SSE up to SSE4, AVX, AVX2, XOP,and AVX-512. It can produce output in plain binary, MZ, PE, COFF or ELF format.” (Source: FASM Homepage > Download)
Normally, no one would think of compiling assembler code at the runtime of an RPA workflow and putting it to use in the context of this workflow. A possible use case could be when there is very specific extensive data to be processed that can be processed faster using processor-specific instructions, but the target architecture may contain variants. This allows a specific variant to be created at runtime, providing the flexibility to respond to changes in the future without changes to the RPA workflow.
To simply test something like this I created a CLI for FASM as a NuGet package and integrated it into a UiPath workflow.
First activity is the compiling of the assembler file and the last activity is the using of the compiled executable.
The output delivers the version of FASM.
And HELLO.EXE does exactly what is expected.
; example of simplified Windows programming using complex macro features include 'include\win32ax.inc' ; you can simply switch between win32ax, win32wx, win64ax and win64wx here .code start: invoke MessageBox,HWND_DESKTOP,"May I introduce myself?",invoke GetCommandLine,MB_YESNO .if eax = IDYES invoke MessageBox,HWND_DESKTOP,"Hi! I'm the example program!","Hello!",MB_OK .endif invoke ExitProcess,0 .end start
It is easily possible to compile x86 assembler code, in this example for Windows, on this way and use it in conjunction with the RPA workflow.
Do you remember Disk Operating System (DOS) - not to be confused with the Windows console. I mean the 16-bit executable, which today can no longer be executed with Windows. To be able to run this kind of programs today, I created a CLI around vDos. It “lets you conveniently run DOS applications by emulating an extended DOS PC in a window.” (Source: vDos Homepage)
A possible use case could be to test control systems of old knitting machines in a factory. Normally, these machines are operated for 30 years and more, so that the use of DOS as an operating system is still possible.
At first I developed a tiny 16-bit DOS program in Turbo Pascal 3.0 and 6.0 and compiled it to a COM and EXE. It delivers only Hello World and writes it into a file for data exchange.
To simply test this I created a CLI for vDos as a NuGet package and integrated it into a UiPath workflow. With the Invoke Program activity the DOS program is executed.
The first step is to get the path of vDos, to copy the DOS executable to its area. Next activity is to execute the program and to catch the data from the output file.
The output delivers the expected result.
Unfortunately it is not possible to use GetText with vDos or DOSBox, which I described here. They use graphical output windows, so OCR must be used here. Or it is necessary to use Computer Vision to control this kind of programs. However, I have not tried that.
Here an example with Tesseract OCR and DOSBox.
As you can see, it is also easy possible to use 16-bit DOS programs on this way and use it in conjunction with the RPA workflow.
These, perhaps far-fetched, abstruse experiments shows us what is possible in the context of an automation platform like UiPath.
- RPA can support software development in test automation area, without any doubts.
- Test automation with RPA will not only move in the End2End area in the future.
- There are no limits to the diversity of the Test Suite’s connectivity options. The limits are set only by our imagination.
- The NuGet package distribution system of UiPath is incredibly good. One package contains all necessary files and with clever programming everything can be achieved what is possible.
Even though the experiments are a bit specific, it was just important for me to take a look at this areas, to find out limits.