...

There are situations when users want to execute existing workflows and jobs with a different Agent, for example, if the Agent previously used Agent 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 within an Agent Cluster due to unavailability of an Agent within an Agent Cluster, job execution is automatically is handed over to a different Agent.
  • Fail-over with Agent Clusters is subject to the agreements of the JS7 - License.
  • For details about automated fail-over see see the JS7 - Agent Cluster article.

Assignment of Jobs to Agents

When adding an Agent to a Controller then:

• the Agent ID is specified that 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 that can be modified later on.
• the URL of specified for an Agent is specified that 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.

Should 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 a workflowworkflows,
• the workflow has workflows have to be deployed later on to apply such changes.
  
  

...

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

• Use of the Manage Controllers/Agents page to modify an 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 too 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 to with the newly assigned Agent.

...