- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- The Diagnostic Tool
- Workflow Analyzer
- About Workflow Analyzer
- ST-NMG-001 - Variables Naming Convention
- ST-NMG-002 - Arguments Naming Convention
- ST-NMG-004 - Display Name Duplication
- ST-NMG-005 - Variable Overrides Variable
- ST-NMG-006 - Variable Overrides Argument
- ST-NMG-008 - Variable Length Exceeded
- ST-NMG-009 - Prefix Datatable Variables
- ST-NMG-011 - Prefix Datatable Arguments
- ST-NMG-012 - Argument Default Values
- ST-NMG-016 - Argument Length Exceeded
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-023 - Empty Workflow
- ST-DBP-024 - Persistence Activity Check
- ST-DBP-025 - Variables Serialization Prerequisite
- ST-DBP-026 - Delay Activity Usage
- ST-DBP-027 - Persistence Best Practice
- ST-DBP-028 - Arguments Serialization Prerequisite
- ST-USG-005 - Hardcoded Activity Arguments
- ST-USG-009 - Unused Variables
- ST-USG-010 - Unused Dependencies
- ST-USG-014 - Package Restrictions
- ST-USG-020 - Minimum Log Messages
- ST-USG-024 - Unused Saved for Later
- ST-USG-025 - Saved Value Misuse
- ST-USG-026 - Activity Restrictions
- ST-USG-027 - Required Packages
- ST-USG-028 - Restrict Invoke File Templates
- Variables
- Arguments
- Imported Namespaces
- Recording
- UI Elements
- Control Flow
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Citrix Technologies Automation
- RDP Automation
- Salesforce Automation
- SAP Automation
- VMware Horizon Automation
- Logging
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Test Suite - Studio
- Extensions
- Troubleshooting
Remote Debugging
Automations may behave differently on different machines. If the machine on which an automation will run in production has a different configuration than the machine where it is designed (for example, the machine has different hardware or software, different permissions, or it is in an isolated network) the process should be tested and debugged with the robot on that machine.
Remote debugging enables you to run and debug attended and unattended processes on robots deployed to remote machines, including on Linux robots that can run cross-platform projects.
You can connect to the remote robot using one of the following connection types:
- Remote Machine - Establish a TCP/IP connection to the robot on the remote machine.
- Unattended Robot - Connect to an unattended robot in the same tenant using Orchestrator.
Using remote debugging requires that the project is open in Studio. If you are using source control, to make sure you are working with the latest project version, we recommend enabling the Enforce Check-In before Publish design setting.
To run or debug a project remotely using a remote machine connection:
-
Make sure that:
- TCP/IP connectivity exists between the Studio machine and the remote machine.
- The remote Robot is the same version as Studio.
- On the remote machine, configure the robot to accept remote debugging requests.
-
If interactive authentication is enforced in Orchestrator and you want to run or debug an unattended process, make sure that the remote robot meets one of the following conditions:
- Connected to Orchestrator using interactive sign-in.
- Connected using the machine key and a user is also signed in from the Assistant.
- Connected using the machine key, no user is signed in from the Assistant, and a troubleshooting session is enabled in Orchestrator for the machine. For more information, see Debugging Unattended Processes.
-
In Studio:
- Set up a connection to the remote robot.
- Make sure remote execution is enabled.
- Run or debug your project.
Before the remote robot can be used for debugging, the UiPath.RemoteDebugging.Agent utility on that machine must be configured to accept remote debugging requests from Studio:
-
Navigate to the installation directory:
- For a Windows robot - Open a command prompt in the UiPath installation folder (by default
%PROGRAMFILES%\UiPath\Studio
for per-machine installations,%localappdata%\Programs\UiPath\Studio
for per-user installations). - For a Linux robot - From a command line terminal, navigate to
/root/application
.
- For a Windows robot - Open a command prompt in the UiPath installation folder (by default
-
Run the following command:
- For a Windows robot -
UiPath.RemoteDebugging.Agent.exe enable --port <port_number> --password <pasword> --verbose
-
For a Linux robot -
~/application # dotnet ./UiPath.RemoteDebugging.Agent.dll enable --port <port_number> --password <pasword> --verbose
The arguments in the command are all optional:
-
--port <port_number>
- Enter the port to use for receiving remote debugging commands from Studio. If no port is provided, the port 8573 is used by default.The port must be open in the firewall and not already bound by another application.
--password <password>
- Enter a password that must then be provided in Studio when setting up a connection to the remote debugging agent.--verbose
- Log extra information to the console.
- For a Windows robot -
-
The following message is displayed:
Agent online and waiting for commands...
- From a command prompt, run the
hostname
oripconfig
command and make a note of the IP address or host name of the machine. One of the values, together with the configured port must be provided when setting up the connection in Studio.
No attended or unattended jobs can be executed from Orchestrator or from the local Assistant while the robot is in a remote debugging state. You can send remote debugging commands even to machines where the robot installation is not licensed.
- In Studio, select the Debug tab.
- In the ribbon, select the arrow under Remote Debugging, and then select Configure Remote Debugging to open the Remote Debugging Settings window.
- From the Connection Type dropdown, select Remote Machine.
-
Provide the following information in the corresponding boxes:
- Host - The hostname or IP address of the remote machine.
- Port - The port to use. The default port is 8573.
- Password - The password provided when the remote debugging agent was configured on the robot machine, if applicable.
- (Optional) To make sure a connection can be established with the current setup, click Test Connection.
-
Click Save.
To run or debug a project remotely using an unattended robot connected to Orchestrator:
- Make sure all the prerequisites are met.
- Set up a connection to the remote robot.
- Make sure remote execution is enabled.
- Run or debug your project.
- Studio and the target robot are connected to the same Orchestrator tenant.
- Studio, the target robot, and Orchestrator are running version 2021.10 or later. For the robot, 2021.10.6 is the minimum version required for running projects from Studio versions starting with 2021.10.6.
- The user signed in to Studio has permissions to start jobs, and to create and delete storage buckets and storage files in the same folder context as the target robot. In addition, the robot account must have view permissions for storage buckets and storage files.
- The unattended robot is configured and the machine has one of the following runtime licenses available: Unattended or NonProduction.
- For debugging foreground processes, the option Run foreground automations is enabled for the robot in Orchestrator.
- In Studio, select the Debug tab.
- In the ribbon, select the arrow under Remote Debugging, and then select Remote Debugging Settings.
- From the Connection Type dropdown, select Unattended Robot.
-
To use any connected machine that is available in the Orchestrator folder selected from the Studio status bar, click Save. If you want to select the machine to connect to, use the following options:
- User - Select an account with an unattended robot assigned to the Orchestrator folder.
- Machine - Select a machine or template from the Orchestrator folder.
-
Hostname - Select a machine from the list of connected machines.
Note: If changes are made to the account setup in Orchestrator, refresh the Orchestrator connection using the button in the Studio status bar so that they are reflected in this window.
When a remote debugging connection is established, clicking the Remote Debugging button in the ribbon toggles between remote and local execution. Before you select a run or debug operation, make sure the desired option is enabled (remote or local).
-
As long as the button is highlighted in gray, all run and debug operations (Debug File, Run File, Debug Project, Run Project, Step Into/Over/Out, Test Activity, Run to/from this activity) are performed on the remote robot.
-
As long as the button is not highlighted in gray, all run and debug operations are performed on the local robot.
The remote debugging experience is similar to the local debugging experience and all the features available for local debugging are also available for remote debugging. When remote execution that was triggered from the Debug tab is in progress, the Studio status bar is colored in green.
Depending on the type of connection used for remote debugging, the remote robot gets the activity packages required to execute a project as follows:
- Remote machine connection - Studio sends the list of project dependencies and activity feeds (package sources) to the remote robot, which uses the feeds provided by Studio to download the required packages.
- Unattended robot connection - Studio sends only list of project dependencies to the remote robot, which uses the Orchestrator feeds and the activity feeds configured on the remote robot to download the required packages.
- When you use a remote machine connection, if you pause debugging for an extended period of time, a Connection Closed error might occur in Studio even though on the remote machine the connection still appears to be active. To avoid this issue, you can increase the TCP idle timeout in your cloud or on-premises load balancer.
- When you use an unattended robot connection, selecting the Picture in Picture option does not start execution in a separate session.