Working with Agent Groups in BPA Server

An Agent Group is a distinct Automate BPA Server object that contains one or more Agents within a logical group. They can be used as workflow objects in place of individual Agents to distribute conditions and tasks to multiple machines across an enterprise. The use of Agent Groups can be more convenient in situations where multiple agents need to be selected for automated execution. Instead of assigning each individual agent, you can simply create an Agent Group which contains the specific agents to be assigned.

CREATING & MANAGING AGENT GROUPS

Creation of an Agent Group is simple and straightforward.  From the Agents section of the SMC, clicking the Agent Groupsfolder 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.


Figure 1. Agent Groups screen in Automate BPA Server Management Console.

 
Creating New Agent Groups

To create a new agent group:

1.   Right-click the Agent Groups folder and select New Agent Group from the right-click menu.
       OR 
     Click the New button located on the header panel. A new icon appears with the name New Agent Group as the default assigned name. 

2.  Click the default name to enter a new name.
      OR
     Right-click the newly created object, select Rename from the right-click menu and enter the desired name.

Assigning Agents to a Group

To add agents to an existing Agent Group:

1. From the Agent Groups section of the Server management Console, highlight the desired group and click the Editbutton. -- OR -- Right-click the group and select the Edit button from the right-click menu. The Agent Group screen appears.
2. Highlight the desired agent from the Available Agents list and click the Add button. The Agents in Group list is then populated with the selected agent. 
3. Click the Apply button (bottom-right corner) to save the settings.

NOTE:  The same agent can be assigned to multiple groups.

Defining a Group’s Primary Agent
 
An Agent Group always contains a primary agent used in specific situations, such as when a task needs to return a result based on an Automate variable. You can define the primary agent in a group by ensuring that it is the first one on the list. 

To set a specific agent as the primary agent:

1. From the Agent Groups section, highlight the desired agent from the Agent Groups list and click the Move Up button until the agent is moved to the top of the list.
2. Click the Apply button to save the settings.

Viewing & Editing Agent Group Properties

Each Agent Group includes a set of general properties which allows you to view and edit 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 of the SMC, select the desired group and click the Properties button or simply double-click the group. The general properties and settings of that agent group are shown, as illustrated below.


 
Figure 2. General Propertied for an Agent Group.

General properties are divided into three sections – Details, Notes and Security. 


Details

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

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. From the Available Group/User Name field (left pane), highlight the desired user or group and click the Add button. This will populate the Selected Group/User Name field (right pane) with the selected user or group, as shown below in Figure 3.
2. Highlight the desired group/user from the Selected Group/User Name field and set its permissions to Allow or Denyunder the Permissions field, as shown below in Figure 4.
3. Upon completion, click Apply to save changes.

Figure 3. Setting security profiles for Agent Groups.



Figure 4. Setting security profiles for Agent Groups (continued).

 

AGENT GROUP 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, error handling, processing and object deployment to an agent may be different depending on whether the type of automation object being executed happens to be a task, triggering-condition or non-triggering condition.    


Tasks

When an Agent Group is assigned to a task object, upon execution, an instance of the task is executed on all agents in the group simultaneously. The workflow suspends at the task object until execution on all agents are completed (either successfully or unsuccessfully). The task must complete successfully on all agents within the group in order for the Success (green) arrow extending from the task to proceed. If the task fails on one or more agents in the group, the Failure (red) arrow, if present, proceeds instead.

Additionally, if the task is set to return a result based on a variable (i.e. AMTask.Result), the corresponding Result (blue) arrow matching the ‘AMTask.Result’ as set by the primary agent is followed regardless of whether or not the task completes successfully on all agents. This is because only the primary agent’s result is taken into account when evaluating Result arrows in a workflow. 

For example, imagine that Agent Group A which appears in the sample workflow illustrated below contains three agents named Agent 1, Agent 2 and Agent 3 (in that order).


Figure 5. A workflow containing an Agent Group.

 
During workflow execution, the Failure Chooser task will execute simultaneously on Agent 1, Agent 2 and Agent 3. The workflow halts until the task completes on all three agents. The table below details how the workflow proceeds in a number of cases:

Additionally, If the Failure Chooser task is set to also return a result based on a task variable (i.e. ‘AMTask.Result’), the corresponding Result (blue) arrow matching the ‘AMTask.Result’ 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 ‘AMTask.Result’ with 20 but the task fails on all agents, both the Failure and Result (with the value of 20) arrows would follow. Conversely, if Agent 2 sets ‘AMTask.Result’ to 20 but Agent 1 does not, and the task fails on all agents, only the Failure arrow would follow.

  
Non-triggering Conditions

When an Agent Group is assigned to a non-triggering condition (a condition that does not initiate workflow executuion, but rather, used as an evaluation or wait object in the middle of a workflow), the Success arrow extending from the condition proceeds if the condition evaluates to TRUE for at least one agent in the group. If the condition evaluates to FALSE on all agents in the group, the Failure arrow, if present, proceeds instead. The first agent that evaluates the condition to TRUE is used to populate the ‘AMCondition’ dataset; however, all other agents that evaluates to TRUE are ignored. This allows the workflow to wait for and/or determine if a condition is true on any one agent in the agent group.

For example, in the the sample workflow shown below, Agent Group A is assigned to a Process condition that waits for the Notepad.exe process to start within 10 seconds. Imagine that the group consists of Agent 1, Agent 2 and Agent 3 (in that order).


 

Figure 7. A workflow containing an Agent Group and a Wait.

 
During workflow execution, the Delicious task will execute on Agent sbr. Upon successful completion, the workflow proceeds to the Wait 10s For Notepad condition. The workflow will wait up to ten seconds on each agent for the Notepad.exe process to start. The table below details how the workflow proceeds in a number of cases:

Triggering Conditions

When an Agent Group is assigned to a triggering condition, (a condition set to trigger workflow execution), the condition is set as a trigger on all agents contained in the group. The workflow starts when the triggering condition is fired on any of the agents in the group. The ‘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.

Let’s use the sample workflow illustrated below as an example. This workflow contains a Key condition which initiates workflow execution when the SHIFT+ALT+9 is pressed.  Imagine that Agent Group A consists of Agent 1, Agent 2 and Agent 3(in that order).



Figure 6. A workflow containing an Agent Group and a triggering condition.

 
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. Triggering conditions do not return failure or result values, therefore, the Failure and Result arrows are irrelevant in this workflow.

 

CONCLUSION

Agent Groups not only allow you to easily implement your business processes, they also add intelligence and diversity to workflows by allowing execution to commence upon an event occurring on any one machine in the Agent Group or allowing a workflow to wait for any event to occur on any machine assigned to the Agent Group.