Component Architecture
ThingWorx Navigate Component Composition
ThingWorx Navigate components are composite components. They are made of smaller sub-components, which together create powerful components that add business value.
Each ThingWorx Navigate components typically consists of two sub-components, a user interface sub-component and a business logic sub-component.
User Interface Sub-Component
The user interface sub-component can be one of two types:
• Mashup– aThingWorx mashup with multiple widgets and bindings.
• Widget– a single widget created outside of ThingWorx which is packed and imported into ThingWorx. It is typically written in web-component technology.
The user interface sub-component communicates with the business logic sub-component via services.
Business Logic Sub-Component
The business logic sub-component retrieves and processes the business data from the backend systems. The business logic sub-component is made up of ThingWorx entities such as Thing Shapes, Thing Templates, and Things. It communicates with the user interface sub-component via services.
Business logic sub-components are designed to enable powerful customizations. They provide the ability to:
1. Customize the business logic that retrieves and processes the data
2. Add new configuration points to support the business logic customization
Business logic sub-components follow the general ThingWorx model for enabling customization. An abstract Thing Template known as the Base Business Logic contains all the common functionality for the business logic sub-component. Each specific implementation is done in a Thing Template known as the Business Logic Implementation. Since ThingWorx services can be executed only on a Thing, each Business Logic Implementation Thing Template must be implemented by a Thing.
Component Configuration
The ThingWorx Navigate components are inherently configurable. During design time, when you add a component to a mashup, all the configuration parameters for the component can be specified as a single configuration JSON object. In the future, the plan is to provide a user interface that allows setting each parameter individually.
The structure of the JSON-based configuration object is defined inside the Base Business Logic. This configuration structure definition is called the Component Definition. It serves as a schema for the definition JSON and defines which configuration parameters are allowed, whether certain parameters are mandatory, and where in the configuration structure each parameter resides.
The Base Business Logic also includes specific points in the Component Definition that can be extended. These points are called Definition Hooks, and overridable hook services are attached to these points. The Business Logic Implementation uses these hook services to extend the Component Definition to accept additional configuration parameters needed by the specific implementation. This extended Component Definition is called Implementation Definition.
By design, ThingWorx Navigate components are robust. As such, a typical configuration JSON object consists of dozens of parameters to configure. To speed up work and avoid unnecessary errors, ThingWorx Navigate ships one or more predefined configurations with each component. Each of the predefined configurations is named and can be selected when configuring a component. Once you select a predefined configuration, the entire configuration JSON auto-populates in the configuration box, and you can make minor tweaks to the configuration without needing to create the entire configuration JSON.
