Types of workflow layouts
For small processes automated or parts of a larger automation project, there are three options of layout – Sequence, Flowchart and State Machine.
Sequence
When should it be used?
When there’s clear succession of steps without too many conditions.
Usually, sequences are used to nest workflows and the high-level logic is handled through flowcharts or state machines.
What are the advantages?
Easy to understand and follow, having a top to bottom approach.
Great for simple logic, like searching for an item on the internet.
What are the disadvantages?
Nesting too many conditions in the same sequence makes the process hard to read.
Not suitable for continuous flows.
Flowchart
When should it be used?
When you have a complex flow with several conditions, a flowchart is at least visually much easier to understand and follow.
When you need a flow that terminates only in one of several conditions.
It should be used only as the general workflow (with sequences nested inside), not for individual parts of projects (nested inside other workflows).
What are the advantages?
Easy to understand, as it is similar to logic diagrams in software computing.
The most important aspect of flowcharts is that, unlike sequences, they present multiple branching logical operators, that enable you to create complex business processes and connect activities in multiple ways.
State Machine
When should it be used?
First of all, let’s understand what a state machine is. It is an abstract machine consisting of a finite number of pre-defined states and transitions between these states. At any point, based on the external inputs and conditions verified, it can be in only one of the states.
State machines can be used with a finite number of clear and stable states to go through. Some examples from your daily life include vending machines, elevators or traffic lights.
What are the advantages?
Can be used for continuous workflows that are more complex.
Transitions between states can be easily defined and offer flexibility.
Can accommodate processes that are more complex and cannot be captured by simple loops and If statements.
It is easier to cover all the possible cases/transitions with state machines.
What are the disadvantages?
Longer development time due to their complexity: splitting the process into logical "states", figuring out transitions, and so on.
Note: State machines are not to be overused - they should define only the skeleton of the project.
In fact, there are templates built upon state machines especially designed to build large enterprise automations.
Setting project Compatibility
When creating a new project in Studio, you must select the compatibility based on the environment on which the project will be executed:
- Windows - Uses .NET 6 with Windows support. This is the default option.
- Cross-platform - Uses .NET 6 with cross-platform support.
- Windows - Legacy - Uses .NET Framework 4.6.1. the compatibility used in releases prior to 2021.10.
- Converting Windows-Legacy projects to the Windows compatibility
- Studio comes with a built-in conversion tool that enables you to convert any Windows - Legacy project to Windows.
When you convert a project to Windows:
Project dependencies are managed based on the following rules:
- If the same version of the package exists in the configured package sources, the version used in the Windows - Legacy project is not changed.
- If the same version of the package does not exist, the version used in the Windows - Legacy project is changed to the highest patch of the nearest version.
- Dependencies for which no versions with the Windows compatibility are found are marked as unresolved and the version used in the Windows - Legacy project is displayed in the Project panel after the conversion.
Most activity packages developed by UiPath and available on the Official feed support the Windows compatibility.
- All the activities and properties are preserved in the converted project.
- Namespaces that are different in Windows - Legacy and Windows projects are updated.
- Namespaces that are required in Windows projects are added and those used only in Windows - Legacy projects are removed.
Designing cross-platform projects
Cross-platform projects enable you to create automations that don't require user interaction, and web browser automations using Chrome. Cross-platform automations can be executed on Windows and Unix-like operating systems such as Linux and macOS.
Creating unattended projects with cross-platform support:
- Create a new project in Studio and select the Cross-platform compatibility option. This option is available for all project types.
- Design the automation. Please note that not all activities packages are compatible with cross-platform projects, so only a selection of packages is available in the package manager.
- Test the automation. We recommend testing automations on the machines where they will run using remote debugging which works with Windows, Linux robots, and macOS robots.
- After testing the automation, publish the project to Orchestrator. The procedure for running unattended jobs is the same for Windows, macOS, and Linux.
Organizing projects into workflows
Breaking down an automation process into smaller workflows ensures speed of development and reliability by allowing independent testing of components while encouraging team collaboration. Both are paramount for the success of such initiatives. Moreover, in complex automations, like most enterprise projects are, the question is not if they should be broken down but how to do it.
What are the breakdown criteria?
There are multiple ways in which the workflows can be split and at least 3 factors should be considered as breakdown criteria:
- The application that is being automated
- The purpose of a certain operation (login, processing, reading a document using OCR, filling in a template, and so on)
- Complexity of each workflow
- Workflow reusability in other projects
Handling data in projects with multiple workflows
Splitting a project into smaller workflows has an influence on how data is handled. Since variables work only inside the same workflow, having more than one workflow requires arguments.
As you probably know from the Variables, Constants, and Arguments in Studio course, Arguments are very similar to variables. Both store data dynamically, have the same data types, and support the same methods. The main difference the two is the ‘Direction’ property which signifies the direction from/to which the data is passed. The direction can be In, Out orIn/Out.
- In - To pass a value to be used only inside the invoked workflow.
- Out - To pass a value to be used outside of the invoked workflow, in the parent workflow.
- In/Out - To pass a value from the parent workflow to the invoked workflow, modify it in the invoked workflow and then pass the new value back to the parent workflow.
Consider an invoked workflow that subtracts all the taxes from a gross salary. You will need at least two arguments:
- An 'in' argument mapped to the variable containing the gross salary.
- An 'out' argument to pass the value of the net salary to a variable in the parent workflow.
-.-
Working with libraries
Extracting workflows and reusing them across an automation project is a good habit for keeping a project organized, readable, and extensible. Apart from using workflows within a project, you would also come across situations where workflows from one project can be reused in others. This is achieved through libraries.
What is a project library?
It is a project containing workflows that can be used as activities in other automation projects. Libraries are saved as .nupkg files when published and can be installed as dependencies from the Package Manager.
Let's look at an example on creating and using a project library
A user logs onto the ACME(opens in a new tab) website, navigates to the Work Items tab from the Dashboard, downloads the work items from the table, writes the data into an excel file, and logs out.
Our task is to identify parts of this process that can be reused in other projects, create and publish a project library containing the reusable parts, and finally, automate the process using the project library.
Here are the high-level steps to build the automation:
- There are three parts of the process that can be used independently in other automation projects. They are the login sequence, navigating to Work Items and extracting the data from the table, and the logout sequence. We'll create a project library containing the reusable parts.
- Publish the project library.
- Import the library to another automation.
- Build the automation using the project library.
Project templates
How are project templates useful?
The speed of developing automation projects can be improved by creating project templates in Studio and sharing them with the team. Studio lets you create and publish custom templates or use one from the available built-in templates.
Here are the high-level steps to build automation
- Create a generic automation process containing three sequences: Initializing, Processing, and Finalizing in the Main workflow.
- Create a separate workflow to send email and use this in the Main workflow using the invoke workflow method.
- Use a Try Catch block in the Processing sequence to check for any exceptions and send email.
- Publish the template.
Activity project settings
What are Activity Project Settings?
Activity Project Settings refers to the settings that can be configured for an individual project, such as the location where the project files will be stored, the type of automation that'll be used (e.g., attended or unattended), and the version of UiPath Studio that will be used to create the project.
From the "Project Settings" window, you can configure a wide range of options, such as the project name and description, the location where the project files will be stored, the type of automation that will be used, and the version of UiPath Studio that will be used to create the project.
You can also specify the workflow settings, such as the default workflow type and the maximum number of retries for failed workflows. These settings can be customized to suit the needs of your project and can help to ensure that your automation processes run smoothly and efficiently.
Whenever a new process is created, a set of default packages are installed. As a best practice, keep only the ones that are relevant to the project.
As dependencies come in multiple versions, we can set the Runtime Rule when installing or updating them. It specifies which packages should be installed during runtime. We have two options:
Strict: Runtime execution is limited to the version of the package specified.
Lowest Applicable Version: It applies the next available higher version to resolve dependency issues if any.
Let's take a look at the options available in Project Settings.
General: It provides information about the project such as the name, its description, and also some settings that control its behavior.
Workflow Analyzer: It enables us to set the rules for projects based on company guidelines and our own specifications. These settings aren't project specific and hence any change made here will reflect in all future Studio projects.
Test Manager Configuration: It allows us to manage, automate, and execute test cases.
Activity Settings: Each activity package has its own set of activity settings. All of these activity settings can be configured either for production or debugging.
-.-
Best practices for project organization
Below are some of the recommendations to keep your projects organized
Pick a suitable layout for your project
Though automations can be built using either sequences, flowcharts, or state machines some tasks are better suited for one over the others.
For example, the main workflow works better as a flowchart as it easier to visualize the entire project.
State machines are ideal for the main workflow when you have multiple strict conditions for when a workflow can move from one state to another.
In general, higher-level decisions or business led decisions work better in a flowchart or a state machine.
On the other hand, sequences are best suited for UI interactions performed in succession without much variation.
Organize projects into smaller workflows
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.
Use exception handling to capture and manage errors
You can put complex or problematic parts of a workflow inside a Try/Catch block to ensure that the automation will not crash or stop for every minor error that it may encounter.
Try/Catch can also be used when using external workflow files as it helps in debugging.
Handle credentials carefuly
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 Get Credential activity.
Make your workflows readable
Giving descriptive names to all components and providing clarifying notes and comments is imperative to make your automations more readable not just for yourself but for other developers as well.
Log the execution progress as well to as it helps you locate any errors faster.
Keep your automations clean.
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.
The following points should also be considered to keep automations clean:
- Remove unreferenced variables.
- Delete temporary Write Line outputs.
- Delete disabled code.
- Remove unnecessary containers.
Source: UiPath Academy
Comments
Post a Comment