When a Case-Type is created, it is often not completely finished. One of the strengths if DCM would be the ability to adjust the Case when necessary, since the environment might also be changing. Doing so, you'll have to take some things into account. Some things being highly flexible to change, and some are harder. This guide explains the considerations when changing models on live cases.

Before starting your change

There are a few things to consider before you start changing your Blueriq model.

What is the nature of the change?

What is the type of change that needs performing? There are two different types to consider:

• I want only new cases to be changed, or cases created from a specific time in the future. Current cases should not be affected
• I want all cases, including the current cases which are already in progress. This means that probably all cases should be migrated.

If your change type is the first, you can see your changed model as a new Case-Type. So change the Case-Type label, create a new branch or repository, create the right shortcuts and make sure the new case-type can be started. From this moment on, you'll have to perform bugfixes on possibly two or more projects, but you can be sure changes on your newly created case-type are not affecting the old cases.

When the second change type is in order, one case-type will remain as maintainable object, but you'll have to consider what to migrate to the newly changed model. The remainder of this article is aimed at the second type, where migrations might be needed

Do I have cases in production?

When I possibly have cases in production, I might have to actively migrate these cases to the new situation. It is important to know what the change is, and what the consequences are for the production cases. For example, when all cases in production passed a certain stage, you might not need to actively migrate all cases to the new situation where something is changed in the early stage. On the other hand, changing logic might also have an effect that results that were positive before, become false in the future. Please take this into account (for example, the application has been deemed "complete", is not anymore since you added an extra requirement to this derivation). You must be aware whether you want the consequences of your change to any case in progress.

When there is no case yet in production, then the strategy of clearing your database and move on to your new model might fit best.

Performing the change

What needs migrating highly depends on what the change is. Keep in mind there are different places in the Case-Engine where state is stored. All with different characteristics.

The Process module has been changed

The process is persisted in the database. Any inconsistency in the database might lead to the current cases to not being able to continue anymore. The two types of data stored in the process database is the process profile and the tasks.

Process profile

The process profile holds all user-set attributes which have been mapped to the process engine. Either by an incoming message event or a data mapping after a task execution. Adding new attributes is possible, but renaming/removing attributes might be difficult. Currently there is no way to clear attributes/entities from the process profile. So when you want to delete an attribute, you have to make sure it is not mapped anymore, and wait until all cases containing this attribute have finished.

Since the profile is only ever updated when an action has taken place, it might be necessary to perform an active migration of all cases when something is changed in this module.

Because profile management is very limited in the process module, I would advice to only use simple model constructions, like singletons with attributes. Instances and relations are harder to maintain. User-set values are best to debug, since you can see the actual value in the database (for example by using the DCM-Maintenance-APP).

Process definition

The process definition (flows/tasks canvas) is also stored in the database in some way. All (sub) processes which are active, cancelled or completed are stored, together with all elements in the process (sub)flow. The process engine reads these from the database to determine what to do with them. Especially the open and started nodes are important to keep in mind when determining what to migrate.

Check the example given above. The DCM-Maintenance-APP shows the state in the database, where "Beoordelen" is open (so active), it is waiting on a condition node "condition" with ID 88, corresponding with the milestone in the flow. The task "Toevoegen Bewijsstukken" has already been completed once, but is open to being picked up again (ID 89 is completed and ID 93 is open again).

The process engine checks for each node with the status "open" in the database, what to do next during a process evaluation. This means that each node should exist in the process definition (model) so it can determine what to do. The process engine either uses a "persistency-id" of the given element, or the "name" within the process (sub)flow. When there is no match, it crashes.

This characteristic can make process migrations quite difficult. Adding items are not, but deleting them is not always possible. When an item needs to be deleted in the process, make sure all cases contain no node with status "open" or "started" anymore. One way of doing this, is to migrate in two steps:

1. set the precondition of the element-to-delete to FALSE, so during the first migration step, all instances of this element are cancelled
2. check there is no case left in production relying on this element, then delete the item and migrate again.

To keep the process as flexible as possible, please make sure the actions to perform are all ad-hoc. Changing processes when a sequence of tasks is placed on a process line, may be far more complex to migrate, since you have to determine what to do with all cases in all states somewhere on this line.

The dossier has been changed