Thing Groups
Thing Groups are a referenceable entity type in ThingWorx that allow for Things and Thing Groups as its members. In addition to ThingWorx’s current permissions model, Thing Groups provide ThingWorx administrators the ability to manage at scale exposure of Things to only those that require access. There are the following main use cases for Thing Groups:
• Visibility permission management at scale - You can group Things so that only specified user groups or users can see them. Thing Groups allow for visibility permission delegation. This visibility permission delegation is enabled in theUser Management Subsystem. Visibility permissions delegation allows users to set the org units (and corresponding users and user groups) on Thing Groups and have that visibility setting delegated to the Things and Thing Groups (as well as any level of grandchildren) that are members of the Thing Group in which the visibility permissions were set. This is configured via organizations and org units that are specified in the visibility permissions of a Thing Group. The visibility permissions specified for these organizations/org units dictates the visibility of the direct Thing and Thing Group children, as well as any level of grandchildren Things in the hierarchy. You can also use Thing Groups to help organize user groups by delegating certain user groups to have visibility on specified Things that have certain properties.
• Thing Groups as a building block for mashups and other applications- Application developers can leverage Thing Groups to visualize hierarchies or scope custom workflows to a specified group of Thing.
The most common ways to group Things are by regions, customers, specific locations, and model number.
Thing Group Visibility Permission Delegation
A general understanding of how visibility permissions work in ThingWorx is helpful to understand the difference with Thing Groups. If a user has visibility permission to see a particular Thing, then they can see that Thing. But, when visibility permissions are enabled, if they have visibility permission to see a particular Thing Group, then not only can they see that Thing Group, but they can also see all Things within that Thing Group, regardless of the visibility permissions actually assigned on those Things. Likewise, they can also see all Thing Groups within that Thing Group, regardless of the visibility permissions assigned on those Thing Groups. Setting the ThingGroup Visibility Permission Delegation Enabled option to true in the User Management Subsystem on a Thing Group allows the visibility permissions on that Thing Group to get delegated down through all child Things and/or Thing Groups. Therefore, if a user can see a particular Thing Group, then they can see all of its hierarchical children Things and Thing Groups. An exception to this behavior occurs when a user is given collection level visibility permissions to all Thing Groups. Selecting the ThingGroup Visibility Permission Delegation Enabled option doesn’t affect collection level visibility permissions for Thing Groups. For example, if a user has the ability to see all Thing Groups due to collection level visibility permissions, it is not necessary that they can see all Things that are children of Thing Groups when visibility permission delegation is enabled. A user has to have visibility to a specific ThingGroup in order to see that children Thing and take advantage of visibility permission delegation.
If a Thing or Thing Group is deleted, all instances of its membership within all hierarchies are also deleted.
Thing Group Best Practices
• Do not use a 1:1 ratio for grouping Things and Thing Groups. For example, if you are using location as the grouping criteria, having only one Thing per Thing Group may result in performance impact at run time.
• Do not use high-frequency property value data as a basis of grouping Things in Thing Groups. If you are using property DataChange events to perform actions within ThingWorx, including operations on Thing Groups, such as visibility changes, memberships, package deployment, and other actions, be aware of the rate of the property change, their actions, and impacts on the resources (memory, CPU consumption, etc) of your platform at run time. If this rate is high, it may be difficult for subscriptions to perform certain operations for the resources available.
Example: Using Thing Groups for Visibility Management
You can use Thing Groups to manage visibility permissions. In this example, the West Coast users group can only access the West coast Things and the East coast user group can only access the East coast Things.
1. Enable the ThingGroup Visibility Permission Delegation Enabled option in the User Management Subsystem.
2. Create user groups.
3. Create an organization that contains an East coast org unit and a West coast org unit. Add the user groups and users as members of the org unit.
4. For each Thing Group, assign visibility permissions.
 |
Design time and run time permissions must also be set if necessary. These permissions cannot be set through Thing Groups.
|
5. Add or remove Things as members of Thing Groups via subscriptions and services. It is recommended to use a Thing Shape to define the properties (semi-static properties: those that change infrequently, such as location and customer, instead of telemetry data that changes frequently like temperature), services, and subscriptions that manage Thing Group membership.
Using Thing Groups with Additional Functionality
The following example illustrates how Thing Groups can be used with other functionality. In this example, the outcome is that when a sale occurs and it is recorded in a CRM system (such as Salesforce), a new Thing is created programmatically in ThingWorx and added to the appropriate Thing Groups, allowing the assigned users and user groups to have visibility to assets.
1. Set up subscriptions, services, and properties on a Thing Shape that will group Things into Thing Groups once Things are created or updated.
2. Connect a CRM system to ThingWorx using ThingWorx Flow. For every new sale of a smart connected product, a Thing in ThingWorx can be created with the appropriate Thing Shapes and Thing Templates with property values defined.
3. Set up user groups for visibility and user groups for run time and design time permissions. Add the appropriate visibility user groups to the org units. Add users to the appropriate user groups.