Change management and artifacts generation

In the context of Data Services Generation (DSG), change management refers to the situation where you modify an aspect of a model (adds a metric, monitoring context, and so on) and want to deploy this new version of the model, preserving the existing data.

You accomplish these tasks by modifying the tables that already exist in the database to support the earlier version in such a way that they are now compatible with both versions. For example, if a new version of a model deletes one metric, and adds a new metric, the monitoring context table will be modified such that it contains columns for both the deleted metric (to support the original version) and the new metric (to support the new version). All existing data retained though old instances will have null values for newly defined metric columns.

The following changes are supported between models (metric refers to metrics, stopwatches, and counters):

Increasing a metric string length
Decreasing metric string length
Deleting of a metric (but see special restrictions on changes to dimensions)
Adding of a metric (but see special restrictions on changes to dimensions)
Adding of a monitoring context
Deleting of a monitoring context
Modifying of correlation predicates for a monitoring context
Addingof a trigger
Adding and Deleting of evaluation time on a trigger
Creating of a new dimension
Deleting a dimension
- Only acceptable if all metrics in the dimension are also deleted
Creating of a new measure
Creating of a new fact attribute

The following changes are not supported. Data Services Generation will throw an error if it detects them:

Changing a stopwatch from accumulating to non-accumulating, or vice versa
Changing the dimension that a metric is assigned to
Changing the set of metrics for a dimension or the dimension key; this can happen in various ways:
- Creating a new metric, assigning it to an existing dimension
- Deleting a metric that is part of an existing dimension
- Toggling the isPartOfKey flag for a metric in a dimension
Changing a metric from being a fact attribute to a dimension attribute or a dimension attribute to a fact attribute

The Data Services Generator examines the previous version of the monitor model and the new version. If there are no previous versions, the Data Services Generator generates the artifacts that correspond to the new model. If a previous version of the new model exists, the Data Services Generator examines the differences between the deployed model version and the new model version. If changes are found, the appropriate scripts are regenerated to modify the databases based on these differences. For more information about creating a new model from an existing one, see the IBM® Business Monitor Development toolkit documentation.

If Data Services Generation detects that the differences between two model versions include incompatible changes, such as deleting a metric that was part of a dimension, it will report an error. At this point, the user has two options. Either undo the change to the model that is causing the problem and redeploy it, or deploy this new version of the model as an entirely independent model, rather than as a new version of an already deployed model.

To deploy a new version of a model as an entirely independent model instead, it is necessary to first change the ID of the model. In addition, the IDs of all the monitoring contexts contained in the model must also be changed to be unique so that they do not collide with the IDs 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 Monitor server.

Another consideration when deploying new versions of existing models is the Data Movement Services (DMS) artifacts. When deploying a new version of a model, the DMS artifacts produced during Data Services Generation can be one of the following three possibilities:

No DS_DMS_Setup.zip file produced: Assuming DSG itself reported success, the lack of a DS_DMS_Setup.zip file indicates that the changes between model versions did not warrant any changes to DMS. You do not have to do any DMS setup for this model version and in the administrative console step wizard you can simply confirm the DMS setup step.
DS_DMS_Setup.zip file produced, but it does not contain any start or stop scripts: The changes you made in the model require changes to the DMS configuration, so you will need to run the DMS setup scripts, but you will continue to use the start/stop scripts that were produced in earlier versions, or produced by the start/stop script-generator tool if you used it.
DS_DMS_Setup.zip file produced, and it contains start and stop scripts: In this case when starting DMS you must run these new start scripts along with any previous start scripts that were produced for earlier model versions. Alternatively you can use the start/stop script-generator to consolidate all the scripts associated with all versions of the model.