Project Organization

Starting from a generic (and process agnostic) framework ensures you deal in a consistent and structured way with any process. A framework helps you start with the high-level view, then you go deeper into the specific details of each process.

The Robotic Enterprise Framework Template proposes a flexible high-level overview of a repetitive process and includes a good set of practices described in this guide and can easily be used as a solid starting point for RPA development with UiPath. The template is built on a State Machine structure.

How it works:

For transaction-based processes (such as processing all the invoices from an Excel file) which are not executed through Orchestrator, local queues can be built using .NET enqueue/ dequeue methods.

Then, the flow of the high-level process (exception handling, retrial, recovery) could be easily replicated - easier than by having the entire process grouped under a For Each Row loop.

All the REFrameWork files, together with the documentation are found on this page.

Splitting projects into smaller workflows and using Invoke Workflow File activities is paramount to good project design. Dedicated workflows allow independent testing of components, encourage team collaboration, and improve design and execution performance when compared to projects organized in fewer, larger files. We recommend keeping workflow file sizes under 5 MB. Workflow files over 10 MB are not supported.

Choose the layout type wisely (flowcharts and sequences). Normally the logic of the process stays in flowcharts while the navigation and data processing is in sequences.

By developing complex logic within a sequence, you will end up with a labyrinth of containers and decisional blocks, very difficult to follow and update.

On the contrary, UI interactions in a flowchart make it more difficult to build and maintain.

Project related files (such as email templates) could be organized in local folders or shared drives.

These folders could be also stored on a shared drive, so all the Robots connect to the same unique source. This way, the process related files could be checked and maintained by the business users entirely, without support from the RPA team. However, the decision (shared or local folders) is complex and should take into consideration various aspects related to the process and environment: size of the files, frequency of changes, concurrency for editing the same file, security policies, etc.

In order to easily manage project versioning and share the work on more developers, we recommend using a Version Control System. UiPath Studio is directly integrated with GIT, TFS, and SVN. You can find a tutorial explaining the connection steps and functionalities here.

Generally speaking, the final solution should be extensible in order to allow variation and changes in input data without developer intervention. For example, lists with customers that are allowed a certain type of transaction, emails of people to receive notifications, etc. should be stored in external files (like Excel) where business people or other departments can alter them directly (add/remove/update).

For any repetitive process, all workflow invocations from the main loop should be marked with the Isolated option to defend against potential Robot crashes (such as Out of memory).

No credentials should be stored in the workflow directly, but rather loaded from safer places like local Windows Credential Store or Orchestrator assets. You can use them in workflows via the GetCredential activity.

Two types of exceptions may happen when running an automated process: somewhat predictable or totally unexpected. Based on this distinction there are two ways of addressing exceptions, either by explicit actions executed automatically within the workflow or by escalating the issue to human operators.

In situations when exceptions may be encountered, it is useful to add a Global Exception Handler to the automation project. Only one such type of workflow can be added per automation project and the Global Exception Handler is not available for libraries.

The workflow can be set to determine the workflow's behavior when an exception is encountered by having the execution ignore the error and continue from the next activity, retry the activity which threw the error, abort the execution or continue and re-throw the error.

Moreover, arguments contained in the Global Exception Handler can be set to log the name of the activity which threw the exception or retry the activity a number of times. For more information on how to use its arguments, check out the Global Exception Handler page.

As an alternative to the Global Exception Handler, exception propagation can be controlled by placing susceptible code inside Try/Catch blocks where situations can be appropriately handled. At the highest level, the main process diagram must define broad corrective measures to address all generic exceptions and to ensure system integrity.

Contextual handlers offer more flexibility for Robots to adapt to various situations and they should be used for implementing alternative techniques, cleanup or customization of user/log messages. Take advantage of the vertical propagation mechanism of exceptions to avoid duplicate handlers in catch sections by moving the handler up some levels where it may cover all exceptions in a single place.

Enough details should be provided in the exception message for a human to understand it and take the necessary actions. Exception messages and sources are essential. The source property of the exception object indicates the name of the activity that failed (within an invoked workflow). Again, naming is vital, because poor naming gives no clear indication about the component that crashed.

As you can see below, choosing not to rename the Invoke activity makes the exception source meaningless in case of a crash (such as Invoke Workflow File > Invoke Workflow File > Invoke Workflow File > Type Into).

In the process flow, make sure you close the target applications (browsers, apps) after the Robots interact with them. If left open, they use the machine resources and may interfere with the other steps of automation.

Before publishing the project, take a final look through the workflows and do some clean-up:

The description of the project is also important (it is visible in Orchestrator). It might help you differentiate easier between processes, so choose a meaningful description as well.

When developing, we often need to automate the same steps in more than one workflow/project, so it should be a common practice to create workflows that contain small pieces of occurring automation and add them to the Library.

There is no universal recipe that tells you how to split any given process.

However, separation of business logic from the automation components is a good principle that helps with building a code that can be reused effectively.