In this release we simplified case creation.

In the previous versions, the start case event was necessary to add the id of the dossier to the profile. This is because the automatic task needs to know which dossier aggregate to retrieve. As this kind of modeling leads to unnecessary complexity and plumbing, we removed this start case event and automated task and moved it to the Case Engine. Now the Business Engineer can focus on creating business value.  

This change impacts two parts of the model:

• The process model
• The implementation model
• The DCM Maintenance App

This is explained in the Modeling changes section.

We also made some restrictions to the way we expose ID's to the model. This is explained in the ID related changes section.

Modeling changes

Process model

Instead of having a process with a create case message event, a start case message event and a required automatic task, we now only have a create case message event.

When creating a process, the following process flow was necessary:

The first message event (CreeerAanvraag) is the create case message event which is still needed. The second one (StartAanvraag) is not necessary anymore as this now happens inside the case engine. The automatic task after the second message event was necessary to map the implementation profile to the process profile and makes sure that the database was updated. This also happens internally now, resulting in the following process:

Implementation

The DCM_CaseCreate parameters have been changed. This means that there is a new Aquima Library released with those changes.

As explained earlier, we removed process nodes from the process, this results in having to know less about the model which leads to less parameters.

Before, the DCM_CaseCreate service type contained the following parameters:

After this release, it contains the following parameters:

The changes:

• We renamed CaseDataAggregate to DossierAggregate (also for type attribute and id attribute) to match the DCM 2 language.
• We renamed CaseAggregate to MetadataAggregate to match the DCM 2 language.
• The CaseStartMessageEvent has been removed.
• AggregateReference has been removed because the entity of DossierTypeAttribute and DossierIdAttribute should be the same and can be implied from those attributes.
• The CaseDataAggregate (dossier) version attribute has been removed as we now always use 'latest'.
• The ProcessMapping has been added as a parameter.

DCM Maintenance App

The 'is consistent' flag for a case was always 'true' if a case was unlocked and 'false' if a case was locked. To remove unnecessary complexity, we removed the 'is consistent' flag from the DCM Maintenance App.

ID related changes

The automated task made sure an update to the metadata aggregate was done, right after the start case event. This automated task lead to an update of the metadata aggregate which was created during the create case event. As we don't have an automated task anymore, we decided on removing the metadata aggregate ID update from the algorithm. This is done to prevent the database from saving the case and right after that updating it with its own ID. This also means that the ID of the metadata aggregate is not available in the implementation profile anymore. Later we will change the way ID's work in the Case Engine.