uipath capabilities

Steps - Discover - Process mining - - Automate - Orchestration - Use NLP and AI - Intelligent document processing - Operate - Analytics - Testing - Deploy on cloud-native

Core components

Info

Studio, Orchestrator and Robots are what we call the core RPA components of the UiPath Platform.

Unattended bot is shown below

Studio

UiPath Studio is an integrated development environment for Automation Developers to design, develop, and debug automation projects.

Studio can be connected to Orchestrator, making it easy to publish automation projects as NuGet packages, via the dedicated feeds. From there, they're distributed to robots to be executed.

When we say Studio, we can think of two profiles, namely Studio and StudioX.

These are meant to match different coding skills that developers may have:

• StudioX is meant for business users looking to automate tasks for themselves and their immediate teams.
• Studio is meant for Automation developers looking to build complex unattended or attended process automations.

Orchestrator

Tldr

Its a web application

Orchestrator, the heart of automation management, is a web application that allows managing, controlling, and monitoring the robots and the automations.

With Orchestrator we can deploy, trigger, measure, provision, track, and ensure the security of every robot in the organization.

Orchestrator also functions as a repository for libraries, reusable components, assets, and processes used by robots or by developers.

The main capabilities of Orchestrator are:

• Provisioning: creates and maintains the connection with robots.

• Control and license distribution: enables the creation, assignment and maintenance of licenses, roles, permissions, groups, and folder hierarchies.

• Automation storage and distribution: allows the controlled storage and distribution of automation projects, assets, and credentials, as well as large files used in automations.

• Running automation jobs in unattended mode: enables the creation and distribution of automation jobs in various ways, including through queues and triggers.

• Monitoring: allows monitoring of jobs and robots and stores logs for auditing and analytics.

Assistant/Robots

Bots send heartbeat to the orchestrator

Kinds of robots:

1. Attended: Human users can trigger robots, through the UiPath Assistant tool to execute processes on their machines. We call these robots attended robots.

They're digital helpers for human users. They work on the same machines as us humans, during the same hours. They're triggered directly by humans (usually through UiPath Assistant) or by an event related to what the human user does. For example, opening an application or receiving an email. 

UiPath Assistant is the component that provides a friendly interface to interact with attended robots. It is the tool that we use to easily access, manage, and run automations. 

1. Un-attended: The robots deployed on separate machines, working without direct human intervention, are called unattended robots.

These are meant to work non-stop, with as little input from human users as possible. They're deployed on separate machines and their jobs are triggered exclusively from Orchestrator.

Their interactions with human users are typically handled with as little disruption as possible, by creating and sending requests for human input or validation as tasks.

While these await to be processed, unattended robots can continue their work by picking up other jobs. When human input is finally provided, unattended robots can resume their work on the process.

AI Center

UiPath AI Center™ is a service that allows you to deploy, manage, and continuously improve Machine Learning models and consume them within RPA workflows in Studio. This chapter treats the subject of model deployment and management which is done through the AI Center web application available through your Automation Cloud™ Portal.

RE Framework

The Robotic Enterprise Framework (ReFramework) is a UiPath Studio template built using state machines. It acts as the starting point for production-ready RPA projects, especially the ones that require scalable processing. It is created to fit all of the best practices regarding logging, exception handling, application initialization, being ready to tackle any business scenario.

The Dispatcher and Performer (Producer and Consumer) Model

The Dispatcher and Performer (Producer and Consumer) model is a pre-designed solution to separate the two main stages of a process by placing a queue in between.

This way, the production of transaction items is entirely independent from their consumption. This asynchronism breaks the dependency between the producer and the consumer.

So, the two main stages of a process involving queues are separated as follows:

• Producer: The stage in which data is read, organized and fed into a queue in Orchestrator is called Dispatcher or Producer.

• Consumer: The stage in which the queue data is processed is called Performer or Consumer.

The performer process pulls transaction items from an Orchestrator queue and processes them as needed by the company. Queue items are processed one at a time.

It uses error handling and retry mechanisms for each processed item.

A major advantage of the performer is its scalability (multiple performers can be used with a single queue).

Dispatcher and Performer model

Let's take an example: we have a list of people and their email addresses in a spreadsheet. An email needs to be sent to each of them with a personalized message based on a template.

We can use the Dispatcher and Performer model in the following manner:

The Dispatcher reads rows from the input spreadsheet and adds the data (i.e., name and email) to a queue; each queue item will have both name and email from one spreadsheet row.

The Performer retrieves an item from the same queue and does the necessary actions using that data, like replacing template values and sending an email.

Config File

To make it easier to maintain a project and quickly change configuration values, it is a good practice to keep them separated from the workflows themselves.

As we've seen in the previous video, in the InitAllSettings.xaml workflow the ReFramework offers a configuration file. It is named Config.xlsx and can be used to define project configuration values. These values are then read into the Config dictionary.

Warning

As a final note about Config.xlsx, since the configuration file is not encrypted, it should not be used to directly store credentials. Instead, it is safer to use Orchestrator assets or Windows Credential Manager to save sensitive data.

End Process State

The Process Transaction state includes the key transaction processing steps. There are three possible outcomes:

• The Success transition is triggered when no exception has been encountered during processing and the automation attempts to get the next transaction item.

• The Business Rule Exception transition is triggered when a predefined business rule is broken and the data needs to be checked by a human. The Transaction item is marked as such and the automation attempts to get the next transaction item.

• The System Error transition is triggered when a system exception is encountered during processing. The automation sets the correct status for the item, launches the retry mechanism, closes all applications, and loops back to the Initialization state.