Automation Lifecycle

Process Understanding

Deciding between an automation for Attended Robots or Unattended Robots is the first important decision that impacts how developers build the code, as the general running framework (Robot triggering, interaction, exception handling) is different. Switching to the other type of Robots later may be cumbersome.

When Attended Robots Make Sense

For time-critical, live, humanly triggered processes, like in a call center an Attended Robot working side by side with a human might be the only possible answer.

Reconsidering Attended Robots

Not all processes requiring human input must use Attended Robots. If a judgmental decision is unavoidable, consider splitting the process into smaller sub-processes that can run unattended.

For example, one sub-process could collect data, and after human validation, a second sub-process continues automatically.

A typical case would be a process that requires a manual step somewhere during the process, such as checking the unstructured comments section of a ticket and, based on that, assign the ticket to certain categories.

Benefits and Practical Considerations

Generally speaking, going with an Unattended Robot ensures a more efficient usage of the Robot load and a higher ROI, a better management and tracking of robotic capacities.

However, several factors affect this decision:

• Attended Robots typically run only during working hours
• Attended Robots keep machines and users busy until execution completes
• Input types and transaction volumes
• Time restrictions and scheduling
• Number of available Robots

Documenting the Process - DSD

The process documentation guides the developer's work and provides help in tracking the requests and the application maintenance. Of course, there might be lots of other technical documents, but one is critical for a smooth implementation, namely DSD (Development Specification Document).

The Development Specification Document should contain the automated process details and focus on two main categories: Runtime Guide and Development Details.

The Runtime Guide should contain a high-level runtime diagram and details about Robot functionality, including sub-processes, schedules, configuration settings, and file management.

Include details on prerequisites, error handling, process resumption, Orchestrator usage, logging, reporting, and credential management.

The Development Details should include packages, development environment, logging levels, source control information, and workflow components with descriptions.

Also include reusable components, invoke trees, custom logs, flowchart snapshots, automation levels, and other development details.

Development and Code Review

The RPA Solution Architect is responsible for continuously coaching developers on the best practices. Hence, frequent and thorough code reviews are a must, to enforce a very high quality of the developed workflows. This way, the developers are motivated to build robust workflows and to follow the best practices guide.

Test

After each component is built, conduct unit testing. Thorough component testing ensures smoother integration and faster debugging.

Use the REFramework’s Test_Framework folder for test files. The RunAllTests.xaml file enables automated testing of multiple .xaml files. Run tests outside office hours in testing environments to optimize developer time.

The recommended UiPath architecture includes Dev and Test environments that allow the processes to be tested outside the live production systems.

Sometimes applications look or behave differently between the Dev, Test, or Production environments and extra measures must be taken, sanitizing selectors or even conditional execution of some activities.

Use the UiPath.config file or Orchestrator assets to switch environment-specific flags. Define a test mode Boolean parameter to control behavior during debugging.

When True, the automation follows test routes and doesn't execute fully. For example, skip notifications and use Cancel instead of Save. When False, follow normal production routes.

This allows you to make modifications and test them in processes that work directly in live systems.

Release

There are various ways of designing the architecture and release flow, considering the infrastructure setup, concerns about the segregation of roles, etc.

In this proposed model UiPath developers can build their projects and test them on Development environments in Orchestrator. They are allowed to check in the project to a drive managed by a version control system (VCS), such as GIT, SVN, or TFS.

Publishing the package and making it available for Test and Production environments is the work of a different team, such as IT.

The deployment paths on Orchestrator have been changed from their default to folders managed by the VCS, by changing the Storage.Location value in the UiPath.Orchestrator.dll.config file in the Deployment section..

The model also contains a repository of reusable components.

Here is the project publishing flow, step by step:

1. Developers build the process, test & debug pieces of it locally (Studio).
2. Once the automation development is completed, the process is published to the Development Orchestrator and tested again end-to-end.
3. The project folder is committed (not packaged) to a Master Library folder (on VCS).
4. The IT/ RPA Operations team creates the project package for QA. This step is intended to be an additional safety measure: the automation source code is inspected (by a different entity) before being packaged and run by robots.For example, the packaged process is stored in the Process Pckgs (QA) folder on VCS, from which it is deployed to the QA robots and executed.
5. If any issue is revealed during the tests, the steps above are repeated.
6. Once all QA tests are passed, the package is pushed to a Production environment - Process Pckgs (Prod).
7. When the Process goes live, the process package is deployed to the production Robots and executed.

Reusable Content is created and deployed separately, as UiPath code (Reusable Code Library) and Invokes (Invokes Repository).

Workflows with source code are .xaml files containing activities for automating common processes, such as Log in to SAP:

Invokes represent workflows composed only of one Invoke activity of the code workflows mentioned above.

The Snippet panel of a Studio developer should point to this Invoke repository in order to provide easy access (drag & drop) to Reusable Content.

The local design authority in charge with maintaining the Reusable Content updates (due to a change in process, for instance) the workflows with code. The Invokes remain unchanged.

The advantage of this approach (as opposed to working directly with the library of source code) is that when a change is done to a reusable component, all the running projects reflect this change as well, as they only contain an Invoke of the changed workflow.

Monitoring

Use Log Message activities to trace process execution for supervision, diagnosis, and debugging. Messages should include transaction IDs and state information for accurate identification.

Logging should be used:

• At the beginning and the end of every workflow;
• When data is coming in from external sources;
• Each time an exception is caught at the highest level.

Messages are sent with the specified priority (e.g. Info, Trace, Warning) to Orchestrator and are also saved in the local .nlog file.

Custom Log Fields

To make data easily available in Kibana for reporting purposes, the Robot may tag log messages with extra values using the Add Log Fields activity. By default, any UiPath log output has several fields already, including message, timestamp, level, processName, fileName, and the Robot’s Windows Identity. Log Fields are persistent so if we do not need to mark all messages with a tag, fields should be removed immediately after logging, using the Remove Log Fields activity. Do not use a field name that already exists. It’s important to specify the proper type of argument the first time when you add the field. This is how Elasticsearch indexes it.