Groups

Groups are used to combine several similar system objects (Users, Device Servers etc.) to make batch operations more convenient. It is very easy to execute an operation over all objects in a group. Groups also provide an easy way to set similar settings to all group members or automatically replicate configuration changes between them.

Another feature of groups is integration with the Common Data facility that allows to have "master" values of group member properties. Changes of master value are automatically applied to all group members.

New members can be added to the group at any time. The maximum number of group members is not limited. When a group is deleted, group members are not destroyed.

Note for advanced AggreGate administrators: group members cannot be accessed by context paths such as group_context_path.member_name. Instead, the normal paths of group members should be used to access them. For example, even if we put the admin user in the usergroup1 group, we won't be able to access it using a path such as usergroups.usergroup1.admin. It may be accessed by its normal path: users.admin.

Group members may be added to a group in LinkServer User Interfaces by dragging a context and dropping it on a group. If the context type is suitable for the group, it will be added. More information about the logic behind this operation may be found here.

Every group member context has a Remove from group action (

), which may accessed through its context menu in AggreGate Client System Tree or through similar facilities in other clients.

Groups provide an easy way to execute the same operation on several different objects. For example, the Group Actions menu for a Device group may have a "Send Message" action, used to send a text message to a device LCD. When using such an action, the user enters the message just once and it is then sent to all Device in the group.

Here is what the Group Actions menu looks like for a Device Server group (screenshot from AggreGate Client):

Groups also let you easily copy settings between group members in manual or automatic mode. In manual mode, some or all settings may be replicated from one group member to all other members. In automatic replication mode, the group monitors all members for configuration changes, and if such changes are detected, they're copied to all other members. This feature maintains group members in sync with each other.

Groups are tightly integrated with the Common Data facility. For example, it is possible to make a Common Table that will contain "master" value for a certain setting of all group members. When this master value changes, its new value is applied to all group members. See Integration With Common Data for details.

User groups are global. They can be created, accessed and managed only by users with administrative permissions. Device Server and Device groups belong to a specific user account and thus can be managed both by administrators and normal users (account owners).

Two contexts are used to administer groups: One is the general Groups context, which serves as a container for groups of a particular type. The other is the Group context, which represents one group.

ls_groups

Every Group context has a Replicate to children action, used to copy the settings from one group member to all other members. This action is very convenient to configure group members in the same way.

Groups also support auto-replication. Auto replication is controlled by the Replication Options property of a group. This property is a table, containing a list of properties (variables) appearing in the group member contexts. Auto-replication may be enabled or disabled separately for every property.

If the auto-replication option is enabled for a certain property, changes to its value in one of the group members are automatically applied to all other members. For example, if there are three Device Servers (A, B and C) in a group G1 and Device Server B is blocked (e.g. by editing its properties in AggreGate Client), Device Servers A and C will be automatically blocked as well. Auto-replication works in a single group only: if Device Server C is a member of two groups (G1 and G2) and was blocked during auto-replication in G1, other members of group G2 will not be blocked. This prevents unexpected 'domino' effects, whereby one change to a replicated group creates unexpected chaos.

When an auto-replicated group detects changes to a property of one of the group members, it takes the value of this property (gets the Data Table containing the value of the context variable) and sets that value for the same property of other group members using a Data Table Smart Copy operation.

Integration with Common Data allows to have "master" values of properties of group members. When this master value is changed, changes are automatically applied by the group to all its members that have this property.

•

First, create a common table to contain the master value, using the Create New Table From Variable action of any Common Data context. The source variable for common table creation should be a variable of one of the group members. Its value will be copied to all other group member when the "master value" feature is enabled for it. The common table must be located in the User Common Data container under the group owner, or in the Global Common Data container.

•	Then, enable the Use Common Table setting in the Replication Options for the record you want to replicate. If the Common Table was properly created in the previous step, the Current Common Table with Master Value setting will show the description and location of the master value:

If Common Tables that can be used as a master value for a property were created in both Global and User Common Data containers, the user's container will be used.

Let's say your Device is a time recorder that has "Bell Table" setting, defining several daily alarms. You can drag the time recorder and drop it on the Global Common Data in AggreGate Client, launching a Create New Table From Variable action. You'll now be prompted to select the variable to be used as a source for the new common table. Select "Bell Table":

Once the variable has been selected, a new common table is created in the global container. It contains the list of alarms that were defined in the dropped Device:

Next, launch the Group Properties action to configure the group. The group settings dialog will open. Here is what the Replication Options look like:

The Use Common Table setting can be enabled for Bell Table because a corresponding master value is found in the Global Common Data container. Let's enable it and save changes.

Now our group monitors changes to the Bell Table located in the common data. If someone edits the table, updated bell times will be saved to all time recorders in the group.

Field Description	Field Name
Group Name. Name of the group context, required to refer to this alert from other parts of the system. It should satisfy the context naming conventions, and cannot be changed once the alert is created.	name
Group Description. Textual description of the group. This is also a description of the group context.	description

This property defines parameters of replication performed by the group for every setting of its members.

Field Description	Field Name
Property. Name of the variable (property) to apply the replication rule to.	variable
Description. Description of the above property.	description
Auto-replication. Use automatic replication for this variable.	replicate
Use Common Table. Use a master value for this property. This setting may be enabled only if Auto-replication is disabled for this property and Current Common Table with Master Value is not empty (i.e. a Common Table containing a master value exists).	useMaster
Current Common Table with Master Value. Description and location of the Common Table that may be used as a master value of a property. This is a read-only field.	master