This week I’d like to admit something to you. When I called Rafał to discuss the issues related to the Framework, I realised that working with the entire XELTO DIGITAL team is a pure pleasure. Each person in our team is responsible for specific process automations, but if anyone of us is facing an issue that they can’t figure out they are not left on their own with the problem. Thanks to this support, joint discussions and “brainstorming”, a model for building robots has just been developed. But before we talk about all of this with Rafał, I have to, at this point, thank my colleagues for cooperation.
With the Expert’s eye:
UiPath promotes the creation of solutions based on the ‘Robotic Enterprise Framework’, which ensures the basic implementation of the key concepts which support the creation of automation. Together with the XELTO DIGITAL team, we have gone one step further and developed an expanded version of the framework, which forms the basis of the robots we build.
What does this give us?
1.Standardisation
For each customer all processes are built in exactly the same way. This has allowed us to implement a number of common mechanisms at the design stage. When opening a new project, the developer no longer has to worry about logging, main error handling or preparing the environment. For example: when using the TypeIntoElement procedure, the developer will log with a single block if an item exists, write the value for it using the method of their choice, check that the value entered is correct, and if something does not work, they can repeat it X times. In addition, both logs and error messages have a uniform format and provide us with key information.
2. Security
With built-in mechanisms, each process can make the basic preparation of a machine for operation and leave the environment ready for the next robot. In addition, whatever happens, the robot is able to gracefully close all open applications and leave the workstation in the same condition as it found it. If the robot works on a Windows server, it knows that it should shut down processes for a specific user session only, allowing multiple robots to work safely at the same time.
3. Accelerated production
It takes about 30 minutes to prepare a model for a new project. During this time, the developer receives a package of end-to-end solutions for which it would take at least a few days to design, build and test if it was done on a one-off basis. In turn, the use of reusable components allows for the quick construction of process actions. I’m writing here about both the universal procedures in the framework and those developed for specific applications which are available in the auxiliary libraries we have built. For example, the already mentioned TypeIntoElement and ClickElement will run on each web application, while the NavigateFastPathJDE is a procedure built exclusively for handling the fast track in JDE.
4.Better Technical Support SLAs
The standardisation of the robot creation process improves the diagnostic time if errors occur in the process operation. There are two reasons for this: first, specific errors can only occur in specific locations. If the ODBC connection does not work, we know right away that the problem should be looked for in the ‘get transactions data’ area. As a result, the time required to find the problem area is significantly reduced. Second, we have introduced uniform error codes for all robots and divided them into those for which the business is responsible and those that appear as a result of the applications used. If, when monitoring the work of robots, we see a message, such as B0001, it is immediately clear to us that the robot failed to log into the application because the password had expired.
In summary, the implementation of our own robot building model means that the new processes are built more quickly and safely, easily fitting into any existing robot infrastructure at any customer’s site.
Author: Rafał Korporowicz – Senior RPA Developer
Foto: iStock
