Level of Difficulty: Senior.
This post will assist in understanding the practical use of design patterns and how they can be applied to the development of processes within UiPath.
What’re Design Patterns?
In a nutshell, a design pattern can be described as a template (or format) that is used to structure code in order to solve a problem in a systematic way. There are multiple different types of design patterns which include a variety of behavioral, structural and creative patterns. These are explained in depth here.
Design patterns are often used to assist in implementing OOP (Object-Orientated Programming) in order to make a solution more modular and reusable. Design patterns can also be used to maintain consistency across solutions so that multiple developers have a clear understanding of how the solution flows from one step to the next.
It is very important to keep design principles (like SOLID) in mind when deciding when and which design pattern should be used within a solution. SOLID is explained nicely here.
Why’s This Important?
When working with Robotic Process Automation (RPA) solutions, it is important to remember that the solution is assumed to have a short lifespan that could be anything from 6 months to 24 months long before facing re-evaluation. Once the value of an RPA solution is re-evaluated and certain aspects need to be enhanced or upgraded, it is easier to do so if the design pattern caters for foreseeable changes by design.
For example, an RPA process that handles reading Excel files that contain stock take information and storing it into an on-premise SQL server already exists. The solution has been re-evaluated after 12 months and the audit has found that new scanners will be used for stock taking rather than manually filling in Excel spreadsheets. The automation needs to be enhanced to accept sensor data from the scanner instead. If all logic that connects to the Excel files is referenced in multiple sequences/workflows logic lived all over the place, the enhancement could create some havoc. By adding a data access/acquisition layer to the solution, only one sequence/workflow will connect to the Excel file and only that sequence/workflow would be affected. All data access to the file is then also modularised.
What’d Such an Implementation Look Like?
Let’s identify some of the possible groupings of functionality:
- Initialisation/ Preparation
- Data Access/ Acquisition
- Domain/ Business Logic
- Modular/ Helper Components
- Tests
- Output
The above-mentioned groups can be further split, as seen below:
As seen above, the idea behind the proposed design pattern is to ensure the appropriate grouping of functionality. Applying a design pattern like this could be as simple as implementing a similar file structure that groups the relevant workflows.
An example of this is illustrated in A UiPath process, as seen below:
A template of the above UiPath process is available for download here.
Design patterns can be modified as needed. The most important aspect of planning the implementation of a design pattern is to determine how the functionality should be split, modularisedand reused (potentially even between projects) while remaining considerate of future operational support.
If you have any questions, issues or feedback, drop a comment below or reach out to jacqui.jm77@gmail.com
The JPanda 