Storing Data with ThingWorx
Persistence Providers
In ThingWorx, a persistence provider enables the connection to a data store and the ability to perform a CRUD operation on that data. Persistence Providers are an entity type in ThingWorx. Currently, there are two basic variations of persistence providers:
• Model Provider – Responsible for ThingWorx model metadata and system data. Each ThingWorx installation must have only one model provider, and it must be defined prior to starting the server. All current model provider implementations include the data provider capabilities as well and the default data provider in a fresh installation. The default data provider can be changed via the platform-settings.json Configuration Details.
• Data Provider – Responsible for run time data ingested against the model elements such as streams, value streams, data tables, blogs, and wikis (from devices, interactive, external systems, etc.). Data providers (except for the model provider, which is also a data provider) must be installed after the server start-up and can be configured in Composer. There can be multiple data provider instances and one can be designated as the default in the platform-settings.json Configuration Details. It is also possible to create multiple data provider instances based on the default model provider package to connect to additional data stores of the same kind.
ThingWorx includes several persistence provider implementations that enable you to choose a database option that best fits your use case. ThingWorx has the ability to leverage multiple data stores, which provides immense flexibility that best meets your IT preferences and investments. The topics that follow in this section provide best practices for adapting the power of ThingWorx to your application environment.
Refer to the ThingWorx Deployment Architecture Guide for information about planning your deployment options.
Refer to ThingWorx Sizing to help determine the persistence provider that best suits your use case from a performance and scalability perspective.
Connecting to Non Supported External Databases
The ThingWorx platform can be enhanced to provide the capability to connect to virtually any data storage technology available via ThingWorx extensions. The built-in DatabaseThing provides the easy integration to any external ANSI SQL capable relational database that provides JDBC (Java Database Connectivity) driver such as Oracle. The connectivity via the DatabaseThing can be enabled by importing a simple extension that wraps the JDBC driver into ThingWorx. Extensions already exist for many of the popular databases, including Oracle, MySQL, and IBM DB2.
You can also use SQLThing instead of DatabaseThing to connect to an external database. For more information, see Connecting to an External Database.
|
Name
|
Default Value
|
Notes
|
|---|---|---|
|
JDBC Driver Class Name
|
com.yourdatabase.yourDriver
|
Depends on the driver being used.
|
|
JDBC Connection String
|
jdbc:mydb:/server:port/database?param=value
|
Defines the information needed to establish a connection with the database. Connection string formatting can be found at connectionstrings.com.
|
|
connectionValidationString
|
SELECT NOW()
|
A simple query that verifies return values from the database (regardless of table names to be executed).
|
|
Maxium Number of Connections
|
5
|
Maximum number of connections allowed
|
|
Database User Name
|
User name for the database
|
|
|
New Password
Confirm Password
|
Password for the new database user
|
|
|
Monitor Rate (milliseconds)
|
30000
|
Time in milliseconds for the monitoring interval
|
|
Number of Retries
|
1
|
Defines how many times the connection pool will try to acquire a new connection
|
|
Retry Delay (milliseconds)
|
2000
|
Time in milliseconds in which the connection pool will wait between acquire attempts
|
Connecting to Multiple Supported Databases
The persistence provider framework of the ThingWorx platform can be configured to use multiple data stores for a given data provider. This feature can be leveraged to distribute the data ingestion and query processing work load to multiple data stores to overcome the typical RDBMS vertical scalability limitations. This option can be considered if and when it’s determined that a single data store resource utilization (such as CPU, Memory, Disk IO) is very high and it’s not feasible to add more resources to the data store. Once the persistence provider is configured, the specific value stream, stream, data table, blog or wiki, instances can be configured to use the additional data provider store.
 |
Only one model store is allowed for a single instance of a ThingWorx application instance.
|
Refer to the 9.0 System Requirements for information on supported versions.