The Case-Modelling stack is based on the Process-Moddeling Blueriq models. Both strategies use a DCM Foundation as a start package, which customers can use to build their own solutions with. This sections will highlight some of the differences between the Process-Modelling Foundation and the Case-Modelling Foundation.

Services and containers

In the Case-Modelling setup, all DCM related services and containers have been changed. Most services globally work similar to the Process-Modelling ones, but act a differently in the background. Since all Process-Modelling services are being processed by the in-line process engine present in the same model and Runtime, the Case-Modelling services are being sent from the Runtime to the Case-Engine, which returns its results.

Another important difference between the services, is the fact that the Process-Modelling services use a process-id as inputs and/or outputs (confusingly called process-id or case-id), which is of type Number. The Case-Modelling services and container use a case-id as inputs and/or outputs, which is of type Text.

The Process-Modelling and Case-Modelling services can be found at the BlueriqLibraries package, you would only one or the other (both implementations cannot exist in one model, or Runtime). The new services will be explained in more detail in one of the sections below. The Case-Modelling variants have a DCM_ prefix. Some of the services are new, and others are not available anymore in the Case-Modelling setup.

Since the containers and services could differ in details, we cannot migrate them from one to another type, so you have to manually alter them in the models.

DCM_CaseCreate service migration

The CaseCreate is a new service in Case-Modelling. A case always consists of 2 aggregates (case aggregate and dossier aggregate), and a process. During the Case Creation, these elements have to be created and initialised. In the Process-Modelling Foundation, this is done by creating the elements, and updating the elements with cross references to each other. In the Case-Modelling, all elements (with their references) are stored in a case document. Therefore, the Case-Engine can start a case for you by doing everything. The DCM_CaseCreate service will send a message to the Case-Engine to start a case. When this is finished (async process), the user can find his newly added case at his overview screen. Below is the model comparison between Process-Modelling and Case-Modelling in the Foundation.

DCM_ReadCase service migration

In the Process-Modelling Foundation, cases are read by reading aggregates. The case-aggregate could be read to get to the references of the dossier aggregate and process. In the DCM_ReadCase service, all of this can be done by using a case-id. This service will return one or two aggregates and load them into the profile. Also, a process-id is never needed anymore, since all process-related services use a case-id in the Case-Modelling context.

DCM_CaseList and DCM_WorkList container migrations

In the Process-Modelling Foundation, AQ_AggregateList containers are used as caselists, After that, the case-aggregate should be loaded to get to the process-id, which could be used to filter worklists. In the Case-Modelling Foundation, only case-id's are used as inputs/outputs of the containers. This means all Caselists should be migrated to DCM_Caselist containers, and the AQ_WorkList containers should be migrated to DCM_WorkList containers. Both containers have been enhanced with extra information, which was not there before. The case-metadata and dossier-metadata (both modelled as the metadata on the aggregates) are stored to be queried in the lists containers. This means all lables (case-metadata which is global, and dossier-metadata which is case-type specific) can be used for showing and filtering data in the lists. These can be found as new field types in the columns. The case-aggregate should be in scope of the model where the list is used (so it makes sense to keep the case-data aggregate type in a shared library), and the dossier-aggregate can be used by typing the desired field (when a case-type does not have this characteristic, it will be treated as unknown).

Another advantage of the Lists, is that they are being served by the DCM-Lists-Service. Therefore, the lists are stored in the database in such a way that they can be queried more efficiently.

Task execution migration

In the Process-Modelling Foundation you had to make sure that the aggregates were read and updated at the beginning and ending of a task. In the Case-Modelling solution, the DCM_ExecuteTask service will do that for you. Making sure that in the end the case-data is consistent before some other actio on the case can be started. This means that in all tasks, the Read and Update subflows can be deleted, making it easier to see what the task is actually doing.

This also means that some maintenance flows (where aggregates are updated, but the process is somehow not) are not needed anymore, and can be simplified in the models.