12. UiPath - Orchestrator For Developers - Giri

Practice 3 - Solution

1. Creating the environment: In Orchestrator, go to Robots > Environments tab and click the plus button Choose the robot created previously to be part of new Environment. 2. Creating a process: Go to Processes and click the '+' button Choose the package published at Practice 1 and the environment created at previous step. Add a description of your process and click 'Create' 3. Creating and running a job Go to Jobs Click the 'Start' button Select the process and the robot created previously from the environment and click Start.

Practice 7 - Solution

1. In order to run the process, first create a text asset in Orchestrator with name "TestAsset". You can assign it an initial value. 2. Create a new project in UiPath Studio as a Sequence and: Add a 'Input Dialog' activity with 2 possible options: "Modify asset" and "See asset" Add an 'If' activity to check if selected action was "Modify asset". If 'True':Add another 'Input Dialog' where the user can input the new value of the asset Add a 'Set Asset' activity and add the user's input as Value. If 'False': Add a 'Get Asset' activity Add a 'Message box' to display the asset value. 3. In case the error "Operation returned an invalid status code 'Forbidden'" occurs while modifying the asset value, you need to perform the following steps: Go to Users page in the Orchestrator and select Roles Click 'More actions' for Robot role > Update Robot role For Assets row, check the 'Edit' column & click Update.

Processes

A process represents the association between a package and an environment. Processes can be accessed from the menu on the left. In order to create a new Process, simply click on the '+', select a package available in Orchestrator, select the environment and give it a description. If the Main.xaml of the process has In, Out, or In/Out arguments, they are displayed on the Parameters tab of the View Processes window. In Orchestrator, they become input and output parameters and they can be configured from the Parameters tab.

Below are the main activities used to program the robots to work with queues:

Add Queue Item Add Transaction Item Get Transaction Item Postpone Transaction Item Set Transaction Progress Set Transaction Status

Postpone Transaction Item

Adds time parameters between which a transaction must be processed.

Practice 2 - Publish a package to Orchestrator

After you have connected your Robot to Orchestrator, you want to test publishing a package. Select any project you have previously worked on locally and publish it to Orchestrator.

Environments

An environment is a grouping of Robots, that is used to deploy processes. The dedicated tab in the Robots menu can be used to create, modify and delete environments. A robot can be added in more than one environment, provided that they are under the same service. In a real scenario, the Finance service could create environments at business unit level (Accounts Payable, Accounts Receivable), at application level (SAP, electronic banking, settlement application) or sub-process. It is very important to remember that services have the robots, environments, queues, processes and so on totally separated.

Securely storing assets

As a good practice, configuration assets, credentials and data that change frequently must not be stored in the workflows. Orchestrator provides a secure way of storing assets and distributing them to robots according to different scenarios.

What are the benefits of Orchestrator?

As you know, workflows can be executed on a local machine to perform simple tasks. In business contexts though, all the capabilities listed in the previous section are needed for effectively managing a large number of robots that have to execute numerous tasks. All these capabilities translate into tangible benefits, such as:

Assets

Assets are shared variables or credentials that are stored in the Orchestrator and used by the robots in different automation projects. They can be considered a data repository that the robots can access when running processes, based on clear instructions.

Types of robots

Before covering robot provisioning, let's spend some time to talk about the types of robots that UiPath offers. Based on how they can be used, there are 4 types of robots: 1. Attended Robots 2. Unattended Robots 3.Development Robot 4.Non-Production Robot

Set Transaction Status

Changes the status of the transaction item to Failed (with an Application or Business Exception) or Successful. As a general approach, a transaction failed due to Application Exceptions will be retried, and a transactions failed due to Business Exceptions will not be retried. A Queue item can have one of the following statuses: New - just added to the queue with Add Queue Item (or the item was postponed or a deadline was added to it). In Progress - the item was processed with the Get Transaction Item or the Add Transaction Item activity; Failed - the item did not meet a business or application requirement within the project; Successful - the item was processed; Abandoned - the item remained in the In Progress status for a long period of time (approx. 24 hours) without being processed; Retried - the item failed with an application exception and was retried (at the end of the process retried, the status will be updated to a final one - Sucessful or Failed) Deleted - the item has been manually deleted from the Transactions page

Practice 1 - Connect a robot to Orchestrator

Connect a standard robot to Orchestrator In this scenario, you have just installed UiPath Studio and the Robot on your machine and you need to connect the Robot to Orchestrator. To complete this task, create a new machine in Orchestrator (for the computer you have installed Studio on), create a standard robot in Orchestrator and pair it with the newly created machine.

Create and consume Orchestrator Queues

Create a Queue in Orchestrator Under the Queues section in Orchestrator, click the Add button. Click the Name field and enter a name, such as "Queue1". Make sure the Auto Retry option is checked and in the Max # of retries section, type 2. 2. Create the Dispatcher Open Studio. Read the excel file as a Data Table. Add a For each row activity. Drag and drop an Add Queue Item activity and place it in a For each row activity. The QueueName field in the Properties panel enables you to link this activity with a queue in Orchestrator. Select the field and type the name of the queue created during the previous steps. Make sure you place the text between quotation marks. The ItemInformation field is where the values of the transaction item can be added. This process works similarly to passing arguments to an invoked workflow. Press the ... button. An ItemInformation window enabling you to create an argument is displayed. Click Create Argument. Name the first argument "CashIn". Set the ArgumentType to String and the Direction to In. Fill in the Value field by entering the information on the first column of the Data Table - row("CashIn").ToString. Do the same steps (7-10) for the second field and third field (Name them: OnUsCheck and NotOnUsCheck). Run the workflow. Check the values in OrchestratorLocate the queue you created earlier.Press the More Actions button and select View Transactions. The previously created transaction items are displayed.Press the View Details button to see the values you entered in Studio. 3. Create the Performer Create a new Sequence in Studio. Name it "ProcessTransactions". Drag and drop a Get Transaction Item activity to the Designer panel. Double-click the Get Transaction Item activity to see the corresponding Properties panel. Fill in the QueueName field by entering the previously created queue. Click the TransactionItem field and press Ctrl + K to create a new variable of type Transaction Item. Type a name, such as "TransactionItem", and press Enter. Run the project.Return to Orchestrator and notice what happened. The status of the first transaction item was changed from "New" to "In progress". That happened because Orchestrator has not been instructed on the status of that item.To access the content inside the transaction item, you need to use the SpecificContent property of the transaction item, as in the following expression: TransactionItem.SpecificContent(""). Sometimes, casting that data to its appropriate data type may be needed.To change the status of the transaction item, continue developing the previous project by performing the following steps. Go back to your open project in Studio. Use three Assign activities to parse the data stored inside the Transaction queue and store these values in three variables of type Integer32. Don't forget to cast the data to Integer, using the cint(TransactionItem.SpecificContent("CashIn")) expression. Now use these values to input them inside the UiDemo.exe. Open the application and Log In. (The credentials are provided in the beginning of the exercise). Keep the application open for the purpose of the exercise. Use a Type into activity for each of these variables. After this three Type Into, use a Click activity for the Accept button inside the UiDemo. To make sure we inform Orchestrator about this Queue Item, drag a Set Transaction Status activity to the Designer panel. Double-click the Set Transaction Status to see its corresponding Properties panel. Click the TransactionItem field to enter the TransactionItem variable, which was created during the previous steps. Ensure the Status field is set to "Successful". Run this workflow. Return to Orchestrator and navigate to the Queues section. Identify the previously created queue and press the More Actions button, followed by View Transactions. Check whether the second item is displayed as "Successful". Re-run the workflow. Repeat step 17, but this time check whether the next item is displayed as "Successful".If deployed to multiple Robots, the project processes each item from the queue in order. 4. Handle Business Exceptions To experiment further, let us adjust the previous project by setting the Set Transaction Status activity in Studio to Failed instead of Successful. Double-click the Set Transaction Status activity to see its corresponding Properties panel. Press the Status drop-down box and select Failed. Click the ErrorType drop-down menu and select Business. This kind of exception is thrown if the data returned by the TransactionItem variable does not match the expected criteria, so it is automatically displayed as "Failed". Click the Reason field and type a suggestive text that can enable a reviewer to identify the cause of the fail, for instance "The field cannot be identified." Run the workflow. The data is retrieved in Studio. Go back to Orchestrator and open the Queues page. Identify the queue created previously and click the More Actions button, followed by View Transactions. Locate the newly added transaction item, which is displayed as "Failed" with a Business Exception. Click the corresponding View Details button and notice the entire processing history in the Item Details window. 5. Handle Application Exceptions The other type of exception you can throw is Application Exception. A transaction item that fails with an Application Exception is placed back in the queue and retried either at a later time or by a different Robot. This way we ensure that the data is not lost or discarded in case a Robot is missing an application that is required to run a process.To experiment with this kind of exception, perform the following steps: Repeat first two steps in the above section (1&2 in 4.Handle Business Exceptions). Click the ErrorType drop-down menu and select Application. Click the Reason field and type a suggestive text, such as "Missing Application". Run the project. Go back to Orchestrator and open the Queues page. Identify the queue created previously and click the More Actions button, followed by View Transactions. Locate the newly added transaction item, which is displayed as "Failed" with an Application Exception. Click the corresponding View Details button and notice the entire processing history in the Item Details window. Compare the two Item Details windows of the failed transaction items. The number of retries is mentioned. Return to Studio to process all the items inside the queue, by using the 'TransactionItem is not Nothing' expression as a condition inside an If statement and process the steps only if the condition is True. If not (False case), add an Terminate Workflow activity and set the Reason("No Transaction Data", for example).Try to throw appropriate errors using Try Catch when needed. Add the appropriate Set Transaction Status error messages when catching errors. Make sure the errors have meaningful names. Finally, after an item fails with Application Exception a certain number of times - the Max # of retries set when creating the Queue - the buttons "In Review", "Retry Items", "Mark as verified", "Assign Reviewer" are enabled. Reviewers can process the item manually. Select the Retry Items option to place the item back in the Queue and process it at a later time. Select the In Review option to signal to other users that you are currently reviewing that item. A reviewer can be assigned from the existing Orchestrator users. Once you have completed this task, run the first workflow several times, followed by the second one. Notice how fast the items on the Queue are being processed. Using multiple Robots speeds up the process. 6. Terminating and stopping a process Run the OrchestratorHelloWorld process from the Jobs section in Orchestrator, but don't press the OK button yet. Notice that the currently running process has a Running state associated with it. Select the check box to the left of this process to see the two buttons - Stop and Kill. Pressing Kill is the equivalent of stopping a process from the Studio. Orchestrator will connect to your Robot and send a stop command to the process. Pressing Stop requires you to use the Should Stop activity in Studio while developing the process. The activity returns a boolean value. It informs whether the Stop button has been pressed in Orchestrator by the time the Control Flow reached the Should Stop activity. This is similar to a Save Game function in a computer game. This allows you to instruct the Robot to exit the running the process in a "clean" manner, by closing all running applications, logged in systems like SAP and database connections. Go back to your first project (the Dispatcher) and let's run it three times in order to add some new queue items in our initial Queue. Check your queue (Queue1) in Orchestrator for the new elements. Go to the Project panel and open the Main workflow. Drag and drop here a Flowchart activity. Create a new variable of type Int32 called 'counter' with the default value set on '1'. Add a Log Message with the message "Processing Transaction number "+counter.ToString From the Project panel drag and drop inside the Flowchart the ProcessTransactions.xaml workflow and connect it with Start point of the Flowchart. Use an Assign activity for increasing the value of the counter with 1 each time the process is run. Connect this activity with the previous one. Drag and drop a ShouldStop activity and connect it with the previous Assign activity used. In the Properties panel and inside the Result press Ctrl+K to create a new variable in order to store the output of this activity. Call it 'shouldStop'. Check the Variables panel and you will see that 'shouldStop' was created with the type Boolean. Further, add a Flow Decision activity and connect it. In the Properties panel in the Condition property set the variable 'shouldStop' as we will need to check if the process should stop or not. Use a Log Message activity for the True case. Write inside of it a representative message like "Process was stopped. " For the False case, connect the Flow Decision with the first Log message activity from the top. Your workflow should look like this: Publishing the process From the top menu of the Studio press Publish. A pop-up will show up and you should see the information about your package. Click Publish. Go to Orchestrator->Processes->Packages. Search for your project here and you should see it. Go back to Processes and create a new Process. In the Package Name select the package that you just published. For the environment choose 'DemoEnvironment' and click Create. Navigate to Jobs and create a new Job for your process. Select the Process then the robot on your machine and click Start. Click on the ... in the right of the Jobs and select View Logs. You will see that the process is running and you can see here the output of each Transaction Item being processed. Go back to the Jobs page and click on the ... and select Stop. Wait for a few seconds and go back to check the logs as you did at step 5. You will see that the last but one Log message will be the one that you set as "Process was stopped."

Create and use Orchestrator assets

Create a new asset in Orchestrator (of type Text, having the name "TestAsset") and create a project in UiPath Studio to perform the following steps: Display an input dialog to let the user choose if he/she wants to see or update the asset. If the user chooses to see the asset, then the robot should display a message box containing the following text: "Hello, here is the asset you set: {value}", where {value} is the value of the asset created in Orchestrator. If the user chooses to modify the asset, then the robot should display another input dialog so the user can input the new value for the asset. The robot should then update the asset in Orchestrator. Note: The "Set Asset" activity require Robots to have Edit rights for Assets. You can read about roles here.

Practice 3 - Create and run a Job

Create and run a Job in Orchestrator After having successfully published a package, let's create and run our first job. To do this, you will need to create an environment, then a process and finally a job. Use any previously created UiPath Studio project you see fit.

Development Robot

Development Robot Has the features of an Unattended Robot, but it should be used only to connect Studio to Orchestrator, for development purposes.

Set Transaction Progress

Enables the creation of custom progress statuses for In Progress transactions. This can be useful for transactions that have a longer processing duration, and breaking down the workload will give valuable information.

Floating Robot

Floating Robot Works on any machine defined in Orchestrator. It is a good choice when human users work in shifts on the same machine or on different machines, and when virtual machines are being regenerated often.

From the Robot Tray

From the Robot Tray Running processes from the Robot Tray can be very useful for testing purposes or simple automations created for parts of your job or personal matters. To run a process directly from the Robot Tray: make sure the package is assigned to the environment in which your attended robot is part of; open the robot; if the package has an update available, you will see an up arrow from which you can update it in your robot; once this is done, you can run the process by clicking the 'Play icon'.

Get Transaction Item

Gets an item from the queue to process it, setting the status to 'In progress'.

How are Assets created and used?

In Orchestrator: Assets can be created from the dedicated area; The name and the data type have to be provided. By using the tabs, assets can be configured as follows:Single Value - can be accessed and used by all Robots;Value Per Robot - each value provided can be accessed only by the indicated Robot. Assets can be modified or deleted from the same menu. In Studio: For credentials, the 'Get Credential' activity has to be used; For all the other types of assets, the 'Get Asset' activity is used.

What are some business scenarios in which I will use Queues?

Items in the Orchestrator Queues are known as transactions. They are meant to be indivisible units of work - a customer contract, an invoice, a complaint, and so on. Working with Queues is very useful for large automations mainly, where the number of items is high and the distribution process may become problematic. Consider the following examples: New customer enrollment forms for a retail company - these may come from different sources (online, partners, own shops, call center) and having a smooth process of adding them to the processing line is crucial. Working with Queues will ensure that these are processed within the SLA time constraints; The complaint process of a worldwide retailer, having contact centers in many locations across the world - working with Queues will ensure that the items are centralized in a single depository and distributed to the available resources as they become available.

Demo abc

Let's recap the Activities and Methods used 1. Assets We used the same workflow from the Process Execution chapter In Orchestrator, we navigated to Assets from the menu on the left and clicked '+' to create a new asset. We gave it a name, selected the text type and gave it a value. In Studio, we used a 'Get Asset' activity, inputted the same name as the Asset that we created and stored the value in a newly created variable. We specified the name of the variable in the 'Type into' activity. In Orchestrator, we created a new Asset with different values per robot and tested it. 2. Credentials In Orchestrator, we created a new asset of credential type and gave it a name. We inputted the username and password securely. In Studio, we created a new sequence and used a 'Get Credential' activity with 2 output variables, one string and one secure string. We used 2 'Type into' activities to log in in the Ui Demo app, and a 'Click' for the Login button.

DEMO 1

Let's recap the Activities and Methods used 1. Connecting a robot to Orchestrator: We navigated to platform.uipath.com and created an account. After logging in, we navigated to Services from the menu on the left and selected the only available service. To establish a connection with a robot, we went through 3 steps:Provisioning a machine: we navigated to Machines from the menu of the left, clicked on the '+' and selected Standard Machine. We took the name from the Orchestrator Settings of the robot on our machine.Provisioning a robot: we navigated to Robots from the menu on the left, clicked on the '+' and selected Standard robot. We chose the machine, gave a name for the robot and added the domain\username (taken from the Command Prompt in Windows, using the 'whoami' command). The password is only needed for unattended robots. We also selected the robot type and gave it a description.Configuring the robot with the machine key: we opened the Orchestrator settings of the robot in the tray, added the Orchestrator URL and the machine key copied from the machine provisioned in Orchestrator. 2. Adding a robot to an environment: Navigate to Robots from the menu on the left and access the Environments tab. Select 'Manage' for an existing environment and select the new robot. From this tab, new environments can be created and robots can be selected to be part of them.

Demo Queues

Let's recap the Activities and Methods used 1. We created a Queue in the Orchestrator. 1. Dispatcher: We started the project as a Sequence and used an 'Excel Application Scope' to initialize an Excel file. In the container: We used a 'Read Range' activity to get the content and store it in a newly created DataTable variable; We used a 'For Each Row' activity to loop through the rows of the DataTable and used 'Add Queue Item' to add the row as a queue item. We specified the name of the Queue in Orchestrator and set the 'itemInfo' property to Collection, using 2 In arguments of String type with the following values:Incomes = row("Incomes").toStringPayments = row("Payments").toString As we run the robot, the Queue in the Orchestrator is populated. 3. The items in the Queue can be seen in Orchestrator, together will their data. 4. Performer: We started the project as a Flowchart and used a 'Log Message' to log the transaction number from a newly created Int32 variable "counter". We invoked the ProcessTransaction workflowhaving the following activities:'Get Transaction Item' to get the data corresponding to the transaction in line;'If' with the condition "TransactionItem isnot nothing". If 'True', we used a 'Try Catch' with the following activities in the 'Try' block:'Assign' the value of the "income" variable using the content of the Transaction Item with the following method: cint(TransactionItem.SpecificContent("incomes"));'Assign' the value of the "payment" variable using the content of the Transaction Item with the following method: cint(TransactionItem.SpecificContent("payments"));'Write Line' to calculate the difference between "income" and "payment" variable;'Set Transaction Status' to 'Success';In the 'Catches' block, we used a 'Set Transaction Status' to 'Failed'. After the ProcessTransaction workflow is run, the counter is increased by 1 using an 'Assign'. We added a 'Should Stop' activity to signal to Orchestrator that this is a place where the execution of the process can be stopped. We used a 'Flow Decision'. If there are other items to be processed, the process goes back to the 'Log Message' activity, otherwise the process will end.

Demo cc

Let's recap the Activities and Methods used In the project in UiPath Studio, we added an argument of In type and we published the new version of the project to Orchestrator. In Orchestrator, we navigated to Processes and clicked on the icon next to the name of the process with updated package to switch to the new version. From the same menu a roll back can be made. We started a new Job, navigated to the Parameters tab and edited the parameter corresponding to the argument with the desired value.

Demo aa

Let's recap the Activities and Methods used We have a very simple project in UiPath Studio that uses a 'Type into' activity to type a text into Notepad. We clicked 'Publish' in UiPath Studio, selected the Orchestrator option and provided release notes. In the Packages tab of the Processes menu, the versions and release notes can be viewed at any time. We navigated to the Processes tab, we selected a package and its version, an environment and provided a description. A process has been created this way. To start a job, we navigated to Jobs from the menu on the left, selected a process and an environment, configured the allocation to specific robots or dynamically and clicked 'Start'.

Demo bb

Let's recap the Activities and Methods used We navigated to Schedules from the menu on the left, selected a process and started configuring the options of the schedule: the execution target (all the robots, specific robots, dynamically) the start and stop time of the job the disable schedule the parameters.

Non-production robot

Non-production robot Similar to Unattended Robots, but they should be used only for development and testing purposes.

Jobs & Schedules

Once a process is created, its execution can be triggered. There are 3 ways to do it: Using Jobs (immediately) To start a job, simply navigate to Jobs from the menu on the left, choose a process and either select the robots you want to execute the job from the environment, or allocate the job dynamically. A job allocated directly to certain robots will have priority over jobs allocated dynamically, but jobs allocated dynamically are executed immediately when any robot in the environment becomes available. When starting a job, you have the option to set input parameters or display the output parameters if they exist as arguments in the Main.xaml of the package. There are 2 options to stop a job: using Stop Job, that will stop it when a Should Stop activity in the workflow is encountered using Kill Job, that will stop it immediately.

Practice 2 - Solution

Open a project in UiPath Studio Click on the 'Publish' button Select Orchestrator as the place to publish and input the release notes. Click 'Publish'

Efficient planning and execution

Orchestrator allows execution of tasks according to schedules that can accommodate various scenarios (like non-working days), to choose execution targets from the available robots and even to create continuous execution loops even outside business hours.

What is Orchestrator?

Orchestrator is the component of UiPath Suite through which the automation workflows developed in Studio are published, assigned to robots and executed. It comes in the form of a web application that enables the management of robots, activity packages, data to be processed, execution schedules, as well as other assets. Orchestrator is ideal for large deployments of robots covering complex processes, but it can also be deployed in scenarios dealing with short and repetitive processes and fewer robots.

Packages

Packages consist of one or more automation workflows published from Studio. They can be published on the local machine or directly to the Orchestrator. Similarly, in Orchestrator, packages can be manually uploaded. In Orchestrator, versions of the same package are stored automatically. The version and release notes can be accessed anytime by selecting Processes from the menu on the left in Orchestrator, and navigating to the Packages tab. Package versions can be active or inactive: active: deployed to at least an environment; inactive: not deployed (this type can be deleted). Packages can easily be updated following the same steps as for publishing. It will be automatically detected that it's a new version of an existing package.

Practice 1 - Solution

Practice 1 - Solution Log in to Orchestrator at platform.uipath.com, navigate to Services from the menu on the left and click on your service. If you don't have an account, create one using your email. Navigate to Machines from the menu on the left and create a new machine. Specify the name of the machine as it is in the Orchestrator settings of the robot in your system tray. Navigate to Robots from the menu on the left, click on the '+' and select Standard robot. Choose the machine created earlier, give it a name and add the domain\username (taken from the Command Prompt in Windows, using the 'whoami' command). The password is only needed for unattended robots. Select the robot type and input it a description. Open the Orchestrator settings of the robot in the tray, add the Orchestrator URL and the machine key copied from the machine provisioned in Orchestrator. Check if robot is connected and licensed.

Practice 4 - Modify a package in Orchestrator

Practice 4 - Solution Open your project in UiPath Studio and modify it. Publish the package to Orchestrator. Don't forget to write clear release notes. Go to Processes in Orchestrator, identify your process and click on the 'More actions' button. Identify the new package version and click the 'Use' button Create and run a job and check if the correct package was used.

Practice 5 - Run a job with an updated process

Practice 5 - Solution Open the Robot Tray; Is the new package is available, update the process by clicking the Update button; After the process is updated, run it by clicking the Start button; Check if the job is performed as expected.

Practice 6 - Add schedules

Practice 6 - Solution 1. Hourly Add new Schedule Check the 'Hourly' option, every 1 hour at 0 minutes. Check 'All robots' from the Execution Target tab and hit 'Create'. 2. 3 times every Monday Add new Schedule Check the 'Weekly' option, select 'Monday' and insert the start hour. Check 'Allocate dynamically' from the Execution Target tab and instruct to execute 3 times.

What are Orchestrator's capabilities?

Provisioning - creates and maintains the connection with the robots. Deployment - ensures the delivery of the workflows for execution, either immediately or using schedules. Configuration - enables the creation, configuration and maintenance of groups of robots and the execution of tasks. Queues - the data that needs to be processed is broken down to indivisible operations called transactions. Queues can store any number of transactions and they facilitate their distribution, execution and monitoring. Monitoring - keeps track of robot identification data and maintains user permissions. Logging - stores and indexes the logs to an SQL database and/or ElasticSearch. Inter-connectivity - acts as the centralized point of communication for 3rd party solutions or applications, and can be used for storing activity packages, libraries and other assets (such as credentials).

Provisioning robots in Orchestrator

Provisioning robots in Orchestrator In order for robots to perform jobs, they have to be provisioned in Orchestrator, together with the machines that they will be using. It is important to remember that the machine name is mandatory for standard robots, and login credentials may be needed for unattended robots. Only the Orchestrator admins have rights to provision robots and machines. Robots can be connected: directly from the Orchestrator Settings window from the Command Line or automatically enrolled Usually, it is recommended to first try and connect the robot from the Orchestrator window. If issues are encountered when doing so, the next step would be to perform the connection from the Command Line.

Transactional processing

Queues allow efficient allocation of the workload between robots, continuous execution and monitoring at transaction level. If a certain transaction in the queue cannot be executed for certain reasons, it won't stop or delay the overall execution.

What are Queues?

Queues are containers that can hold an unlimited number of items. Queues in Orchestrator will store items and allow their distribution individually to robots for processing, and monitoring the status of the items based on the process outcomes. Working with Queues brings a series of advantages, especially for large automations with multiple types of elements underlined by a complex logic: centralized depository of work items; reporting capabilities at individual item level, as well as queue level; effectiveness of item distribution process - anytime a robot becomes available, the queue item in line is dispatched; unitary logic of item distribution - such as First In, First Out.

Working with Queues

Queues are easily created in Orchestrator. When they are created, queues are empty, but there are specific activities in the UiPath Studio to make the robots populate Queues. Bulk upload is also supported directly in Orchestrator, from .csv files. When creating a queue, you set the maximum number of retries (the number of times you want a queue item to be retried) and the Unique Reference field (select Yes if you want the transaction references to be unique). Once a queue was created, these settings can not be modified Queues are very important for the Dispatcher & Performer model, in which the two main stages of a process involving queues is separated: the stage in which data is taken and fed into a queue in Orchestrator, from where it can be taken and processed by the robots. This is called Dispatcher; the stage in which the data is processed, called Performer.

Orchestrator Key Concepts

Robot -The Robot is UiPath's execution agent that enables you to run workflows built in Studio. It can be of several types, as you will see in the next chapter. Environment -An environment is a group of robots configured in Orchestrator. Processes can be allocated to individual robots, but it's more effective to allocate them to environments. A robot can be part of more than one environment, provided they are in the same service. Organization Unit -In general, it is an entity in Orchestrator that corresponds to a business unit. The same Orchestrator instance can have multiple organization units configured, each of them having separate robots, environments, queues, assets and so on. The Community Edition plan won't allow the creation of other organization units than the default one created. Package -A project developed in UiPath Studio that is published to Orchestrator. Multiple versions of the same project can be stored and used. Process -It is a package that has been allocated to a certain environment. Job -A job is a process that has been sent for execution to some or all of the robots in the environment. Schedule -A process that is configured for an execution that is not immediate, but according to a schedule. Multiple configurations are possible when it comes to schedules. 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 for ERP systems. Queue -A queue is a sequence of transactions that is built in Orchestrator, and then used to dispatch to robots for processing.

Un Attended Robot

Robots run unattended in virtual environments and execute any number of processes. On top of the Attended Robot capabilities, Orchestrator covers execution, monitoring, scheduling and providing support for work queues.

Monitoring

Robots, processes and task execution can be monitored via Orchestrator, which can enable quick reaction in case of any error, and also provides the means for accurate reporting and auditing of the robot work.

Standard Robot

Standard Robot Works on a single Standard Machine only. It is a good choice when the machine on which the robot runs is known and will never change.

Important notes

The Community Edition doesn't allow multiple services, but other plans do. Services allow separation of all data under the same Orchestrator instance. Template machines should be used instead of Standard Machines when the name changes every time (like in the case of Virtual Desktop Infrastructure)

Add Transaction Item

The robot adds an item in the queue and starts the transaction with the status 'In progress'. The queue item cannot be sent for processing until the robot finalizes this activity and updates the status.

What is a robot?

The robot is UiPath's execution agent that enables you to run workflows built in Studio. The installation of the Studio comes with a robot that is triggered when the 'Run' button is clicked when a project is open. Provisioning robots in Orchestrator allows better package distribution capabilities, better scheduling, and enables the use of assets and queues. All these will take an implementation much closer to a business context.

Types of Assets?

There are four types of assets: Text - the equivalent of String (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 for SAP or SalesForce.

Attended Robot

This type of Robot is triggered by user events, and operates alongside a human, on the same workstation. Attended Robots are used with Orchestrator for a centralized process deployment and logging medium.

Using Schedules (planned)

Using Schedules (planned) Schedule offer multiple configuration options, such as: choosing a regular interval to execute the process setting up parameters (arguments in the Main.xaml in Studio) selecting the robots to execute (similarly to Jobs) - all robots, selected robots or dynamically setting up non-working days and other parameters. To schedule a process execution, navigate to the Schedules page, create a new Schedule and configure its parameters. Once you are done, click 'Create'.

What are some business scenarios in which I will use Assets?

When data doesn't change from one execution of a process to another, so it doesn't make sense to assign it every time from the Parameters tab. At the same time, data that may change shouldn't be stored in the workflow; Whenever robots need credentials to access applications in an automation scenario. The Credentials stored as Assets are encrypted with the AES 256 algorithm.

Add Queue Item

When encountering this activity in a workflow, the robot will send an item to the designated Queue and will configure the time frame and the other parameters.

Accessibility and version control

Workflows can be published as packages and stored in Orchestrator, at version level and with the developer's release notes. Different versions can be distributed to robots for execution. Libraries can also be published and stored in Orchestrator. From there, they can be accessed at any time, used in development and distributed to robots.