Process Migration
If you want to be able to migrate a process instance from one version of a process template to a later one, you will need to make sure that the data in the first process template is compatible with the second process template version. The Case Data Manager (CDM) component will do a compatibility check for all types of classes (Local or Case) whenever a new version of Business Data Project is deployed.
As much of the structure of the data comes from the BOM, you have to ensure that the BOM used by the two versions of the project is compatible. This means that the BOM used by the process template that you are migrating from must be a subset of the BOM used by the process template that you are migrating to.
Therefore, if you want to be able to migrate process instances from the old process template to the new version of the process template, you can only make compatible changes to the BOM. If incompatible changes are made to the BOM, there is a possibility that process instances will not be able to be migrated to the new version of the process templates.
A compatible change adds a new entity to a BOM, or makes an existing entity less restrictive, for example, the addition of a new class, or increasing the length of a text attribute from 50 to 60 characters. Examples of ‘incompatible changes’ include removal of a class, making an optional attribute mandatory, or adding a maximum value to an integer attribute that was previously unrestricted.
The following changes in the process template are considered as compatible when migrating a process instance from one version of a process template to a later one.
General Changes
Any BOM entity’s label can be changed (as long as the name remains the same).
Diagrams can be rearranged, annotated, and so on.
Changes to Class Attributes and Composition Relationships
The multiplicity of an attribute or composition relationship may be changed, as long as it makes it less restrictive (for example, it either increases the upper bound or decreases the lower bound) and it does not change between having a maximum multiplicity of 1 and greater than 1. Examples are given in the following table.
| From | To | Valid? |
|---|---|---|
| 1..5 | 1..8 | Yes - increase in multiplicity |
| 1 | 0..1 | Yes – made optional |
| 0..1 | * | No (cannot change from single to many) |
| 1 | 1..* | No (cannot change from single to many) |
| * | 1..* | No (might have zero) |
| 0..1 | 1 | No (might have zero) |
| * | 4..* | No (might have less than 4) |
The attribute type cannot be changed. If an attribute’s type remains the same, its restrictions may be altered, as long as they are less restrictive than the old restrictions.
| Restriction | Permitted Change |
|---|---|
| Default value | May be changed |
| Lower limit | May be decreased or removed if a former lower limit was set |
| Upper limit | May be increased or removed if a former upper limit was set |
| Lower limit inclusive | May be changed from false to true |
| Upper limit inclusive | May be changed from false to true |
| Maximum text length | May be increased |
| Number length | May be increased |
| Decimal places | May be increased (if length increased by the same amount or more) |
Change to a Primitive Type
When the type has a BOM Native Type as its superclass, it may be altered subject to the compatible change rules described in Changes to Class Attributes and Composition Relationships.