IBM BPM, V8.0.1, All platforms > Measuring and improving business processes > Use business monitoring with process applications

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.

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.

Monitor models have one of the following Common Event Infrastructure (CEI) distribution modes:

Only the most recent version of a monitor model can have a Common Event Infrastructure (CEI) distribution mode of Active.

When a new version of the model is deployed with a process application snapshot, older versions are quiesced and their CEI distribution mode is set to Active(no new MC instances). 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.

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.

Use business monitoring with process applications


Related information:
Synchronizing and updating monitor models for process applications