Learn different ways to run an on-premises robot.-Robotic Process Automation(RPA)-阿里云帮助中心

Prerequisites

You have prepared the on-premises robot. This includes the following:
- You have created a login account for the robot and assigned robot permissions. For more information, see Assigning on-premises robots.
- You have installed and logged in to the client. For more information, see Client installation and login.
You have developed your automation process and published it as an application. For more information, see Publish and manage applications.

Manage application scope

Note

Your account's application permissions determine which applications an on-premises robot can run.

You can obtain application permissions in two ways: by requesting them yourself or by having an administrator assign them.

Method 1: User self-service request

Request the required application from the "My Applications" menu in the console. You can log in in two ways:
1. From the robot client with single sign-on. In a logged-in robot client, click "Request Application" to be automatically redirected.
2. Log in to the console and go to the "My Applications" menu.
Select the application you want to request and submit the request.
After you submit the request, an administrator must approve it. For more information, see Application management. You can view the approval status in "My Applications".

Method 2: Administrator assignment

An administrator can directly assign an application to a member account from the "Enterprise Applications" menu in the console. For more information, see Application management.

View applications you can use

Go to the "My Applications" menu in the console to view the applications you can use.

Run an application

You can trigger an application using several methods:

Trigger method		Prerequisites
local trigger	Manual execution from the client	None
remote trigger	scheduled execution	The "Allow to be scheduled" option is enabled in the client. Robot usage permission: The account has permission to use the on-premises robot. Application usage permission: The account has permission to use the application.
	API-triggered execution	The "Allow to be scheduled" option is enabled in the client. Robot usage permission: The account has permission to use the on-premises robot. Application usage permission: The account has permission to use the application.
	MCP Tool call execution	The "Allow to be scheduled" option is enabled in the client. Robot usage permission: The account has permission to use the on-premises robot. Application usage permission: The account has permission to use the application. You have published the application as an MCP Tool. For more information, see Publish and manage MCP Tool.

Manual execution

You can run an application directly from the client. To enter the required input parameters, click the arrow on the left.

Scheduled execution

First, you must enable "Allow to be scheduled" in the robot client. You can do this in two ways:
- Method 1: Configure it directly in the client, as shown in the following figure.
- Method 2: Set whether the robot can be scheduled in robot monitoring. For more information, see Robot monitoring.

Next, configure a scheduled task in the console by navigating to scheduled task management > Scheduled task.

The following are key points for configuring a scheduled task:

Parameter	Description
Select robot	Select the robots on which you want to run the scheduled task.
Execution configuration	Queue if scheduling fails: This option applies when an application cannot run at its scheduled time. If enabled, the task is queued. If the task remains queued for over 24 hours, it fails, and the retry on failure process is not triggered. A task is not queued if the target robot is unschedulable (for example, disconnected or has "Allow to be scheduled" disabled) at its scheduled start time. Retry on failure: If enabled, the robot will immediately retry when an application execution fails. The robot retries a maximum of three times. task priority: When multiple tasks are sent to the same robot simultaneously, those with a higher priority are executed first.
Schedule	Supports various scheduling methods, including immediate execution, one-time scheduled execution, and recurring execution at specified intervals (daily, weekly, or monthly).

API-triggered execution

First, you must enable "Allow to be scheduled" in the robot client, as described in the previous section.
API calls
- Related APIs
  - Use the createServiceTask API to trigger an execution. For an example call, see API call examples.
  - Use the queryTaskStatus API to query the status of a task by its taskId, and use the queryServiceResult API to get the task_result for a specific taskId.
- API calls require an AccessKeyId and AccessSecret. Navigate to "System Settings > Personal Information" to find the AccessKeyId and AccessSecret for your account, as shown in the following figure.
  Important
  API calls are still subject to application usage permissions. If the account associated with the AccessKeyId does not have permission for the specified application, the API call will fail.
- API calls require a robot ID. You can find the robot ID in two ways:
  - Method 1: In the console, go to "on-premises robot - robot monitoring" to view the robot ID, as shown in the figure. To access this page, your account needs the necessary permissions for this menu.
  - Method 2: Open the on-premises robot client and go to the "Settings - About" screen to view the robot ID, as shown in the following figure.
View API-triggered tasks. You can find information about these tasks on the "scheduled task management - API-triggered tasks" page.

MCP Tool call execution

First, you must enable "Allow to be scheduled" in the robot client, as described in the previous section.
For more information, see Publish and manage MCP Tool.

Use cases

Use case: Integration

This example demonstrates how to call five on-premises robots using an OpenAPI. The process is similar for an MCP Tool call.

Prepare five on-premises robots.
1. Administrator: Create five sub-accounts exclusively for logging in to the on-premises robots. For more information, see Manage sub-accounts.
2. Administrator: Assign an on-premises robot license to each of the five accounts. For more information, see Assign on-premises robot licenses.
3. Install the on-premises robot client on five Windows hosts and log in to each client with one of the five accounts.
4. On the robot monitoring page in the console, verify that the on-premises robots are connected.
Prepare one sub-account for API calls.
1. Administrator: Create one sub-account exclusively for calling on-premises robots via an AccessKeyId/AccessSecret pair.
  Important
  For the account used to call the OpenAPI:
  - You do not need to assign an on-premises robot license to this account.
  - The "Scope of usable on-premises robots" setting for this account must be "All" or a "Specified scope" that includes the robots you want to call. For more information, see Set the on-premises robots that an account can use.
2. Administrator: Assign the required applications to this account. For more information, see Manage the application scope for your account.
3. Log in to the console with this account to obtain the AccessKeyId/AccessSecret pair and make the OpenAPI call.

Use case: Allocation by team

Assume you need to allocate resources to three teams, with each team using one on-premises robot. Team members run tasks either by remotely logging on to the Windows host for manual execution or by using scheduled tasks in the console.

The administrator prepares an on-premises robot for the first team.
1. Administrator: Create one sub-account. For more information, see Manage sub-accounts.
2. Administrator: Assign an on-premises robot license to this account. For more information, see Assign on-premises robot licenses.
3. Administrator: Install the on-premises robot and log in through the client.
4. Administrator: Set the "on-premises robot scope" for this account to "Specified scope" to ensure the account can only use a defined range of robots. For more information, see Set the on-premises robots that an account can use.
The administrator provides the account credentials to the team.
Team members request permission to use applications, and the administrator approves the requests.

Repeat the process to complete the allocation for other teams.

Use case: Use the latest version at runtime

This scenario is useful when there are many queued API-triggered tasks and the RPA application is updated frequently. This method ensures that the robot uses the latest default application version at runtime.

Important

This method requires your RPA application to handle input parameter compatibility across different application versions.

Method: When creating a task with the createServiceTask API, set appVersion to dynamic. The application version is not specified at task creation. Instead, the robot uses the latest default version when the task starts running.

For example:

Use the createServiceTask API to create two tasks consecutively.
When the first task starts, the task details show that it runs application version 0.5.0, as this is the current default version.
At this time, the second task is waiting to run, and its application version shows as "dynamic."
While the first task is running, a new application version, 0.6.0, is published.
When the second task starts running, the task details show that it uses application version 0.6.0.