About the course
Orchestrator is at the core of the UiPath Platform, providing management capabilities for automation and robots. These capabilities are needed in smaller-size deployments, as well as at an enterprise scale, where organization modelling is also necessary.
We’re here to cover Orchestrator from the perspective of an RPA Developer. We’ll be focusing more on the core Orchestrator concepts and features, using them in development, and seeing how they’ll work at runtime.
What you will learn in this course
At the end of this course you should be able to:
- Define the purpose and main capabilities of Orchestrator.
- Describe the Orchestrator entities and what they are meant for, as well as differentiate between the tenant context and the folder context.
- Create, configure and provision unattended robots from Orchestrator.
- Differentiate between a background and a foreground process.
- Execute jobs using unattended robots in different ways.
- Describe how licenses are allocated and consumed in Orchestrator.
Introducing UiPath Orchestrator
Orchestrator is the component of the UiPath Platform for managing automation, robots, and related entities. Although it comes with different cloud and on-premises delivery options, including persistence, high availability, and disaster recovery, users can access it through a simple web interface.
Orchestrator offers role-based access control and a structure of tenants and folders to replicate organizational structures. Users are able to run the automation workflows developed in Studio and published to Orchestrator using the unattended robot workforce. Furthermore, Orchestrator is used to manage and distribute licenses, as well as to store automation resources.
Orchestrator Entities, Tenants, and Folders
- Orchestrator works with packages, processes, folders, robots, and so on. That’s why it is necessary to first understand these entities and the connections between them.
- The hierarchy is another important aspect of Orchestrator. Some of the entities exist in the tenant context, while others exist in the folder context.
- In Orchestrator, you use roles to control the level of access an account should have.
- The UiPath Platform has logging capabilities for all of its main components. Logs are created locally for every robot and automation action and then sent to Orchestrator from where they can be filtered, viewed, and analyzed.
Robot (Orchestrator entity)
By now you are familiar with UiPath Robot, the component of the UiPath Platform. This is an execution host that runs automation processes published in Orchestrator, as jobs.
In Orchestrator, a robot entity represents an image or the Robot component, controlling its connection and capabilities. The robot entity exists only if it is defined in relation to a user in Orchestrator.
Folder
Folders enable the separation and hierarchical organization of automation entities (processes, queues, assets) and the fine-grained configuration of roles and permissions. The hierarchical structure allows up to 6 sub-folders under each first-level folder.
Folders help replicate the organizational hierarchies, with the separation of automated processes between teams, segregation of process data, and access control for users. At the same time, when it makes sense, they allow sharing of the resources and assets.
Package
A project developed in UiPath Studio that is published to Orchestrator as a NuGet package. Multiple versions of the same project can be stored and used.
Packages can also be manually uploaded to Orchestrator.
Additionally, by viewing the versions for a package you can download it from Orchestrator.
Process
It is a version of a package that’s been allocated to a certain folder.
Given that most processes use a queue, asset, or storage bucket, the Package Requirements tab, for when adding a new process, makes it easy to identify which entities your package is using and if they are missing from your folder.
Job
A job represents the execution of a process on a UiPath Robot. You can launch the execution of a job in either attended or unattended mode. You cannot launch a job from Orchestrator on attended robots, unless for debugging purposes using personal workspaces, and they cannot run under a locked screen.
Heartbeat
Attended and unattended robots send a heartbeat to Orchestrator every 30 seconds. This signals to Orchestrator that the connection is working.
Tenants and folders
Just like folders, tenants are meant to replicate organizational hierarchies within the same instance of Orchestrator.
From a hierarchy perspective, folders are subdivisions of tenants. And while in the folders case it’s more about hierarchization and separation, tenants are clearly isolated from one another.
Consider a typical large company, in which both the data and the business processes are typically separated between divisions like Sales and Finance. But then, the subdivisions would have some of the data or some of the processes separated, at the same time, sharing others.
In Orchestrator, some of the entities exist in the tenant context, while others exist in the folder context:
Tenant entities
From the entities defined above, robots are tenant entities. This means that they can be allocated to multiple folders in that tenant. Using roles and permissions, the way robots work with each of the folders can be customized. We’ll see that a bit later.
Packages are published to Orchestrator using feeds. The feeds can be configured to be at the tenant level, or at the folder level. A package published to the tenant feed can be then used in a process in any of the folders. If it is published using a folder feed, it cannot be used for processes in other folders.
There are a couple of other Orchestrator entities which exist at the tenant level:
User
Both human users and robots are uniquely identified with users in Orchestrator.
Machine (Orchestrator entity)
These are Orchestrator entities corresponding to the workstations where human users and robots work. Using API keys, they enable the connection between the physical machines and Orchestrator.
License
The right to use Studio and/or Robots, both attended and unattended, is done through licenses. Licenses exist at the tenant level, from where they get distributed to users and consumed when the machines connect to Orchestrator.
Webhook
Webhooks facilitate the communication between Orchestrator and other applications at API level. These are mapped at tenant level, which means they cannot be differentiated between folders and will provide information for the entire tenant.
The tenant menu in Orchestrator offers access to the audit trail and to the notifications and alerts for all the entities on the tenant, as well as to third-party credential stores, such as CyberArk. It also contains a settings menu for the entire tenant.
Folder entities
A folder is a storage area that helps keep your projects separate. From the entities defined at the beginning of the lesson, processes and jobs are folder entities. Packages depend on feed configuration.
There are two types of folders available in Orchestrator: Classic and Modern. A Classic folder is created by default for each new tenant. To learn more about the feature comparison for the two folders, look for the resources at the end of this lesson.
Apart from them, several other entities exist at the folder level:
Asset
An asset is a piece of data stored in Orchestrator for the use of robots. There are four types of assets:
- Text – stores only strings (it is not required to add quotation marks).
- Bool – supports true or false values.
- Integer – stores only whole numbers.
- Credential – contains usernames and passwords that the Robot requires to execute particular processes, such as login details.
Assets can have a global value or a value per user. This means that only the designated user will access a certain value stored in that asset.
Storage bucket
Storage buckets are entities used for storing files which can be used in automation projects.
Queue
Queues are containers that can hold an unlimited number of items, storing different types of data.
The process of feeding items to a queue is typically different from the process of processing the queue items and handled by different robots.
Trigger
Triggers enable the execution of jobs in a structured manner. There are two types of triggers:
- Time triggers: with these, you can schedule the recurrent execution of a process.
- Queue triggers: these enable the execution of a process based on the new items added to a queue.
Personal Workspaces
A personal workspace is a modern folder available for the dedicated use of a particular attended user. Personal Workspaces make it easy to deploy automations to your own robot, for easy regular execution, with the organizational benefits of logging, visibility, and potential reuse.
They come with the following entities: package feed, machine template, and resources (jobs, assets, logs, queues, etc.).
Roles
Roles are sets of permissions used to control the access of human users and robots to tenant and folder entities.
Each permission is defined from the combination of at least an action type (view, edit, create, and delete) and an entity, be it at the tenant or folder level. For example, you can set up the right to view only the queues in a certain folder, but not the queues from other folders.
Standard roles for modern folders
The following roles are pre-configured to manage permissions at the tenant level and at the folder level, which is required to work in modern folders.
They are only available if you choose to create them for your tenant from Tenant > Settings > General. You can find below just an overview and more in-depth by identifying the resource at the end of this lesson.
| Role | Level |
|---|---|
| Tenant Administrator | Tenant |
| Allow to be Folder Administrator | Tenant |
| Folder Administrator | Folder |
| Allow to be Automation User | Tenant |
| Automation User | Folder |
Logs in Orchestrator
Logs are time-stamped files that contain informational events, errors, and warning messages relevant to the application. The UiPath Platform has logging capabilities for all of its main components. Logs are created locally for every robot and automation action, and then sent to Orchestrator from where they can be filtered, viewed, and analyzed.
There are two types of Orchestrator logs:
Diagnostic logs
These are diagnostic logs generated by UiPath Orchestrator regarding its behaviour.
Execution logs
These are logs generated by process execution.
The Logs page displays logs generated by Robots in all folders you have access to, including logs generated for jobs started through remote debugging sessions.
To access it, navigate to the Automations tab from a folder context, and select the Logs tab.
Messages are logged on the following levels: Trace, Debug, Info, Warn, Error, and Fatal.
User and Robot accounts
In Orchestrator, both human users with attended licenses (Robot or Studio) and unattended robots need to have a corresponding Orchestrator user.
Depending on the deployment type and the organizational setup, users are added and managed in different ways:
- Users can be added locally in on-premises, standalone Orchestrator.
- Users have to be added in Automation Cloud, then in cloud Orchestrator to grant them a license.
- Users can be added from Active Directory for both on-premises and cloud Orchestrator if the integration was configured beforehand.
Robot accounts have to be created in Automation Cloud, and they behave like user accounts regarding permissions. The only differences compared to user accounts are:
- Robot accounts are not allowed to have any interactive-related process configuration.
- No email address is required to create a robot account.
Automatic robot creation
To simplify the attended and unattended robot creation, as well as the license provisioning, the automation robot creation can be enabled at user level, for both attended and unattended robots, and at group level for attended robots.
Basically, you enable the Attended Robot or Unattended Robot toggle at the account or group level, configure the various settings (robot execution settings, machine login credentials, if applicable), and a floating robot with those attributes is created.
Machine templates
Robots run on physical or virtual workstations. These are mirrored in Orchestrator by entities called machines. The machines in Orchestrator work as API key generators, authorizing the connection between the robots and Orchestrator.
There are two types of machines in Orchestrator:
- Machine templates: this allows the connection to multiple workstations with a single API key.
- Standard machines: this allows the connection between Orchestrator and a single machine. This is suitable for scenarios in which robots need to run on specific machines.
License distribution
In Orchestrator, licenses are also called runtimes. They are allocated at the machine template level, under Machines in the Tenant menu.
The number of runtimes allocated there should be matched with the maximum number of users which can run on a single machine connected using that machine template. On a regular Windows machine, only one user can run. But on a Windows server machine, multiple users can run simultaneously.
Licenses are consumed as soon as a machine is connected to Orchestrator, no matter the number of users running on it.
The use of folders and job priorities
By accurately reflecting the business hierarchies with the help of folders, roles and permissions, we can control the access to automation processes and make sure the effort is spent where it brings the most return. Job priorities can ensure that business priorities are well reflected in the automation process.
The separation of processes based on UI interaction
Processes in Orchestrator are now differentiated between those that interact with the user interface (known as foreground processes) and those that don’t, called background or headless processes.
This has a significant impact on the way automation jobs are executed. An unattended robot can simultaneously run a foreground job and as many headless jobs as available runtimes on a machine.
The license allocation per machine
Allocating licenses (runtimes) per machine ensures that their consumption is optimized. For example, on a Windows Server machine, multiple robots can open sessions and run unattended jobs up to the maximum number of runtimes.
Custom job allocation strategies
Unattended automation was designed in Orchestrator to ensure resource optimization and effectiveness. But there are cases in which business logic is more important. Orchestrator offers a couple of features and options to allow the customization of the job allocation process so that certain jobs or resources are available only to certain users.
Facts
Which of the following entities need to be mapped to the folder in order to run an unattended job?
Answer:
- Process
- User or Robot
- Machine template
…
The automatic robot creation can be enabled for Active Directory users for both unattended and attended robots.
…
Consider a Windows Server machine connected to Orchestrator using a machine template configured with 3 licenses (runtimes). If the only job running uses a background process, how many licenses are consumed?
Answer: Licenses are consumed when the connection between the machine and the Orchestrator is in effect. So, all 3 licenses are consumed.
…
Which of the following folder entities can be configured to be accessed/executed only by a certain unattended robot?
Answer: Assets can be configured to be accessed only by a user corresponding to a robot. Triggers and Jobs can be configured to be executed only by a user. Queues are collections of items and cannot be configured to be accessed only by a given user.
…
Review Question: Which of the following actions can be easily performed by Studio users that are signed in to Orchestrator?
Answer:
- Run jobs using published processes.
- Publish a package to Orchestrator.
…
When a user is being imported from Active Directory, the automation robot creation can be configured only for the attended robot, but not for the unattended one.
Answer: False
…
When running a job, will all the automation ‘.xaml’ files included in the project be executed?
Answer: No, only files linked to the Main.xaml through the Invoke Workflow File activity will be executed.
…
Which of the following folder entities can be configured to be accessed/executed only by a certain unattended robot?
Answer:
- Job
- Asset
- Trigger
Congratulation
