This procedure starts from the presumption that you previously created a process.
Unattended robots can execute processes only if the Windows credentials (username and password) are provided when registering the robots in Orchestrator.
- Navigate to Automations > Jobs. The Jobs page is displayed.
- Click Start Job. The Start Job window is displayed.
- From the Process Name drop-down, select a process that has been previously deployed to the current folder.
- From the Jobs Priority drop-down, select the priority of the job to be executed if you want it different from the priority set at the process level. This field is automatically populated with the priority inherited from the package.
- From the Job Type drop-down, select the runtime type under which the job is to be executed. The number of available and connected runtimes is displayed below the drop-down.
- Unattended - the job is executed in unattended mode consuming an Unattended runtime (i.e. using an Unattended license)
- NonProduction - the job is executed in unattended mode consuming a NonProduction runtime (i.e. using a NonProduction license)
- Development - the job is executed in unattended mode using a Development runtime. This allows developers to run jobs from Orchestrator in their Personal Workspace, for testing and debugging purposes, without consuming an Unattended or NonProduction license. See details about debugging using personal workspaces.
The number of available runtimes, calculated as the total number of runtimes minus the number of running jobs.
The total number of runtimes, calculated as the sum of runtimes on all machines associated with that folder, which are connected to Orchestrator.
Say you have 2 nonproduction runtimes and 1 unattended runtime on machine template A, and 3 nonproduction runtimes, and 2 unattended runtimes on machine template B. Both are associated with one folder. On each template, you connect one host machine. The resulting runtime state is the following:
A running job of either type subtracts 1 from the number of available runtimes for that type.
- In the Execution Target tab select the execution strategy:
1. Allocate Dynamically
Dynamic allocation with no explicit user and machine selection allows you to execute a foreground process multiple times under the user and machine that become available first. Background processes get executed on any user, regardless if it's busy or not, as long as you have sufficient runtimes.
Using the Allocate Dynamically option you can execute a process up to 10000 times in one job.
The process is executed under a specific user. Only specifying the user results in Orchestrator allocating the machine dynamically. Specifying both the user and the machine means the job launches on that very user-machine pair.
The process is executed on one of the host machines attached to the selected machine template. Specifying the template displays an additional Connected Machines option, allowing you to select a specific host machine from the pool of connected host machines. Only specifying the machine results in Orchestrator allocating the user dynamically. Specifying both the user and the machine means the job launches on that very user-machine pair.
Make sure that runtimes matching the job type are allocated to the associated machine template. Only connected host machines associated with the active folder are displayed.
- In the Arguments tab, provide input arguments for the selected process. This tab is automatically populated with all the input arguments accepted by the selected process, and the corresponding values inherited from the package.
- Click Start. The Start Job window closes and, if there are available runtimes on the currently active folder, the job starts on a Robot according to the settings you made. The status of the job is displayed in real-time on the Jobs page.
Click the corresponding More Actions button, and then Stop. The automation project is executed until it finds a Should Stop activity. During this time, the job is in the Stopping state. If the activity is encountered, the execution is stopped, and the job's final status is Successful. If a Should Stop activity is not found, the job execution does not stop until it reaches the end of the project. The final status, in this case, is Successful as well.
A job started from the Jobs page can be stopped from the Jobs page only.
Click the corresponding More Actions button, and then Resume.
Click the corresponding More Actions button, and then Kill. The automation project is forcefully stopped, the job is marked as Stopped, and "Job canceled" is displayed in the Job Details window.
A job started from the Robot Tray can be killed from the Robot Tray only.
A job started from the Jobs page can be killed both from the Jobs page and the Robot Tray.
This feature enables you to quickly run a job from the jobs list, without going through the configuring job flow. You can restart any job with a final state – Stopped, Faulted or Successful.
You can’t restart jobs triggered by an agent.
This procedure starts from the presumption that you previously started a job that already reached a final status.
- Click the corresponding More Actions button, and then Restart. The Start Job window is displayed, with the job's initial settings.
- Make the desired changes.
- Click Start. The Start Jobs window closes and the execution starts. The status of each job is displayed, in real-time, on the Jobs page.
To view the logs for a specific job, click the corresponding More Actions button, and then View Logs. The Logs page is displayed and contains data regarding the indicated job.
Click the corresponding View Details button. The Job Details window is displayed. Here you can find information such as the name of the process, the environment where the job had been executed, the Robot which executed it, start and end times of the job, and input and output values if defined.
To download the recording for a faulted job, click More Options > Download Recording. Execution media is downloaded according to your settings.
Updated 23 days ago