Versioning in monitor models

You can have multiple versions of a monitor model for a process application and its snapshots, though only one version can be active at any given time. Data captured by older versions is still visible on the dashboard.

When a process is changed in a way that affects monitoring (for example, when custom tracking groups, timing intervals, or auto-tracked fields are added, modified, or deleted), generate a new version of the monitor model that captures those changes. When using generated monitor models on the Process Center server, new versions are generated and deployed by clicking File > Update Tracking Definitions. On process servers, a new version of the generated monitor model is created and deployed each time a snapshot with business monitoring support is deployed.

Note: Versioning for custom monitor models is done at the discretion of the process application developer, who decides when a new version of the monitor model must be deployed. For custom monitor models created in IBM® Integration Designer, the Integration Designer developer makes the changes to the monitor model and changes the model timestamp, as described in "Synchronizing and updating monitor models for process applications."

Monitor models are identified by an ID (for example, bmon_ORDPROC_MAIN) and a version timestamp (for example, 2011-01-01T12:00:00+0400). Models with different IDs are unrelated. Models that share the same ID and have different, increasing timestamps are related and are considered versioned.

The event consumption mode is a combination of the state of the monitor model and the transport type. Monitor models have one of the following event consumption modes:

CreateNewInstances: Events are processed and new monitoring context instances can be created as a result.
UpdateExistingInstancesOnly: Events for existing monitoring context instances are processed, but events that would create new root monitoring context instances are ignored.
InactiveSaveEvents: Events are saved for a future monitor model version to process. The events are not processed by the current monitor model version.
Inactive: Events are not distributed to this monitor model version.

Only the most recent version of a monitor model can have an event consumption mode of CreateNewInstances.

When a new version of the model is deployed with a process application snapshot, older versions are quiesced and their event consumption mode is set to UpdateExistingInstancesOnly. This means that events related to new monitoring context instances will go to the new version, while events relating to existing monitoring context instances will go to the old version.

Note: In a situation where a process application is tracked by both a generated model and one or more custom monitor models, the latest version of each can be active. This is possible because the custom and generated monitor models have different IDs.

When you deploy a new version of the monitor model, a set of tables and views is created in the MONITOR database to support that version. Additionally, a set of cross-version views is created to support dashboard queries that require data across all the current and previous model versions. Data that did not exist in previous model versions results in null values being returned.

Versioning limitations

Because the database views union data together across model versions, some types of changes are not supported. If you change the data type of an existing auto-tracked field or tracking group, any subsequent deployment of the generated monitor model fails. In order to make changes to data types, you must remove the existing monitor model and create a new one that has a different ID. See Replacing a generated monitor model with a new monitor model.