Introduction

There are situations when users want to execute existing workflows and jobs with a different Agent, for example, if the Agent previously used is not available.

The following wording applies:

  • Switch-over: suggests that users modify the Agent configuration to manually switch to a different Agent for execution of existing jobs.
  • Fail-over: suggests that due to unavailability of an Agent within an Agent Cluster, job execution is automatically handed over to a different Agent.

Assignment of Jobs to Agents

When adding an Agent to a Controller then:

  • the Agent ID specified cannot be modified later on, except when forcibly resetting the Agent or dropping the Agent's journal.
  • the Agent Name and optionally any number of Alias Names which are specified can be modified later on.
  • the URL specified for an Agent can be modified later on.



Within a workflow a job is assigned an Agent - more precisely:

  • the job is assigned an Agent Name or
  • the job is assigned an Alias Name of an Agent.

On deployment of a workflow to a Controller the Agent assignment of a job is replaced by the Agent ID. This is required as the Controller has to keep track of Agent locations and deployed workflows and/or jobs.

If jobs are to be permanently assigned a different Agent then:

  • the assignment of the job to an Agent should be updated.
  • the Configuration view offers a search/replace function to update Agent assignments in workflows,
  • workflows have to be deployed later on to apply such changes.


Users who do not want to permanently modify Agent assignments of jobs but who want to temporarily use a different Agent without redeployment of workflows can switch-over to a different Agent.

Switch-over of Agents

This scenario assumes that Agent assignments to jobs in a workflow are not modified and that workflows should not be redeployed.

Instead, the URL of an Agent configuration can be modified to point to a different Agent. This includes performing the following steps:

  • Use the Manage Controllers/Agents page to modify the Agent. The Agent ID remains unchanged, only the URL is modified to point to an existing Agent.



  • In the next step the newly assigned Agent has to be forcibly reset to accept assignment of the Agent ID. Users should be aware that a forced reset will inevitably hijack the Agent for the given Controller. This also applies to Agents that are assigned different Controllers. Therefore double-check that the assigned URL effectively points to the Agent that you want to assign. 



  • After ca. 20s the Controller should be coupled with the newly assigned Agent. The Controller will then automatically forward any scheduling objects such as workflows assigned to that Agent ID to the Agent that is available with the updated URL. This step typically is performed within a few seconds. Users can then execute any previously deployed workflows with the newly assigned Agent.