One of the key differentiators for UiPath Apps is the ability to easily connect an app to a RPA automation. The app can be used as a front end to provide inputs to the process or as a visual canvas to display outputs to your users.
Once a process has been published in Orchestrator, you can reference that process from an App.
In the example below, we'll show you how to import an existing process into an App.
- From an App in App Studio, click on the + icon next to the app title.
- Click on Process to open the process import dialog.
- A list of Orchestrator instances for the current Automation Cloud account is shown. Choose the one that hosts the processes you need and click Next.
- A list of processes, organized by folders, is shown for the currently selected tenant. Click on the > icon next to any folder to enumerate the processes in that folder.
- Highlighting a process will show you the process description as well as the inputs or outputs for that process.
- Check the checkbox next to the process you want to use in your app and click the Select button. The process selection dialog lists all the processes for a given Orchestrator tenant, organized by folder.
Process permissions are managed in Orchestrator. If you don't see a process in Apps Studio, make sure you have the right permissions for that process from Orchestrator.
If your process is making use of a complex .NET object in its input or output (eg DataTable), App Studio doesn't know what the fields of that object are by default. There are two ways you can specify this:
- Run your process before adding it to your app. If a process uses an object, Apps will check its Job History to automatically detect the schema/fields of that object.
- Manually specify object fields for process input/output. If your process has no job history then after it has been added to your app you must manually specify its fields in order to use them in your app.
- Manually added parameters to a process will be removed if the process is refreshed.
The process has now been added to your App.
Most RPA processes take inputs and/or display outputs. After designing the UI of our app, we want to connect controls to these inputs and outputs.
In the example below, we show you how to bind the input to a textbox and then display the output as a label. This app is designed to help a bank teller take in a cash deposit. We want to send the value of the Cash In textbox as an input and then display the resulting transaction ID output when the process is completed.
- Click on the textbox that we want to use as the input for the process (in this case, the Cash In textbox).
- We want to bind the value of this textbox to the input of the process so we click on the Value Binding property under the General tab of the Property panel.
- We can quickly find the process input by searching for CashIn. The resource panel finds the value and we can either double click it or drag-and-drop it to become the value binding.
- We can use the same set of steps to bind the transaction ID output of the process to the label.
Now that the process inputs and outputs are bound to the UI, the final thing we need to do is choose when to execute the process.
As discussed in the Events and Rules section, you can customize how an when a process is launched from your app.
In the example below, we show you how to start a process when a button is clicked but this could have been done from any event.
- Click on the "Submit deposit" button and switch to the Events tab in the properties pane.
- Click on Create Rule to open the rules builder.
- Choose the Start process rule.
- Click on the "What process to start" textbox and choose the Bank Teller process from the resources panel.
Processes run attended by default. If you want to run the process unattended, simply click on the Unattended type radio button.
You're all done! If you preview the app, you'll see that when the "Submit Deposit" button is clicked, the Bank Teller process will run on the local robot, passing the value of the "Cash In" textbox as an input and then displaying the transaction ID as a label at the bottom of the app.
Distinct users can not consume more than 100 unique unattended processes for a given orchestrator across all of the apps they use during their account lifetime In the case of an on-premise orchestrator, this is limited to 100 unique unattended processes across all users.
Updated about a month ago