UIPath进阶教程-5-Orchestrator

5.1 Multi-tenant-Experimental

UiPath Orchestrator offers a multi-tenant option. Using more than one tenant, users can split a single instance of Orchestrator to multiple environments, each one having their robots, processes, logs and so on.
This can be very useful when separated artifacts for different departments or different instances for clients are needed

5.2 Robots

Use meaningful names and descriptions for each Robot provisioned.
For Back Office Robots, the Windows credentials are needed in order to run unattended jobs on these types of Robots. For Front Office Robots, credentials are not needed because the job will be triggered manually by a human agent, directly on the machine where the Robot is installed.
Every time a new Robot is provisioned, the type of the Robot should be chosen accordingly.
The next step after registering the Robot to Orchestrator is done is to check if its status is Available, in the Robots page.

5.3 Environments

Use meaningful names and descriptions for each environment created.
Orchestrator Environments should map the groups of process execution. Each environment should have a specific role in the company business logic.
If a Robot is going to execute two different roles, it can be assigned to multiple environments.The access management of the Robots to the processes is done by using the Environments properly.

5.4 Process

Once in a while, old versions of processes that are not used anymore should be deleted. Versions can be deleted one-by-one, by selecting them manually and clicking the Delete button or the Delete Inactive button, that deletes all the process versions that are not used by any Release.
Note: It’s recommended to keep at least one old version to be able to rollback if something is wrong with the latest process version.

5.5 Assigning Processes to Environments

It is good practice to assign each process published to Orchestrator to an environment. In the Processes page, the deployment decision is taken. All the Robots from the environment will get access to the process version set for this Release.
When a new version of a process is available, an icon will inform the user.

Rolling back to the previous version is always an option if something goes wrong after updating. This can be done by pressing the Rollback button.

5.6 Jobs

If the robot should run multiple processes with no interruption, all the jobs should be triggered one after another even if the robot is busy. These jobs will go in a queue, with the Pending status, and when the Robot is available again, Orchestrator triggers the next job.

It’s better to cancel a job than to terminate it.
To be able to Cancel a job, the Should Stop activity is needed in the process workflow. This activity returns a boolean result that indicates if the Cancel button was clicked.

The Terminate button sends a Kill command to the Robot. This should be used only when needed, because the Robot might be right in the middle of an action.

5.7 Schedules

Besides the obvious functionality, schedules can be used to make a robot run 24/7. Jobs can be scheduled one after another (at least one minute distance) and if the Robot is not available when the process should start, it’s going to be added to the jobs queue.

5.8 Queues

Use meaningful name and description for each queue created.
At the end of each transaction, setting the result of the item processing is mandatory. Otherwise, the transaction status will be set by default to Abandoned after 24 hours.
Using the Set Transaction Status activity, a queue item status can be set to Successful or Failed. Keep in mind that only the Failed items with Application ErrorType are going to be retried.
If there are two or more types of items that should be processed by the same Robots, there are at least two option of how these can be managed by the Queues.
1. Create multiple queues, one for each type and create a process that checks all the queues in a sequence and the one with new items should trigger the specific process.
2. Create a single queue for all the items and for each item, create an argument “Type” or “Process”. By knowing this parameter, the robot should decide what process should be invoked.

5.9 Transactions

The Add Transaction Item activity brings the option of getting all the Transactions functionalities without using a queue properly (a queue should still be created before). This activity adds an item to the queue and sets its status to InProgress. Start using the item right away and don’t forget to use the Set Transaction Status activity at the end of your process.

5.10 Logs

The Add Log Fields activity adds more arguments to Robot logs for a better management. After using it in the workflow, the Log Message activity will also log the previously added fields.