Page History
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.
| Table of Contents | ||
|---|---|---|
|
Before starting your change
There are a few things to consider before you start changing your Blueriq model.
...
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?
...
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.
| Info |
|---|
The user-set attributes of the process profile are stored in the database. All stored attributes must always be available in the process module in the Blueriq model. When something is missing, the process-engine cannot load the case anymore, and assumes something is wrong and throws an error. |
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.
| Info |
|---|
All process elements with the status "open" or "started" in the database should be present in the (sub) process in the model definition. Make sure it does, otherwise the process cannot continue. |
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:
- set the precondition of the element-to-delete to FALSE, so during the first migration step, all instances of this element are cancelled
- 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
Overview
Content Tools