Standard Design Pattern
The standard design pattern provides the most straightforward way to develop a building block that adheres to the building block structure and allows for discovery by the rest of the solution. This is the most common design pattern used when developing building blocks. This type of building block can contain UI elements as well as business logic and data storage. It is ideal for use by field teams or customers who want to create their own functionality in addition to content delivered by PTC.
The following diagram represents the most fundamental requirements for a set of entities to be considered a building block.
In the diagram, arrows with hollow heads and solid lines (
) indicate that an entity extends from the entity to which the arrow points, and arrows with hollow heads and dashed lines (
) indicate that an entity implements the entity to which the arrow points.
) indicate that an entity extends from the entity to which the arrow points, and arrows with hollow heads and dashed lines () indicate that an entity implements the entity to which the arrow points.Required Entities
The following entities are required for the standard design pattern:
• Project—ThingWorx project entity containing the building block entities. The recommended naming convention includes the project name in the names of all entities that are part of the building block. For example, if project is named PTC.BuildingBlock, the names of all entities in the building block start with the project name: PTC.BuildingBlock.EntryPoint, PTC.BuildingBlock.Management_TS, and so on.
• Entry Point—Inherited from the PTC.Base.ComponentEntryPoint_TT Thing Template, this entity contains all building block metadata, such as the name, description, version, list of dependent building blocks, and so on. Each building block inherits from the PTC.Base.ComponentEntryPoint_TT Thing Template for its own entry point Thing Template, for example PTC.BuildingBlock.EntryPoint_TT. An entry point Thing is created from this Thing Template, for example PTC.BuildingBlock.EntryPoint. The DeployComponent service on an entry point Thing can be overridden to perform an action when the building block is first deployed on the ThingWorx server.
• Manager—The building block manager is the primary service layer for the building block, providing multiple capabilities for the building block. First, it acts as an abstraction layer for entities calling into the building block. Second, it is used for configuring menu items, contained mashups, and which managers to use when more than one is defined. Each building block should have a manager Thing Template that extends from the PTC.Base.CommonManager_TT, for example, PTC.BuildingBlock.Manager_TT. The manager itself is a Thing based on the building block manager Thing Template. The manager Thing Template also implements a Thing Shape (PTC.BuildingBlock.Management_TS). This Thing Shape should contain all services needed for the building block. For building blocks developed by PTC, these services can be overridden as a customization, allowing solution developers to override default services for their own purposes. For more information, see Customizing Services.
Optional Entities
The following diagram shows optional entities that can be included in the standard design pattern. In the diagram, the PTC.MfgModel building block is used as an example of a building block with model, asset, or equipment hierarchy, whose Thing Templates implement the model logic Thing Shape in the standard design pattern building block. Entities with dashed outlines are optional entities that are included in this pattern for the specific purposes described below. Other ThingWorx entities can also be included in the standard design pattern, but these entities have specific meaning.
In the diagram, arrows with hollow heads and solid lines () indicate that an entity extends from the entity to which the arrow points, and arrows with hollow heads and dashed lines () indicate that an entity implements the entity to which the arrow points.
) indicate that an entity extends from the entity to which the arrow points, and arrows with hollow heads and dashed lines () indicate that an entity implements the entity to which the arrow points.The following optional entities are included in the standard design pattern:
• Security entities—Permission user groups can be created and used to define different permissions for each building block. A user role is simply another user group that is added to each of the permission user groups.
• Mashups—The standard design pattern allows mashups to be added as a part of the building block functionality. These could be main mashups that are tied into the master mashup, or contained mashups that are used by different building blocks. It is up to the building block developer to determine which features are in which building block.
• Model logic entities—The model logic Thing Shape is intended to be used by mashups or other components that enforce organizational security for equipment by using the organizations as required by ThingWorx. This is needed if the use case calls for visibility control for individual equipment. The services contained in the model logic Thing Shape are applied to the equipment hierarchical entities. They provide wrapped services to call into the appropriate configured manager through the management Thing Shape for the building block. All managers are registered on the DefaultGlobalManagerConfiguration configuration table on the PTC.BaseManager Thing. Managers can also be configured on the ManagerConfiguration configuration table of any entity that implements the PTC.Base.ConfigManagement_TS Thing Shape, such as the manager Thing for a building block, or an equipment model Thing that is based on a Thing Template which implements the Thing Shape (for example, PTC.MfgModel.DefaultWorkUnit_TT). This allows different models to use different managers. For example, two sites can have different managers that they want to use since they get data from different sources.
When a service references another manager, it first looks at the ManagerConfiguration table on the entity that is calling the service to see if there is an entry configured for the referenced manager. If it does not find an entry there, the service then looks at the DefaultGlobalManagerConfiguration configuration table on the PTC.Base.Manager Thing.