Monitor model versions

To fix problems with a monitor model, or to make enhancements to the model (such as adding a metric or a monitoring context), you can create and deploy a new monitor model version. You can modify aspects of a monitor model and then deploy the new version of the model for future event processing and dashboard reporting, while preserving the data collected from previous model versions.

Note: Administrative privileges are required to deploy and uninstall all monitor models. In addition to deploying monitor model applications, other operations that are performed automatically require administrative privileges. Assign the Administrator role to the user who deploys and removes monitor model applications.

To create a new version of a monitor model, use the Monitor Model editor in the Business Monitor development toolkit. Update the model version time stamp, but leave the model ID as it is. IBM® Business Monitor considers a later time stamp to be a later version of a model. Updating the model ID makes it appear to IBM Business Monitor that it is a new model. Use the Monitor Model editor to produce an enterprise archive (EAR) file for each model version that is created. Deploy the new version of the monitor model using the WebSphere® Application Server administrative console, just as you would deploy a new model, but ensure that the application name does not match the application name of any previously deployed monitor model version. The application name can be changed at Step 1 of the deployment options menu, as described on the "Deploying monitor models" page.

A monitor model can have multiple versions deployed but only the most recent version can have a event consumption mode of "Active." Any number of previous versions, however, can have a version consumption mode of "Active (no new MC instances)." This means that events related to new monitoring context instances will go to the new version, while events related to existing monitoring context instances will go to the old version.

Alternatively, if you want active instances from the previous versions to be processed by the new model version, you perform the following tasks:

Before deploying the new model version, switch the version consumption mode of the previous version to "Inactive".
After deploying the new model version, transfer instances from the old version to the new version, and then change the version consumption mode of the new version to "Active".

Events for the old model version during this process will be recovered by the new model version when its event consumption mode is changed to "Active".

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. Because the database views union data together across model versions, there are some limitations on the changes supported among monitor model versions.

You cannot change the data type of an existing metric, and you cannot change hierarchies of monitoring contexts. All other monitor model changes are supported. The schema must always be in sync with the model versions. For example, you cannot deploy model version 1 and model version 2 without the schema, and then add the schema for both. You would have to deploy model version 1, deploy the schema for model version 1, deploy model version 2, deploy the schema for model version 2, and so on. This practice also applies to removing a monitor model.

To deploy a new version of a model as an entirely independent model instead, you must first change the ID of the model. In addition, you must change the names of all the Java EE projects generated during EAR generation to make them unique, so that they do not collide with the names used by the already deployed model. If you deploy a model as an independent model rather than as a new version, no tables or data are shared between the models, just as would be the case for any other two independent models deployed on the IBM Business Monitor server.

Because the data movement service always works on a version-specific basis, no special user intervention is needed to deploy a new monitor model version when data movement service is enabled.

Tip: Be aware that a duplicate instance can be created in version 2 of a monitor model if all the following conditions are true:

A single inbound event can both create a new instance and update an existing instance.
The event can appear twice in the event stream related to a single monitoring context instance.
Multiple versions of this monitor model behave in the same way for this inbound event.
An instance exists in version 1 of the monitor model.
The event is sent again by the event producer after version 2 of the monitor model is installed.