You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

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.

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


  • No labels