Persistence store relationships

Device message flow

A typical device metric flows into the IoT tool from various sources. The IoT tool might use an MQTT message on a bidirectional connection for direct device management features and continuous connectivity. The IoT tool might use a Kafka topic or gateway connectivity. These messages are often persisted to enable guaranteed delivery, specifically in the MessageSight or Kafka subcomponents of the IoT tool.

These subcomponents are not typically backed up or restored. The components handle reliability through replication. Each message goes through a lifecycle. Restarting the IoT tool reestablishes this lifecycle and starts processing new messages.

Device registration and metric timestamp data

The IoT common service registers new device types and device instances into both MongoDB metadata store and RDBMS before a schema is created for that device to store its timestamp metric values. The registration for the relational database management system is completed in a different transaction boundary. If a single MongoDB node fails, replication from one of the other nodes accomplishes recovery automatically. If MongoDB has a multinode loss of data before the next backup, inconsistencies can arise.

If MongoDB has a multinode loss of data before the next backup, the device is not registered in the recovered MongoDB, but the device still has the historical timestamp metric data and some authentication and metadata. The device must be re-created to authorize IoT connections and receive new metric data. To avoid a multinode loss, use a script to automate IoT device registration and before you enable connectivity to the IoT tool common service to receive time-series data, record a MongoDB backup.

Data dictionary relationships

The Asset Data Dictionary is a service that handles complex graph relationships between assets and devices, device tag hierarchies, and other advanced features. The Asset Data Dictionary uses a relational database management system for persistence and references identifiers in different application service schemas, which might be in the same relational database management system instance or different instances that have different transaction boundaries. If the application services share the relational database management system instance, back up and restore all the schemas together to keep them consistent. If the schemas are spread across multiple relational database management system instances, restoring data for Maximo® Manage or Maximo Monitor independently of the Asset Data Dictionary might require performance of those asynchronous operations.