Cloud – UiPath Orchestrator
In recent years, a cloud UiPath Orchestrator has been gaining traction, and as many enterprises move toward cloud-first architecture, let’s cover this aspect.
UiPath will maintain the complete infrastructure for Orchestrator, and all the resources will be held in the cloud. As UiPath introduces new products regularly, it becomes easy for customers to quickly subscribe to them and not install them as separate applications in on-prem environments.
Let’s consider ABC Insurance Corporation, an insurance service provider and a UiPath Enterprise customer who is setting up the cloud UiPath platform. Candace and her team at ABC Insurance Corporation will work on this assignment.
Automation Cloud setup
Now it’s Candace’s turn to set up the cloud Orchestrator for her team. The UiPath account team will provide the initial cloud administrator for UiPath Automation Cloud. She can add new users from the admin and access the Orchestrator default tenant, and the rest of the setup can be made once we log in to cloud Orchestrator.
Figure 1.5 – UiPath Automation Cloud
This is the primary offering for all new customers. Many existing customers are interested in converting to the cloud as it reduces the overhead of maintaining the Orchestrator platform and easy scalability.
Even though there are plenty of advantages, there are also a few disadvantages, such as not having access to the DB. Custom monitoring with Kibana or any internal platform is also not possible in this setup.
Candace and her team could access the UiPath cloud Orchestrator from the Automation Cloud within minutes. Next, she and her team need to understand Robots and options provided by UiPath before setting up.
Robots setup
As per UiPath documentation, UiPath Robots is the client program that runs processes developed in UiPath Studio or Studio Pro. Robots information is stored and controlled by UiPath Orchestrator.
There are different ways Robots can be configured in an Enterprise setup based on business needs. Before we can configure Robots, we need virtual machines to host these Robots’ client software.
Before moving forward, let’s understand folder concepts, as Robot types are tied to folder concepts.
UiPath folders
Orchestrator resources, such as processes, jobs, and assets, can be logically grouped into folders. Folder concepts provide an excellent way to organize the entire UiPath program. There are two types of folders currently supported by UiPath:
- Modern folder: This is the recommended option that will enable the UiPath program to utilize better all the latest features available in the UiPath Platform. Users and roles are assigned at the folder level, and greater flexibility to move Robot licenses between folders. Automation workflow executed in a folder can access resources in another folder, too.
- Classic folder: User roles are assigned at the tenant level, and Robots can be only part of a single folder. If the Robot needs to be used in a different classic folder, then the Robot needs to be deleted and recreated in the new folder.
Note
Classic folders will not be supported from UiPath Orchestrator v2022; all the existing customers need to migrate to modern folders to upgrade to this version.
UiPath Robot machine setup
Machines are runtime environments (physical or virtual) where the Robots execute the process. There are four options of machines in the latest version of Orchestrator (v2022.10):
Figure 1.6 – Machine options
Note
The software needed to run the automation (including UiPath Assistant) must be installed once the machine is set up. Access to resources, such as network shared location, needs to be provided.
All the Robot machine options are discussed in this section. Lets look through the options:
- Machine template: Robot machines can be logically grouped as per an organization’s functional or IT needs. Let’s assume 10 AWS EC2 virtual machines are available to execute HR and supply chain processes. We can build two different templates for HR and the supply chain. The HR template might have Version 10 of App A and App B installed, and the supply chain process needs Version 12 of App A and App C. Best practice here is to create a “Gold Image” with all the applications you will need for your automation. Failing that, you need to plan out and create machine templates for the combinations of applications you need. Adding a machine template key to the Robots will break the machine mapping.
Note
As the Robot and machine mapping is broken, any program can be executed in any Robot tied to the machine template.
To build a template, fill in the template name and runtime licenses needed, for example, a Production (Unattended) 5 runtime license. Additional options are to mention whether the machines are Windows- or Linux-based once under the Process Compatibility settings:
Figure 1.7 – Machine template options
In addition to this, we can also customize it to run foreground or background jobs.
- Standard machine: This is the default option available, and runtime licenses are needed. Most of the classic folder Robots are running on standard machines, and it is one of the most popular machine types used currently in organizations. The standard machine is supported in the modern folders concept, too. This will be a recommended type with a robust bot machine mapping, for example, a dedicated bot running on email processing on a machine.
Figure 1.8 – Standard machine options
- Primary Robot Pool: This is one of the recent machine types added at the start of 2021. This is a scalable auto option provided by popular cloud vendors, which will allow to automatically add new Robot machines in the cloud as per the configured parameter such as cost, maximum number, and time.
We need to add a cloud provider connection before using this feature.
Figure 1.9 – Cloud machine options
We just need to provide a name and associate the cloud connection to enable these auto-scalable machines:
Figure 1.10 – Robot pool
Note
A Robot pool can be a way to reduce your license and infrastructure costs significantly. If your organization has a mature cloud practice or is trying to start one, it is highly recommended to consider using a Robot pool as part of your architecture plan. Please refer to this documentation to set up the cloud connection: https://docs.uipath.com/orchestrator/v0/docs/elastic-robot-orchestration.
- Cloud Robot Pool (Preview): The last one is the latest feature in preview mode as of Jan 2022. This is a pure-play attempt by UiPath to enable Robots as a service offering. The Robot VMs will also be managed by the UiPath cloud platform and can be provisioned at will if this option is enabled. Reduction in risk and cost of maintenance are significant benefits in this approach, but lack of control, customization options, and Azure cloud dependency are a few drawbacks to be highlighted.
A new license type called Automation Cloud Robots is needed to leverage this feature. The user needs to enter a name and choose a machine image to set up a VM on UiPath Cloud. Once the virtual machine is enabled, the remote desktop needs to be enabled, and when we log in, UiPath Studio and Assistant are preconfigured:
Figure 1.11 – UiPath Cloud Robot Pool
Note
I predict that this will be the machine of choice in a few years as UiPath will handle the VM maintenance, and clients have one less maintenance function. Please refer to the official documentation here: https://docs.uipath.com/orchestrator/v0/docs/automation-cloud-robots-vm.
UiPath Robot categories
Now that we have seen different machine options, let’s look at some Robot categories.
Supervised versus autonomous Robot
The most common differentiation of Robots is based on the human-in loop concept, where the Robot executes a job with or without assistance from humans.
Supervised Robots run under human supervision and need humans to interact to complete a transaction:
- Attended – Bots operate along with the user and can be invoked via user events
- RPA developer bots – This is used to connect your Studio/StudioX or StudioPro to UiPath Orchestrator, and it is used when developing the UiPath scripts
On the other hand, autonomous Robots do not require human supervision to execute jobs:
- Unattended – Unattended bots are executed as batch jobs in the background, typically in a virtual environment, and are used to automate processes designed by the developers. It is the most popular bot license type being used in many organizations.
- Non-production/testing bots – Works in unattended/test mode for development purposes only.
Note
Choosing the right mix of Robot licenses is also an essential consideration for the UiPath program to succeed.
Standard versus floating Robot license
A standard Robot is configured in a dedicated virtual or physical environment, that is, there is a tight bot-to-machine mapping, and the same bot cannot be used in a different machine at the same time. The standard machine is the only machine type that works with a standard Robot. Standard Robots are the current standard in most organizations.
The floating Robots concept allows the Robot to be in multiple virtual or physical environments. The Robot is not associated with any machine. If a machine template is used and the Robot is configured to run on it with multiple machines, it becomes a floating Robot.
Note
Once the classic folder concept is depreciated in UiPath Orchestrator v2022, all the Robot licenses will be floating in nature by default on modern folders.
Normal versus high-density Robots
The subsequent differentiation of Robots is based on the hosting machine. If the Robot is hosted in individual VMs or desktops, it is considered a normal Robot.
If multiple Robot IDs are configured to run on a server environment, for example, Windows Server 2019 with five Robots accounts, it is a high-density Robot. The main advantage is that we can run multiple automation simultaneously in separate user sessions on the same machine. For this, some configurations must be done on the Windows Server machine first; then, you need to set up the environment in Orchestrator. Please refer to the following documentation: https://docs.uipath.com/installation-and-upgrade/docs/setting-up-windows-server-for-high-density-robots.
There are a few advantages and disadvantages of high-density Robots. One of the main advantages is to reduce the Robot machine maintenance downtime and easy monitoring of machine health. Still, the major drawback is if the server goes down with an issue, then multiple bot accounts will be stopped. One way to mitigate this risk is to have a machine template and provide additional runtime licenses to the machines in the template.
There are a few more types of Robots worth mentioning:
- Test Robot: If the UiPath Test Suite is enabled, we can procure this test non-production license type with a testing runtime associated. Converts a non-production Robot to a testing Robot.
- AI Robot: This is a particular type of license for the AI Center. An AI Robot license is used for machine learning (ML) training jobs, and a single license can also be used for executing any two ML skills available in the AI Center.
This section has covered all the major Robot types, and next, let’s see how to set up a Robot. Candace and the team are ready to set up unattended Robots using the machine template option in the ABC Insurance Corporation’s cloud Orchestrator.
UiPath Robot setup
On a very high level, both attended and unattended Robots can be set up on any of the four supported machine types, and they follow a structured flow, as depicted in the following diagram:
Figure 1.12 – Robot setup steps
Details of all the steps depicted in the diagram are detailed in this section, lets get into the details of the first step.
- Set up a VM and install all the required software for executing the process as needed, such as an Office suite, SAP client, and so on. We must add the root user to the right user group and domain that has access to this machine. Usually, the organization’s infrastructure group will be responsible for setting up the machines as needed, as per the policy agreed with the Enterprise architecture group.
- Install the UiPath Assistant software and choose whether you wish to run attended or unattended automation on this machine. The Enterprise support team will be able to install the software with elevated privileges.
- Next, we need to add a Robot user in Orchestrator with runtime licenses configured and provide correct access privileges to the folders and their resources.
- Establishing the connection between Robots and Orchestrator is mandatory, and again, the Enterprise support team needs to get involved as admin privileges are required to update the Orchestrator settings.
- Once the connection is established, trigger a test job, and see the execution in action.
Note
Please refer to Setting Up the Cloud Orchestrator and Robots in the book's GitHub repository (https://github.com/PacktPublishing/UiPath-Administration-and-Support-Guide) for step-by-step instructions to connect an unattended Robot to Orchestrator. In the real world, once a new Robot is set up on a machine, prerequisite checks are needed, such as whether the Robot has all the access rights enabled, software access, and licenses provided, such as Office 365 Acrobat, and so on. A trial job run is highly recommended in an attended mode before the actual runs take effect.
This completes the information on Robots. Candace and the team have followed the previous steps to set up the Robots.
Now that we’ve set up the UiPath environment, let’s talk about organizing the UiPath program.
