Abstract and Implementation Design Pattern
In the abstract and implementation design pattern, the abstract portion of the standard design pattern is split out into its own building block, for example PTC.BuildingBlock, separate from the implementation building block, for example PTC.BuildingBlockImpl. This allows the solution developer to provide multiple implementations of the same abstract building block, for example, PTC.BuildingBlockImpl1, PTC.BuildingBlockImpl2, and so on.
In the abstract building block, the service definitions in the management Thing Shape, for example, PTC.BuildingBlock.Management_TS, are empty, overridable services that are meant to be overridden in the implementation building block. In the implementation building block there is an additional manager implementation Thing Template, for example PTC.BuildingBlockImpl.Manager_TT. This manager Thing Template extends from the manager Thing Template in the abstract building block, inheriting the services defined in the management Thing Shape. The services are actually implemented in the implementation building blocks manager Thing Template.
The following diagram shows how the required entities for a building block are broken out into abstract and implementation building blocks.
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 in the abstract and implementation design pattern:
• Projects—Each building block (abstract and implementation) has a ThingWorx project entity containing the building block entities, for example PTC.BuildingBlock and PTC.BuildingBlockImpl. The recommended naming convention includes the project name in the names of all entities that are part of the building block.
• Entry Point—The entry point identifies the building block to the rest of the installed solution, including its name, version, dependencies, and so on. A service named DeployComponent can be overridden to perform an action when the building block is first deployed on the ThingWorx server.
The abstract building block extends the PTC.Base.ComponentEntryPoint_TT Thing Template for its own entry point Thing Template, for example, PTC.BuildingBlock.EntryPoint_TT. The implementation building block extends the PTC.DefaultConfiguration.EntryPoint_TT Thing Template for its own entry point Thing Template, for example PTC.BuildingBlockImpl.EntryPoint_TT.
An entry point Thing is created for each building block from its entry point Thing Template, for example PTC.BuildingBlock.EntryPoint and PTC.BuildingBlockImpl.EntryPoint, respectively.
• Manager—The building block manager is the primary services 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.
The abstract building block should have a manager Thing Template (PTC.BuildingBlock.Manager_TT) that extends from the PTC.Base.CommonManager_TT. The implementation building block has a manager Thing Template (PTC.BuildingBlockImpl.Manager_TT) that extends from the abstract building block’s manager Thing Template. The manager Thing for the implementation building block is created based on the implementation building block’s manager Thing Template.
The abstract building block’s manager Thing Template also has an implemented management Thing Shape (PTC.BuildingBlock.Management_TS). This Thing Shape contains all services needed for the component. These services are inherited by the implementation building block manager Thing Template, where the actual service implementation resides. 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.
The implementation building block’s manager Thing Template can implement any additional Thing Shapes that are required for that implementation. For example, many implementation building blocks in the DPM solution implement the PTC.DBConnection.DBManagement_TS Thing Shape so that they can access the DPM database.
Optional Entities
The following diagram shows optional entities that can be included in the abstract and implementation design pattern. In the following 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 abstract and implementation 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 abstract and implementation 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 abstract and implementation 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 abstract and implementation 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 and 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.