ThingWorx Model Definition in Composer > Modeling > Thing Groups > Thing Groups FAQ
Thing Groups FAQ
Question
Answer
Can I configure delegation of run time permissions to Thing Groups?
No, because Thing Group entities do not have the same set of services that a Thing entity does. This is true for custom Things created from out-of-the-box Thing Templates and Thing Shapes, and especially true for custom Thing Templates and Thing Shapes.
How do I enable Thing Group membership related audit log messages?
This must be enabled in the platform-settings.json file. Refer to Audit Subsystem Messages for more information.
How do I get a list of 'All Things' that I can manage or use in ThingWorx applications?
There are two ways to view all Thing entities that you have permission to view:
• In Composer: Select Things from the Modeling section in Composer to view all Things that you are permitted to view. A Thing Group is not necessary if the user has the needed permissions to Composer and the visibility permissions to view the Things collection's Things.
• Via REST API: ThingWorx provides APIs for REST, JavaScript services, and Java extension logic to get the list of Things from the Thing collection. The user context of the logic that invokes that Thing collection list API determines the visibility permissions used and determines the list of Things returned. ThingWorx applications can be written using JavaScript services and Java extensions. For REST APIs, the resource URI is /Thingworx/Things endpoint.
What Thing Groups or Things does a user or user group have visibility to?
Authorized users of services can determine this as follows:
1. Determine the organizations and/or organizational units a user or user group belongs to as a member.
2. Using an iterative approach, such as a for loop in ThingWorx service scripts, iterate through all Things/Thing Groups and call the GetVisibilityPermissions or GetVisibilityPermissionsAsJSON services to see if any of the organizations/organizational units are contained within the list retrieved in the first step.
* 
Configuring permissions to invoke these services should be done with care as the services check exact memberships and return lists without concern for visibility of the Groups, thus they are intended for use by privileged API workflows.
What are the performance implications of having Thing Group visibility permission delegation enabled?
When Thing Group Visibility Permission Delegation is enabled,performance impact will vary, based on several deployment configurations that include:
• If the user is an administrator or the owner of the Thing or Thing Group, it does not require further checks into the visibility permission delegation functionality.
• Explicit Thing/Thing Group visibility permissions that are acceptable and valid for the requesting user do not require further checks into visibility permission delegation functionality.
• The layout (depth, width, number, etc) of Thing Group hierarchy models impact the visibility check algorithm across that hierarchy's participants.
• The rate of Thing Group membership change (model change) that invalidates previous visibility checks that requires re-computation in the previous bullet point.
• The rate that a particular Thing/Thing Group's visibility is accessed may require a re-computation if the previous visibility check data is no longer available.
* 
If visibility permission delegation is disabled, then visibility check performance is aligned to the direct Thing/ThingGroup visibility check performance.
How do I get a list of all Things within a model/Thing Template to use in ThingWorx applications?
To get a list of all Things that are visible to you:
* 
Axeda Models are represented in ThingWorx as Thing Templates.
• Use a service call (via REST, JavaScript service, Java extensions) to one of the QueryImplementingThings services on the Thing Template and Thing Shapes:
◦ QueryImplementingThings
◦ QueryImplementingThingsWithData
◦ QueryImplementingThingsWithNamedData
◦ QueryImplementingThingsWithPropertyHistory
◦ QueryImplementingThingsWithNamedPropertyHistory
The following services can be used without providing query parameters:
• GetImplementingThings
• GetImplementingThingsWithData
How do I model a region's Things to use in ThingWorx applications?
A region is a geographic area or division that can be modeled using model tags, property values, Thing Group entities, and so on.
Thing Group entities provide native hierarchy functionality that allow for nesting regions within regions as a hierarchy. You can provide visibility to the Things and Thing Groups within a hierarchy to specific set of users.
1. Create a Thing Group using the REST API, services in ThingWorx, or through the Thing Group entity UI.
2. Customize details of the Thing Group entity by providing additional entity model data such as name, description, and tags.
3. Add any Things or sub-region Thing Groups as members of a Thing Group via the Thing Group member REST API and/or services.
How do I list a region's Things?
There are a few options, depending on how you implemented a region and how you marked your region's Things. You can use model tags (no hierarchy provided), string property values (no hierarchy provided), or Thing Groups (hierarchy provided).
• If you used model tags or string property values, you can use various search resource services, or if the Thing Template/Thing Shape is known, you can use various QueryImplementingThings, QueryImplementingThingsWithData, QueryImplementingThingsWithNamedData, QueryImplementingThingsWithPropertyHistory, GetImplementingThingsWithData, etc. related services to get a list Things that fulfill the search criteria.
• If you implemented your regions fully or partially as Thing Groups, you can locate the Thing Group for a particular region and invoke services that return the list of Things without query criteria.
How do I model a customer's Things to manage and/or use in ThingWorx applications?
A customer, company, corporation, or division can be modeled using model tags, property values, or Thing Group entities. Using Thing Groups for these modeling examples provides functionality that allows for nesting business or other similar non-geographic constructs as a hierarchy. You can provide visibility to the Things and Thing Groups within the hierarchy to a specific set of users:
1. Create a Thing Group by using the REST API and/or services in ThingWorx or through the Thing Group entity UI.
2. Customize details of the Thing Group entity by providing additional entity model data such as name, description, and tags.
3. Add any Things or sub-region Thing Groups as members of the Thing Group via the Thing Group member REST API or use services to leverage the native nesting/hierarchy functionality.
How do I list a customer's Things?
There are multiple options that depend on how you implement a customer and mark your customer's Things. You can use model tags (no hierarchy provided), string property values (no hierarchy provided), or Thing Groups (hierarchy provided), among others.
• If you use model tags or string property values, you can use various search resource services, or if the Thing Template/Thing Shape is known, you can use various services such as QueryImplementingThings, QueryImplementingThingsWithData, QueryImplementingThingsWithNamedData, QueryImplementingThingsWithPropertyHistory, GetImplementingThingsWithData to get a list Things that fulfill the search criteria.
• If you implemented your customers fully or partially as Thing Groups, you can locate the Thing Group as a customer and invoke services that return the list of Things without query criteria.
How do I model a system's Things to manage and/or use in ThingWorx applications?
There are multiple options:
• Use THINGNAME as the base type for the properties defined on a Thing. This allows you to show that the Thing that has those properties is a container Thing that contains the Things referenced by those properties. Those Things, with names that are the values of the THINGNAME basetype properties, are considered contained Things. You can also strongly type those properties to allow specific contained Things that implement specific Thing Shapes or Thing Templates.
• Define/utilize a network for this scenario when a contained Thing is only contained by one node within the network. If a Thing is contained by multiple nodes within one network, use the former scenario.
• If the previous approaches do not suffice, you can also use the general features of Thing Groups to satisfy application logic or model requirements.
How do I model a group of Things with the same location such as "My House" or "My Business"?
Since these Things share the same location, you can use model tags, property values, Thing Groups, or contained Things to model the group.
If you use a Thing Group to hold these Things as members, you can also nest Thing Groups with Things to categorize and collect Things into sub-groups of the "My House" or "My Business" co-located Things. In this example, the nested/sub-groups can be rooms or floors within a building.
How do I associate locations to region?
Use the LOCATION base type (latitude, longitude, and elevation data) for property definitions or create your own infotable of location metadata for locations such as street addresses or other coordinate system or locale formats.
If an entity model or ThingWorx application requires knowledge of location data that is "owned or contained within a given region", depending on the application run time performance demands, authorizations to that location data can be stored in data tables. This information can exist at various hierarchical levels within Thing Groups as members of those Thing Groups or through other custom/application specific associations such as model tags or data tags.
How do I associate locations to a customer?
Use the LOCATION base type (latitude, longitude, and elevation data) for property definitions or create your own infotable of location metadata for locations such as street addresses or other coordinate system or locale formats.
If a entity model or ThingWorx application requires knowledge of any format of location data that is "owned or contained within a given customer, company, corporation or division", depending on the application run time performance demands, authorizations to that location data can be stored in data tables. This information can exist at various hierarchical levels within Thing Groups as members of those Thing Groups or through other custom/application specific associations such as model tags or data tags.
How do I add a location to one or more Things?
ThingWorx provides a rich model for assigning data to Things through Thing, Thing Template, and Thing Shape property definitions whose values are set, stored, and retrieved from the Thing instance.
If your Things are of a specific common type and share a common Thing Template, or you have Things of different types but do or can share a common Thing Shape, then properties can be defined once on that common Thing Template and/or Thing Shape.
The value of the property definition from a Thing Template or Thing Shape is set on the Thing. If you have a property defined with a LOCATION, STRING, or other base type, then you can set the value of that location property on the Thing. The value of that property depends on its base type or the custom format of the data you want to support within your application, such as coordinates or street addresses.
How do I add a customer to one or more Things?
ThingWorx provides a rich model for assigning data to Things through Thing, Thing Template, and Thing Shape property definitions whose values are set, stored, and retrieved from the Thing instance.
If your Things or assets are of a specific common type and share a common Thing Template, or if you have Things and assets of different types but do or can share a common Thing Shape, then properties can be defined once on that common Thing Template and/or Thing Shape.
The value of that property definition from a Thing Template or Thing Shape is set on the Thing. If you have a property defined as a STRING or other base type, then you can set the value of that customer, company, corporation, or division name property on the Thing or Asset. The value of that property depends on its base type or the custom format of that data you wish to support within your application such as customer, company, corporation or division name.
How do I visualize the children of a Thing Group?
In Composer, open an existing Thing Group. Click the Membership Details tab, locate the combo-box and select Direct Child Thing Groups.
To view the details of a Thing Group child, click on the entry on the Membership Details tab's panel and select View. From that view, go to the Membership Details to see the direct children Thing Groups of that Thing Group.
How do I visualize the parent Thing Groups of a Thing Group?
In Composer, open an existing Thing Group. Click the Membership Details tab, locate the combo-box and select Direct Parent Thing Groups.
To view the details of a Thing Group child, click on the entry on the Membership Details tab's panel and select View. From that view, go to the Membership Details to see the direct children Thing Groups of that Thing Group.
When do I use Networks versus Thing Groups?
Networks are recommended for directed connection relationships, such as machines in a production line, between Things. Thing Groups are recommended for grouping Things by common characteristics, such as template types, location, customer, or region.
While networks and Thing Groups both provide the ability to model hierarchies, there are differences that should be considered.
• Networks require utilizing the network to follow any given node's children and parents.
• Networks cannot contain another network entity as a member.
• Thing Groups provide the ability to have hierarchy and navigation of the hierarchy. Because of this, modeling regions, customers, and other hierarchy relationships is recommended for Thing Groups.
• Thing Groups can be reused in other Thing Groups as children to create reusable subset branches of multiple hierarchies.
Was this helpful?