About Deployment

One single Orchestrator instance can simultaneously run up to 1,000 Unattended robots or up to 10,000 Attended ones. For the recommended deployment for 10K Robots, please check the information presented here.

Orchestrator supports the multi-tenancy concept as well. The approach is called “Shared Schema”, meaning that multiple tenants can share the same database and the same database schema. All tenant-related data is unambiguously defined in each table by its own TenantId.

Logical Decomposition

The UiPath Server Platform has the following logical components, grouped in three layers:

• Presentation Layer

  • Web Application
  • OData REST API Endpoints
  • Notification API

• Web Service Layer

  • REST API implementation

• Persistence Layer

  • SQL Server

  • Elasticsearch

    
    

    

    
    

The Web Application is the visual layer of the Server Platform. The user interacts with its web pages in order to perform various actions: creating Robot groups, assigning packages to them, analyzing logs per Robot or per process, starting and stopping the Robots.

Besides the web pages, Orchestrator also contains a service layer which exposes a REST API mainly consisting of OData endpoints. REST API is consumed by both the Web Application and the Agents. The Agent is the supervisor of one or more Robots on the client computer.

Orchestrator functionalities covered by REST API:

• Configuration - REST endpoints used to define and configure application users, permissions, Robots, assets, releases, and environments.
• Monitoring and Notification - REST endpoints used for registering the Agents, delivering configuration settings to the Agents, and for sending/receiving notifications from the Server and the Agent. The Notification API also uses WebSocket communication.
• Logging - REST endpoints used to log different information like errors, explicit messages sent by the Robots, and other environment-specific information.
• Deployment - REST endpoints used by the Robots to query the package version that needs to be executed if you use the Start Job command in Orchestrator.
• Queues - REST endpoints responsible for queues and queue item management, namely adding data to the queue, obtaining a transaction from the queue, setting the status of a transaction etc.

Components of the Persistence Layer:

• SQL Server

  • stores the configuration of Robots, Robot groups, and associated processes, users, roles, schedules – information managed through the Web Application component.
  • manages queues and queue items.
  • optionally, stores the messages logged by the robots (in lieu of, or in addition to Elasticsearch).

• Indexer Server (Elasticsearch) whose role is to store and index the information logged by Robots. It can be disabled through configuration settings.

  Note: Messages logged by the robots can be stored in the SQL Server, in the Indexer Server, in both of them or in none.

The Indexer Server uses the Elasticsearch (an open source project) full-text search engine. All messages logged by Robots (using activities like Log Message or Write Line) are sent through the Logging REST endpoint to the Indexer Server where they are indexed for future utilization.

Note: For a better distribution of resources, it is recommended to install the Indexer Server on a separate machine than the one on which SQL Server is installed.

On the client computer, a running process is represented in the above diagram as an Executor. There can be several business projects running simultaneously, each having a corresponding Executor. The UiPath Agent (a Windows service) is the single point of contact for all Executors, through which all messages are logged into the Orchestrator Service, which processes them further (Indexer Server or SQL Server Database or both).

A Robot represents an association between a machine name and a username. It can manage multiple executors at the same time. On systems that support multiple interactive sessions running simultaneously (e.g. Windows Server 2012), there can be multiple Robots running at the same time, each in a separate Windows session using a unique username. We call this feature “High-Density Robots”.

The UiPath Agent is also responsible for sending the status of the Robot (e.g. SubmitHeartBeat endpoint) and downloading the required version of the package to be executed.

The communication between the Agent and Orchestrator is always initiated by the Agent. In the notification scenario, the Agent opens a WebSocket channel which is later used by Orchestrator to send commands to the Robot (Start, Stop, etc.).

Load Balancing Recommendations

We have tested Orchestrator high availability and disaster recovery deployments with several network load balancers like BIG-IP F5, Citrix NetScaler ADC, HAProxy. As the in-depth configuration of a network load balancer greatly differs from vendor to vendor, we have the following recommendations:

Recommendation
	Use a load balancing algorithm such as Round Robin or a predictive Round Robin derivate;
	Do not use persistent sessions, also known as sticky sessions;
	Use your preferred network load balancer in Layer 7 mode as it can interact with the Orchestrator API health checking endpoint. This API endpoint is available at https://your-orchestrator.com/api/status and returns 200 OK if the Orchestrator web app is up and running and 500 if it is not working. See Health Check Endpoints in the Orchestrator guide for details. The network load balancer should interrogate the API health checking endpoint of every Orchestrator server every 3 to 5 seconds.