System Agents

System Agents are pre-defined and system controlled agent entries that provide dynamic agent ID mapping based on workflow states.  System Agents can be assigned to automation objects in the same fashion that regular 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.

System agents are useful for creating generic workflows that take their lead from the automation objects that executed before them.  They are especially useful when coupled with Agent Groups, as they allow workflows to alter their runtime behavior based on the result of an automation object that may have execute on one or more agents in an Agent Group.

Behavior

System Agents consist of four 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 one agent or an Agent Group. The table below outlines the mapping of System Agents when the workflow is triggered and the System Agent’s mapping is relative to one agent:

Name

Resolution

TriggeredAgent

The agent that triggered the workflow.

ConditionAgent

The agent of the condition object that executed previous the current automation object. This value is undefined until an inline condition is encountered.

PreviousAgent

The agent of the automation object that executed previous the current automation object. This value is undefined until a workflow item has been completed.

DefaultAgent

The agent of the default agent as set in the Workflow properties.

 

The table below outlines the mapping of System Agents when the workflow is run manually and the System Agent’s mapping is relative to one agent:

Name

Resolution

TriggeredAgent

DefaultAgent

ConditionAgent

The agent of the condition object that executed previous the current automation object. This value is undefined until an inline condition is encountered.

PreviousAgent

The agent of the automation object that executed previous the current automation object. This value is undefined until a workflow item has been completed.

DefaultAgent

The agent of the default agent as set in the Workflow properties.

 

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

TriggeredAgent

The agent in the group that triggered the workflow.  This can only be one agent in the group.  If more than one agent in the group triggers, a new workflow for each agent is started.  Therefore, this System Agent is always well-defined in a workflow.

ConditionAgent

The agent in the group that first satisfied the condition.  If no agent in the group satisfied the condition, the default agent of the group is used.

PreviousAgent

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, PreviousAgent is the same as TriggeredAgent.  If the previous automation object was a condition, PreviousAgent is the same as ConditionAgent.

DefaultAgent

The agent ID of the default agent as set in the Server Preferences.

 

Examples


This section provides some examples of the usage of System Agents, grouped by standard workflows, where Agent Groups are not used, and more dynamic workflows, where Agent Groups are employed.

Example 1 - In the example below, a triggering condition is set to execute on sbr, but the task objects downstream are set to PreviousAgent.  This allows the user to change the agent of the triggering condition at design time without having to alter the agent property of every other item in the workflow.  

 

Example 2 - Using TriggeredAgent, 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 workflow below demonstrates this by capturing a triggering condition on agent sbr then executing a task on agent SCOTT64NB, another task on PreviousAgent (which, in this case, would be SCOTT64NB), then executes a task on TriggeredAgent (causing the task to run on sbr).

 

Example 3 - ConditionAgent allows workflows to execute agents on the same agent that the previous condition executed on. This provides a logical separation from triggering conditions and standard conditions, which can be important if a workflow is started on one or more agents but it’s process is dictated by conditions that occur on other agents. Below demonstrates a workflow that uses both TriggeredAgent and ConditionAgent to execute automation objects on Static Agents.

 

Example 4 - As stated previous, System Agents are arguably their most useful when Agent Groups are employed in a workflow. For the next several examples, assume there exists an Agent Group A that consists of three agents: Agent 1, Agent 2 and Agent 3. Agent 1, by being the first agent in the group, is considered to be the ”default agent” of Agent Group A. Below illustrates a triggering condition (the Hotkey event) is assigned to Agent Group A.  Assuming the hot-key is pressed on Agent2, the ”r;Delicious” task will also execute on Agent 2, since PreviousAgent will evaluate to the agent in the agent group that satisfied the triggering condition.

 

Example 5 - Using the same example as Example 4, we can achieve the same effect by using TriggeringCondition in place of PreviousAgent (shown below), since in this situation they evaluate to the same agent.

 

 

Example 6 - The two can be used together to achieve a more elaborate workflow. In the workflow illustrated below, we assume that Agent 3 pressed the hotkey.  Task ”r;Delicious” is set to execute on agent sbr. When it returns, the Process condition executes on PreviousAgent (in this case, sbr). If the Process condition evaluates to True, the Display Success task executes on the TriggeringAgent (Agent 3), and if the condition evaluates to False, the Display Failure task executes on PreviousAgent (sbr).

 

Example 7 - The workflow below shows the same workflow as before, but this time the Notepad condition is set to execute on Agent Group A, and Display Success is set to ConditionAgent. Since this is an Agent Group assigned to a condition, the Success arrow will be followed when the first agent in the group satisfies the condition. If no agents in the group satisfy the condition, the Failure arrow is followed. Assuming that Agent 2 satisfies the condition, the task named Display Success will execute on Agent 2. 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.

 

 

Example 8 - Below shows a workflow that would act the same as the one above, since the first automation object linked to a Success arrow of a condition object will resolve PreviousAgent and ConditionAgent to the same thing.

 

See Also


Agents | Agent Groups | Creating and Managing Agent Groups | Deploying and Managing Agents