Application Architecture
The ThingWorx Applications are currently composed of three products: Real-Time Production Performance Monitoring (RTPPM), Connected Work Cell (CWC) and Asset Monitoring and Utilization (AMU). The ThingWorx Applications are built leveraging the ThingWorx Platform, and are composed of mashups, Things, and services packaged together as multiple extensions. Each application corresponds to its own extension in ThingWorx and once installed, extensions are read-only.
Although each of the extension are independent, when more than one ThingWorx Applications are installed together they share a common database, which stores configuration and process data. The ThingWorx Application Core simply called Core acts as an intermediary between the database and the applications. The ThingWorx Application database is connected to the ThingWorx Platform via a database Thing. The Core is composed of Things and services allowing interactions with the database in a standard way for all three applications. The Core also contains an ad hoc extension called Core UI, which is a set of standard screens and features that are shared by all ThingWorx Applications.
Using the ThingWorx Platform and its connectivity, especially with Kepware, data from the plant floor is captured and treated within Core to be used within the ThingWorx Applications.
The ThingWorx Applications expose different services and endpoints used to extend the applications and develop custom extensions. Whether the goal of the extension is to ingest or retrieve data from the Core database, this document will cover the different options and endpoints the applications expose for customization.
In order to understand how an extension can be developed it is important to understand how data flows between different components of the ThingWorx applications as well as where that data is housed. The figure below illustrates this flow.
Upon implementation, all application mashups use Utils Things and services. Utils Things and services are front-end oriented with the goal being to manipulate data making it usable via a front-end display. Utils Things can be part of the Core or not, depending on functionality.
If some database data must be transferred to or from a mashup, the service on the Utils Thing calls a service living on a manager Thing. In summary, Utils Things can be interpreted as front-end wrappers for manager services.
Manager Things and services live in the Core and allow interaction with the database and ensure data consistency and integrity. A manager can be seen as a group of database tables with similar functionalities or a common purpose. Typically, each database table is represented in ThingWorx by a Thing Shape containing services interacting with this table. Combining those Thing Shapes together in a Thing Template and a Thing makes a manager. Manager services contain business logic to interact with the database. The database is connected to the ThingWorx Platform using an external database connection Thing; therefore, all manager services refer and call this database Thing.
As a reference, the current database structure and list of current managers can be found
here.
|
|
Utils services are retro-compatible through versions while manager services are not.
|