Upcoming BPA Feature: Advanced Workflow Capabilities Using Agent Groups

by marjo martinez, in Tech Talk, posted 3/3/09

One of the many new features that will be introduced in the upcoming release of BPA Server version 7.0.8.0 is the concept of Agent Groups. An Agent Group is essentially a single element that contains a collection of two or more agents within a logical group. Agent Groups can be used in place of individual agents within a workflow. This allows a single trigger condition the ability to set off tasks assigned to numerous agents in one workflow.  This also provides a single task the ability to execute on multiple agents simultaneously. Additionally, Agent Groups allow the workflow to wait for and/or test for a condition to be true on any one machine in the agent group.

This article will outline how to create Agent Groups and explain their properties and behavior in a running workflow determined by the type of object each Agent Group is applied to.

 

Creating and Managing Agent Groups

From the Agents section of the SMC, clicking the Agent Groups folder displays the Agent Groups screen as shown below. Here, you can create new agent groups, set permissions and manage the properties of existing agent groups.

Creating New Agent Groups

 

1. To create a new agent group, select the Agent Groups folder.

2. Click the New button. A new icon appears with the name New Agent Group as the default assigned name.

3. To assign a new name for the agent group, click the default name or right-click the group and select Rename from the right-click menu and enter the desired name.

NOTE:  A unique name must be assigned for each Agent Group

 

Assigning Agents to Groups

1. To add agents to an agent group, select the specified group and click the Edit button or right-click the group and select Edit from the right-click menu. The Agent Group screen appears as shown below.

2. Highlight the desired agent from the Available Agents list and click Add to add to the Agents in Group list. To remove agents, highlight the agent from the Agents in Group list and click Remove. After assigning the appropriate agents to the group, click OK to save the settings and close the Agent Group screen.

3. To modify the order of agents within a group, select the agent and click the Up or Down button.  Order is important because the first agent in the list becomes the “primary” agent.  Only the result of the primary agent in the group is considered when evaluating Result arrows in a workflow.
 
NOTE: The same agent can be assigned to multiple groups.

 

General Properties

Each agent group includes a set of general properties which allows you to view specific details, enter custom notes and assign permissions for that particular group. To access an agent group's general properties from the Agent Groups folder, select the desired agent group and click the Properties button, or double-click the group. The general properties of that agent group appear as shown below.

 

Details

The Details section displays various attributes about the agent group. The following fields are included:

Field or CheckboxDescription
NameThe assigned name of the user
Created ByThe user who created this specific user as indicated in the Users section of the SMC.
Created OnThe date/time when the user was initially created.
Modified OnThe date/time when the user's properties were last modified.
Version DateThe date of the current BPA version
Globally EnabledIndicates whether or not the user is globally enabled. This option is enabled by default.

 

Notes

The Notes section provides a location where you can enter descriptive information or custom notes in regards to the specified agent group. Notes entered will appear in various reports and other sections of the SMC.

Security

The Security section allows you to set permissions for existing users or user groups on this agent group. Instructions are as follows:

1. Click the Add button. The Add a Group/User screen appears where pre-existing users or groups can be selected.



2. Select the Groups or Users tab, highlight the desired group/user and click the OK button. The selected group or user is then added to the Groups or Users list as shown below.



3. Highlight the user or group and set the available permissions to Allow or Deny. Upon completion, click Apply to save changes.  Below is the set of permissions and the items that they correspond to:

 WorkflowTaskConditionUserUser GroupAgentAgent GroupFolder
CreateXXXXXXXX
ReadXXXXXXXX
EditXXXXXXXX
DeleteXXXXXXXX
MoveXXXXXXXX
Enable/DisableXXXXXXX 
Manually ExecuteXX      
Manually StopXX      
Modify StagingXXX  XX 
ImportXXX    X
ExportXXX    X

 

Properties

Each Agent Group has properties that are specific to that particular instance of the group.  These properties are:

ID
A unique identifier for the group.  This property is normally used for internal purposes only and would not typically be shown to an end-user.
 
Name
The “friendly” identifier for the agent group.  This is the property that is shown in the Workflow Designer and other parts of the software to identify the group in a more usable fashion than what the ID provides.  The name shall be unique amongst agent groups, but should not be relied upon as the unique identifier for the agent group (the ID property should be used for such purposes)

Description
A user-defined description for the group.

Agents
The list of agents that belong to a group.  An agent can belong to more than one group, but the same agent cannot be added more than once to the same group.  Order is important as the first agent in the Agent Group is considered to be the “default” agent for error handling, resolution and result population.

 

Behavior

An Agent Group’s behavior in a running workflow is determined primarily by the type of object the Agent Group is applied to.  Characteristics such as object deployment to an agent, as well as error handling and processing, vary depending on the automation object being executed.

Tasks

When an Agent Group is assigned to a Task object, the task is executed on all agents in that group simultaneously.  Workflow execution suspends at the task object until task execution on all agents completes.  The task must complete successfully on all agents within the group in order for the Success arrow extending from the task to be followed.  If the task fails on one or more agents in the group, the Failure arrow (if present) is followed.  A task’s object’s result is determined by the result of the task that runs on the “default” agent in the Agent Group.

For example, assume Agent Group A consists of Agent 1, Agent 2 and Agent 3 (in that order).  Consider the following workflow:


In this situation, the “Failure Chooser” task will execute simultaneously on Agent 1, Agent 2 and Agent 3.  The workflow waits until the task completes on all three agents.  The chart below details how the workflow proceeds in several cases:

ResultWorkflow Progression
All tasks completed successfully on all agentsThe Success arrow is followed, and “Display Success” task executes on agent “sbr”
All tasks failed on all agents    The Failure arrow is followed, and “Display Failure” task executes on agent “sbr”
The task completes successfully on Agent 1 and Agent 2, but fails on Agent 3   The Failure arrow is followed, and “Display Failure” task executes on agent “sbr”

 

Additionally, If the “Failure Chooser” task is set to also return a result based on a task variable (i.e. AMTaskResult), the corresponding Result arrow matching the AMTaskResult as set by Agent 1 is followed regardless of whether or not the task completes successfully on all agents.  This is because only Agent 1’s result (being the default agent in the group) is considered when evaluating Result arrows in a workflow.

For example, if Agent 1 populates AMTaskResult with 20 but the task fails on all agents, both the “Failure” and “20” arrows would be followed.  Conversely, if Agent 2 sets AMTaskResult to 20 but Agent 1 does not, and the task fails on all agents, only the “Failure” arrow would be followed. 

Triggering Condition

When an Agent Group is assigned to a Condition object acting as a triggering condition, the condition is set as a trigger on all agents in the agent group.  The workflow starts when the triggering condition is fired on any of the agents in the group.  The workflow AMTrigger dataset is populated relative to the agent that the triggering condition occurred on.  This allows one trigger condition to be assigned to multiple agents in one workflow.

For example, assume Agent Group A consists of Agent 1, Agent 2 and Agent 3 (in that order).  Consider the following workflow:

Once a user presses Shift+Alt+9 on Agent 1, Agent 2 or Agent 3, the workflow will follow the Success arrow and run the “Display Success” task on agent “sbr”.  Note that the “Failure” and “20” arrows would never be followed in this workflow since triggering conditions do not currently return Failure or Result values.

Agent Grouping tied to triggering conditions is especially powerful when coupled with Workflow Runtime Properties.

Conditions

When an Agent Group is assigned to a Condition object that is not a triggering condition, the condition is successful if the condition evaluates to true for one or more agents, and fails if the condition evaluates to false for all agents.  The first agent that evaluates the condition to true is used to populate the AMCondition workflow dataset, and all other true conditions are ignored.

For example, assume Agent Group A consists of Agent 1, Agent 2 and Agent 3 (in that order).  Consider the following workflow:

In this situation, the “Delicious” task will execute on agent “sbr”.  Once the task completes, the “Wait 10s For Notepad” Process Condition begins.  Because an Agent Group was assigned to the condition, the workflow will wait up to ten seconds on each agent for the notepad.exe process to start.

The chart below details how the workflow proceeds in several cases:

ResultWorkflow Progression
Notepad starts within ten seconds on Agent 2.  Notepad does no start on Agent 1 or Agent 3.The Success arrow is followed, and “Display Success” task executes on agent “sbr”.  The AMCondition variable is set with the result data from Agent 2.
Notepad starts within ten seconds on Agent 3, then Agent 2 and Agent 1.The Success arrow is followed once the result from Agent 3 arrives, and “Display Success” task executes on agent “sbr”.  The AMCondition variable is set with the result data from Agent 3.  The remaining results are discarded.
Notepad does not start within 10 seconds on any agent in the group.The Failure arrow is followed, and “Display Failure” task executes on agent “sbr”.

 

Note that the “20” Result arrow would never be followed in this workflow since conditions do not currently return result values.


Conclusion

The addition of Agent Groups in BPA 7.0.8.0 allows workflows to become more robust due to the fact that a single trigger condition will have the ability to execute tasks assigned to numerous agents in a single workflow and allow a single task the ability to execute on multiple agents simultaneously.  Additionally, workflows will become more intelligent with the use of Agent Groups because they allow a means for a workflow to wait for a particular condition to be true on any one machine in the agent group.