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.

Guide Contents

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:

...

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.

...

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.

...

The dossier has been changed

The dossier is stored in aggregate format, meaning the data can only be interpreted by loading the data (user-set attributes from the database) together with a consistent model. All information will be derived again when needed in the rule-engine. When you want to change the model, it is likely you'll want to change the data that goes with the change.

...

For each situation, you have to determine what to do and if a migration is needed. For some changes (for example additions to the model), it might not be necessary to actively migrate cases.

Case Migration

When your changes have been set, you could end up with either a migration flow (actively migrating data) or an empty migration flow to just update and recalculate all data based on the same data + new model. One way of triggering a migration, is to use a message event and an automatic task. The message event triggers the migration, the automatic task processes any changes and makes sure the newly derived case state is mapped back to the process profile. Any newly created tasks will become active after the process evaluation.

...