UiPath Apps while currently being a cloud-only offering, does provide means to connect to an on-premise deployed version of UiPath Orchestrator (v19.10 and later) to help leverage the power of RPA to help drive rich app experiences.
For more information on data flow between Apps and Orchestrator, see Hybrid data flow diagram.
- All connections to Orchestrator are made from a single place, the Apps Service application.
- All calls to Orchestrator are authenticated calls in line with the security model exposed by Orchestrator. Please see the section about Authenticating.
- Credential obtained from the user to talk to Orchestrator is used for all communication with Orchestrator both at design time when authoring the app as well as runtime when executing the app. The identity of the user who is designing or running the app itself has no bearing here.
- After initially obtaining the credential from the app designer, the credential is stored in the Apps backend with encryption at rest to enable seamless and uninterrupted design and runtime experience for all users of the app
- Apps service sets up a secure webhook callback over https on process lifecycle events to help detect when processes start, stop, error out, etc. This follows the best practices mentioned in the About Webhooks page.
- No process-related data is stored on the Apps backend. The only information that is persisted is metadata around the identity of the process/es that are being used by a specific app.
- Apps can invoke both attended and unattended Orchestrator processes. An app designer can choose to run a process through the connected Orchestrator or directly on the local computer on which the app is running using UiPath RobotJS.
- In the local robot scenario, process execution is invoked from the browser to the locally running robot and communication does not leave computer boundaries.
- In the process execution via Orchestrator option, the complete lifecycle of the process is managed by Orchestrator, and UiPath Apps plays no role in the same other than listening to process lifecycle events using the webhook callback.
The Apps service uses the outgoing IPs for all external communications:
220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124
Traffic from this IPs needs to be allowed through the Organization DMZ firewall and any other intermediate firewalls including the firewall on the computer/s in which Orchestrator application is hosted.
Please note that these IPs may change going forward as we continue to enhance the product.
- The associated port on which Orchestrator application is hosted needs to be exposed through the DMZ on all relevant firewalls (see the previous point)
- An orchestrator user who has read and execute access to relevant processes whose credential will be used from UiPath Apps to talk to Orchestrator
- If using local robot process execution through Robotjs, please ensure Robotjs is properly configured using instructions provided at RobotJS.
- Ensure that the On-Premise hosted Orchestrator is only accessible through a secure https channel
- Create a low privilege user in Orchestrator that only has read and execute access to just the desired processes/folders and use that for the integration.
Apps Designer says unable to connect to Orchestrator
- Are the UiPath Apps outgoing IPs whitelisted?
- Is the Orchestrator port whitelisted?
- Is the correct URL with the port being used in the Orchestrator URL field?
- Has it been confirmed that the credentials provided when connecting to Orchestrator are correct?
- Do the credentials provided have the permissions to list/run folders and processes?
Apps Designer shows no processes or wrong processes
- Does the user whose credential was configured during App Design have read access to the folder in which the desired processes reside?
When previewing an App and/or running an app and invoking a process, there is an error
- Are the UiPath Apps outgoing IPs still whitelisted?
- Is the Orchestrator port still whitelisted?
- Does the user whose credential was configured during App Design still exist?
- Does the user whose credential was configured during App Design still have the same credentials?
- Does the process and the exact version that is executed still exist in Orchestrator in the same folder or anything has changed?
- If running processes locally, is Robotjs configured correctly, and is able to properly handshake with the robot?
- Has the process being executed on the local robot been downloaded to the robot prior to executing the same through the app?
- Does the user whose credential was configured during App Design have to execute access to the process?
Updated 6 days ago