Dear RPA Enthusiasts,
The Robotic Enterprise Framework (REFramework) by UiPath provides a great template for more complex Automations, with inherent Exception and Error Handling – in accordance with best practices. Moreover, its general structure allows for precise process enhancements and maintenance as well as to pinpoint errors or faulty activities. These benefits are true for the original developer(s) itself/themselves, but more importantly for anyone who happens to be in charge for making adjustments to or reviews of the workflows at hand (especially after a certain period of time, where we humans normally tend to forget what the automation and procedure did in every detail).
A Brief Overview
The REFramework consists of these major steps:
– Initialization (Load Settings and Applications);
– Get Transaction Data (Loading the Transactions to be processed, one by one);
– Process the Transaction (Processing every single Step – this Workflow holds the lion-share of your Activities, most-likely);
– Set Transaction Status (Whether everything was successful, a Business Rule was thrown or even a System Error occurred);
– End Process (Closing Applications, Notifications, …).
Please note: This is just a brief overview and more details/handlings are present within the Framework. For those interested in the Framework itself, please refer to the following link in the official UiPath Documentation:
https://docs.uipath.com/studio/docs/robotic-enterprise-framework
You can find the REFramework Template in UiPath Studio when you set up a new project alongside other Templates, as shown in this screenshot (Studio version 2019.10):
(As a sidenote: Being able to understand the REFramework and setting up processes by utilising the instrument is the main requirement if you aim to get certified in UiPath (Advanced Developer Certification), by the way!)
Putting the REFramework into Practice
Even though I am an advocate of the Framework and the immediate benefits it provides, I do not build every of my processes with it. For simple Automations with just a few Activities, I would refer to the ‚more common‘ Sequences and/or Flowcharts. However, I would always hold true to the main concept and the above-mentioned structure (Init, Get Transaction Data, Process Transaction(s), Set Status/End Process)! It serves as some sort of Governance and other Developers benefit from it if they are tasked with dealing with the Workflows and Automations I set up. Frankly, I would wish for Workflows to be structured similarly, whenever I come across them – and that is often when time to get something fixed is of great relevance, as a side note. I’m sure you can relate.
In this article I would also like to suggest improvements to the REFramework and to leave them up for discussion. If you’ve come across similar challenges, feel free to share how you’ve managed to handle them. What are your thoughts on the Framework itself and what experiences have you made utilising it?
Three Potential Improvements to the REFramework
So, these are three potential improvements to the REFramework that I would like to put out there – up for debate and discussion with my peers.
Adding Path Exists Activities in the «Initialization»-Workflow
Have you ever wondered why the subfolders in the project directory ‚Data‘ (Input/Output/Temp) contained .txt files called ‚placeholder‘? For instance, I ran an Automation that merges documents and it used these folders to process temporary (PDF) files. Even though you could work with only .PDF files taking into account their file extensions, I was not a fan of uploading the placeholder-files into my Production Environment. Therefore, I deleted them. Whenever I ran my procedure locally (Studio Environment), all went well. However, the package we published to Orchestrator and ran in the Production Environment failed. It turned out that empty published folders are not in fact added to the package, causing errors when trying to save files in those non-existing directories. Therefore, I strongly recommend setting up «Path Exists»-checks within your Project Initialization – and to let your Robot create the relative directories accordingly if needed.
A More Central Approach to Setting a Transaction Status
Have you ever logged ‚Success‘, ‚BRE‘ or ‚System Error‘ in your Transactions file, for example on the right-hand side of all the Transaction info, as is recommended? The Workflow is set up so that you set the Target Column in three different Write Cell Activities. This is easy to set up, but withholds disadvantages when it comes to maintenance or process enhancements. Has your Transactions File ever grown in structure, with additional information being added (and used) in your Automation? If you carry on logging your Transaction Results in the same column, you end up with a mess.
Therefore, you’re forced to adjust each of your 3 Write Cell Activities (not only the Target Column, but maybe also your Comments and Annotations, depending on how you documented and described your Activities). Seems annoying, right? What could the suggestions be to improve this? Perhaps the Workflow could be restructured to have only one Write Cell Activity, regardless of the scenario. A different approach would be to include the Column Name in your central Config file. Do you see any other approaches to this?
The Config Dictionary (Variable Type: Dictionary<String,Object>)
We all learned to utilise a central Config file, which makes our life so much easier when it comes to maintenance and simple modifications to the settings and references of our project. We also internalised that in order to look up a set Value, we use Config(„NAME“).ToString – sounds familiar? I’ve been using this for a long time. However, since we with Routinuum „Challenge Routine.“, I questioned why we actually make our Workflows slightly harder to interpret by assigning everything ‚.ToString‘. Hence, I delved deeper into this and wanted to get to know why our Config Dictionary variable is „String, Object“ and not just „String, String“. I have hardly ever used anything else than the ‚String, String‘-combination, so I thought about adjusting my REFramework template to exactly that when it comes to Config Variables and Arguments. One alternate case is that you might be adding Integer values to your Config file. In that case, it would require you to convert from String to Integer in your Workflow [using Convert.ToInt32(Config(„NAME“))] – I could live with that for these rarer occasions. However, it would require other RPA Developers to be able to understand this generally – albeit slightly – altered approach to ensure easy-to-conduct maintenance and long-living RPA Workflows. Have you made any different observations on this topic in particular?
Other Ideas and Areas of Improvement
Please, let me know if you have any other ideas and – if you’re willing to share – potential improvements on the REFramework. How have you handled them in the face of RPA Governance and standardised RPA Engineering / Development within your organisation or at your customers?
Best regards,
Roman Tobler