Building Blocks
A "building block", also known as a component, is an implementation pattern in ThingWorx designed to produce smaller, independent, self-contained yet feature-rich modules that can be used to build solutions. Each building block is created to serve a specific purpose, such as external data integration, solution capabilities, user interface additions, platform functionality, or equipment manipulation and management. Building blocks are stacked together in an ordered fashion to make up a solution, starting from the base building block up to the solution building block.
An individual building block is made up of a set of ThingWorx entities collected into a ThingWorx project, which is packaged as a ThingWorx extension. Each building block is based on the base building block (PTC.Base) which enables the whole building block architecture. This base building block establishes the starting structure for each building block with the following entities:
• ThingWorx project entity—Encapsulates and manages all of the entities that make up the building block.
• Entry point entity—Based on the PTC.Base.ComponentEntryPoint_TT Thing Template, this entity is used to contain all building block metadata, such as the name, description, version, list of dependent building blocks, and so on.
• Manager—Based on the PTC.Base.CommonManager_TT Thing Template, this entity is used to contain the functions of a building block, including services, properties, configurations, events, and so on.
• Permissions—Permission user groups can be created for a building block based on the security access needs for the building block. A typical example of a permission user group could be more granular access to CRUD services.
The following diagram illustrates the basic content contained in a building block. As shown, all building blocks are dependent on the base building block. For more information, see Base 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.Building Block Types
Building blocks are generally grouped into four different types, indicative of their underlying design pattern:
• UI building block—A building block exposing the user interface as its main interaction interface. It can include logic for UI purposes in addition to mashups. UI building blocks generally call into an abstract or standard building block.
• Abstract building block—A building block containing service definitions, exposing the APIs as its main interaction interface. It is intended to have only abstract elements and is usually accompanied by an implementation building block. It can also contain mashups as needed.
• Implementation building block—A building block providing the service implementation to connect to external data sources or provide data-level business rules. It generally overrides services contained in the abstract component.
• Standard building block—A building block that is not intended to be overridden with a unique implementation, but is generally a combination of the abstract and implementation building block types. A standard building block can also contain mashups as needed. Most customer-developed building blocks will be of this type as it is not as complex as the other building block types.
Building Block Categories
Building blocks are generally grouped into four common categories that are loosely related to their dependence on other building blocks:
• Solution building block—Usually a very simple building block that has dependencies on all of the building blocks needed for the solution. This building block category is a basic implementation of the entry point from the base building block within a project entity. For example, the DPM building block (PTC.DPM).
• Solution-specific building blocks—A combination of user interface type building blocks and standard or abstract type building blocks, organized based on how the solution goes to market. These can be split into two further categories based on the reusability of the business logic capabilities:
◦ Module presentation building blocks—These are generally user interface type building blocks. For example, the Production Dashboard building block (PTC.ProductionDashboard) in the DPM solution.
◦ Module logic building blocks—These are building blocks that provide a business logic layer across many underlying building blocks. For example, the operation KPI building block (PTC.OperationKPI) in the DPM solution calls into a number of the domain-specific building blocks.
• Domain-specific building blocks—These building blocks provide a collection of domain-specific capabilities that have minimum dependencies. For example, the shift building block (PTC.Shift), reason code building block (PTC.ReasonCode), and so on.
• Common building blocks—The common set of building blocks that can be used by all solutions. For example, the base building block (PTC.Base), user management building block (PTC.UserManagement), model management building block (PTC.ModelManagement), and the database connection building block (PTC.DBConnection).