System Agents

Overview

System agents are pre-defined, system-controlled agent entries that provide dynamic agent ID mapping based on workflow states. System Agents are assigned to automation objects in the same fashion that normal agents and agent groups can be, but their runtime behavior is different depending on workflow state.  This allows a workflow to run on different agents while still using a pre-defined and static agent name.  System Agent mappings are resolved to the correct agent ID as each item in the workflow executes based on the System Agent being used. This allows a workflow to run on different agents while still using a pre-defined and static agent name. System agent mappings are resolved to the correct agent ID as each item in the workflow executes based on the system agent being used.

System agents are useful for creating generic workflows that take their lead from the automation objects that executed before them. They are particularly beneficial when coupled with agent groups, as they allow a workflow to alter its path as a result of an automation object that may have executed on one or more agents in the group.

Related Topics

ClosedBehavior

System agents consist of five pre-defined agent names that map at runtime to physical agents. How the mapping is performed depends on whether or not the system agent being evaluated refers to an automation object that was assigned to a single agent or agent group.

Relative mapping to a single agent - Triggered workflow

The table below outlines the mapping of system agents when the workflow is triggered and the System Agent’s mapping is relative to a single agent.

Name Resolution
Triggered Agent The individual agent that triggered workflow execution. This agent must be assigned to a triggering condition.
Condition Agent The individual agent assigned to the condition object that executed prior to the current automation object. This value is undefined until an in-line condition is encountered.
Previous Agent The individual agent assigned to the automation object that executed prior to the current automation object.
Default Agent The default agent as set in the Workflow properties.
Variable Agent The variable agent acts like a variable in a task. Any task assigned to the variable agent will run on the named agent instead. It is essentially a way to dynamically change the agent something runs on.

Relative mapping to a single agent - Manually executed workflow

The table below outlines the mapping of system agents when the workflow is run manually and the System Agent’s mapping is relative to a single agent:

Name Resolution
Triggered Agent The default agent as set in the Workflow properties.
Condition Agent The individual agent assigned to the condition object that executed prior to the current automation object. This value is undefined until an in-line condition is encountered.
Previous Agent The agent of the automation object that executed previous the current automation object. This value is undefined until a workflow item has been completed.
Default Agent The default agent as set in the Workflow properties.
Variable Agent The individual agent assigned to the automation object that last used a shared variable.

Relative mapping to an Agent Group

System Agents are arguably their most useful when Agent Groups are employed in a workflow. In such a case, System Agents allow a workflow to adapt at runtime to the conditions that match the situation that Agent Groups cause. Because an automation object may run on one or more agents, and because the Success and Failure of automation objects depends on the type of automation object itself, it can be difficult in a workflow to know what agent should be responsible for executing the next automation object.  System Agents solve this problem by allowing the agents to change dynamically based on the result of the previous automation object.

If a System Agent is to be resolved based on an automation object that has been assigned an Agent Group, the same rules that determine what the AMResult, AMCondition and AMTrigger system datasets are populated with determine how the System Agent will resolve. The table below outlines how the mapping of System Agents is accomplished when the System Agent’s mapping is relative to an automation object that has been assigned to an Agent Group:

Name Resolution
Triggered Agent The individual agent in the group that triggered workflow execution. This can only be a single agent in the group. If two or more agents in the group simultaneously triggers execution, a new workflow for each agent is started. Therefore, this system agent is always well-defined in a workflow.
Condition Agent The individual agent in the group that first satisfied the condition. If the condition is time sensitive (normally when it is used as a wait object) and no agent in the group satisfied the condition, the default agent of the group is used. When adding agents to an agent group, the first one on the list automatically becomes the default agent.
Previous Agent If the previous automation object is a task that has been assigned an Agent Group, the default agent of the group is used. If the previous automation object was a triggering condition, Previous Agent is the same as Triggered Agent. If the previous automation object was a condition, Previous Agent is the same as Condition Agent.
Default Agent The agent ID of the default agent as set in the Server Preferences.
Variable Agent The individual agent in the group that last used a shared variable.

ClosedAssigning system agents

System agents can be assigned to workflow objects such as tasks, processes and conditions in the same fashion as normal agents or agent groups.

To assign a system agent to a workflow object

  1. Drag a new or existing condition, task or process object from the Workflow Designer's Objects/Repository panel and drop it onto the main workspace.

  2. The newly created/added object is set to Default Agent.

  3. Double-click the agent name to display a drop-down list of available task agents, agent groups and system agents (as shown below).

  4. Select the desired system agent.

ClosedExamples

This section supplies a variety of examples regarding the use of System Agents grouped by standard workflows, where Agent Groups are not used, and more dynamic workflows, where Agent Groups are employed. In all examples, the correct value is shown in purple.

Example 1

In the example below, a triggering condition is set to execute the workflow if the hot-key combination Shift+Alt+9 is entered by a user on Agent 1. The task objects downstream are set to Previous Agent which will resolve to Agent 1. This allows the user to change the agent of the triggering condition at design time without having to alter the agent properties of every other item in the workflow.  

Example 2

Using the Triggered Agent option, a workflow can always run an automation object on the agent that originally triggered the workflow, regardless of where the current execution point is. The sample workflow below demonstrates this by capturing a triggering condition on Agent 1 then executing a task on Agent 2, another task on Previous Agent (which, in this case, would be Agent 2), then executes the final task on Triggered Agent (causing the task to run on Agent 1).

Example 3

The Condition Agent allows workflows to execute objects on the same agent that the previous condition executed on. This provides a logical separation from triggering conditions, which are used mainly to fire off a workflow and standard conditions, which are used as a wait or conditional objects. This can be important if a workflow is started on one agent but its process is dictated by conditions that occur on other agents. Below demonstrates a workflow that uses both Triggered Agent and Condition Agent to execute automation objects on static agents.

Example 4

As stated previously, System Agents are arguably their most useful when Agent Groups are employed in a workflow. For the next several examples, assume there exists a group named Agent GroupA that consists of three agents: Agent 1, Agent 2, and Agent 3.Agent 1, being the first agent in the group, is considered to be the ”default agent” of Agent Group A. Below illustrates a triggering condition (the Hot-key event) assigned to Agent GroupA. Assuming the hot-key is pressed on Agent2, the Delicious task set to run on Previous Agent will also execute on Agent 2, since Previous Agent will always evaluate to the individual agent in the group that satisfied the triggering condition.

Example 5

Using the same example as Example 4 above, we can achieve the same effect by using Triggered Agent in place of Previous Agent (shown below), since in this situation, they would evaluate to the same agent.

Example 6

Examples 4 and 5 can be combined to achieve a more elaborate workflow. In the workflow illustrated below, Agent Group A consists of Agent 1, Agent 2 and Agent 3. Assume that the hot-key combination Shift+Alt+9 occurs on Agent 3 and the task named Delicious executes on Agent 1. When the task completes successfully, the Wait 10s for Notepad condition executes on Previous Agent (in this case, Agent 1). If the Wait 10s for Notepad condition evaluates to Success, the Display Success task executes on the Triggered Agent (which is Agent 3, the agent where the trigger originally occurred). If the condition evaluates to Failure, the Display Failure task executes on Previous Agent (Agent 1).

Example 7

The example below displays the same workflow as above, but this time the Wait 10s for Notepad condition is set to execute on Agent Group A which consists of Agent 1, Agent 2 and Agent 3 and the Display Success task is set to Condition Agent. Since this is an Agent Group assigned to a condition, the Success arrow will be followed when one of the individual agents in the group satisfies the condition. If no agent in the group satisfies the condition, the Failure arrow is followed. Assuming that Agent 3 satisfies the condition, the task named Display Success will execute on Agent 3. If ten seconds elapses without the condition being satisfied on any of the agents in Agent Group A, the Display Failure task will execute on Agent 1, since that is the default agent for Agent Group A.