Modeling Assets with Things, Thing Templates, and Thing Shapes
Things are representations of physical devices, assets, products, systems, people, or processes that have properties and business logic.
With the purpose of defining one behavior once and reusing it across your solution, ThingWorx facilitates modeling your solution by providing Thing Templates and Thing Shapes. Thing Templates provide the base functionality to Things with their properties, services, events, and subscriptions. Thing Shapes allow a reuse of properties across assets in a single solution.
Things inherit functionality from Thing Templates. A Thing Template can derive one or more additional characteristics by implementing Thing Shapes.
End users interact with Things for information in solutions and for reading or writing data.
Best Practices for Creating Things, Thing Templates, and Thing Shapes
Use the following best practices while creating Things, Thing Templates, and Thing Shapes:
• Define naming conventions for your Things, Thing Templates, and Thing Shapes. Keep the following points in mind:
◦ Use a standard nomenclature across entities. For example: You could use a unique namespace prefix across different entity types to avoid conflicts.
◦ Provide meaningful names to the entities.
◦ Try to include a good description for every entity that you create.
◦ Avoid ambiguous names.
◦ Avoid long entity names wherever possible.
See the section Naming Entities for more information.
• Use tags for all the entities that you create and modify. For complex solutions, this helps in differentiating between various modules of the same solution or multiple solutions. For customers, it helps to differentiate between entities of different solutions on the same instance of ThingWorx Platform. As a developer, it permits you to quickly filter through the entities in ThingWorx Composer and export a module of the solution for testing purposes. It is recommended to set up naming conventions for tags, especially if you plan to use different tags across different modules of the same solution.
• Group the same entities in a module into a project. Each module has its own project.
• Whenever possible, use Thing Shapes.
 |
It is recommended that you use Thing Shapes to define properties and services. If you define properties and services on a Thing Template, it is difficult to move their definitions to a Thing Shape.
|
◦ Define all properties, services, and events at a Thing Shape level.
◦ A Thing Template is used to group Thing Shapes and to support inheritance.
◦ Whenever possible, do not implement properties or services on Thing Templates and Things.
◦ Allow service overrides on Thing Shapes and Thing Templates.
◦ Ensure that out-of-the-box Thing Shapes and Thing Templates are non-editable.
◦ Define annotations to identify supported APIs. This ensures that services and properties are maintained on upgrade.
• Use a Thing Shape to encapsulate specific functionality. By using Thing Shapes, you can easily add new functionality to existing Thing Templates in ThingWorx. Do not implement Thing Shapes in the Thing directly. Inherit the characteristics of the Thing Shape in the Thing through the Thing Template.
For example, if you have implemented your assets using custom Thing Templates and Things, it is simple to add a Thing Shape to those Thing Templates. However, if the properties or services were defined directly on a Thing Template, you will need to recreate all your assets to use the new functionality, because the base Thing Template cannot be changed for a Thing Template or a Thing.
• Do not derive Things directly from system Thing Templates. It is recommended that you create custom Thing Templates that derive from the base Thing Templates provided by ThingWorx. This allows you to add additional functionality later by implementing additional Thing Shapes and adding them to your Thing Templates.
• If your solution has many connected remote devices or if it uses the ThingWorx Edge Micro Server or the EDGE SDKs, use the RemoteThing Thing Template instead of the GenericThing Thing Template as the base Thing Template. Depending on whether you need file transfer or tunneling, use the RemoteThingWithTunnels, RemoteThingWithFileTransfer, or RemoteThingWithTunnelsAndFileTransfer Thing Template. It is recommended to automate the process of adding remote bindings through scripts that check if unbound remote Things exist, and create them automatically on the ThingWorx Platform. This enables you to automatically have Things created on the ThingWorx Platform, as new devices are shipped and go into production.
|
|
You cannot change the base Thing Template after you create a Thing or Thing Template.
|
• Use networks to define relationships between your Things. In a network, a Thing can be the parent, child, or sibling of another Thing. This enables you to model a hierarchical structure.
Sustainability Considerations
This section describes other considerations as applicable:
• Security
◦ Ensure that you make all the Things, Thing Templates, and Thing Shapes non-editable.
◦ Add appropriate visibility, run time and design time permissions on the Thing Templates or Thing Shapes.
◦ Define user organizations, user groups, and users that have access to the Thing Shapes, Thing Templates, or Things.
• Upgrades
◦ Organize Things, Thing Templates, and Thing Shapes using projects and tags. This allows you to perform tasks such as searching, exporting, modifying visibility permissions, and identifying entities for an upgrade.
◦ Ensure that you use the right naming convention while creating entities. This saves costs of renaming entities during upgrades.
• Extension and Customization
◦ To extend component Things, create subtype Thing Templates that inherit the OOTB Thing Templates.
◦ Override services and properties in the subtype Thing Templates as instructed by the extension developer.
◦ Introduce new services and properties in new Thing Shapes.