This project is an example of an actual Case-Type. In the most basic form there are a few phases, and a few tasks. It is created to show how the structure can work. However, in an actual context of a customer, the contents will most likely be different. The Business Engineer can use this as a starting package, and delete, update and add where it is needed.

Module structure

A module structure has been created to implement different features (or concepts) to make Dynamic Case Management possible.

The specific functions will be explained below.

Case-Dossier (ZaakA_Dossier)

Each Case-Type has a dossier. This is the data which is being gathered by the different sources. Users that perform tasks or systems that share data using automatic tasks. The dossier module is used to store the data during case-evaluation, and is retrieved at starting a task. At the moment, this is done by having an aggregate-definition to store and retrieve the data. This aggregate is retrieved and sent to any Blueriq task which is started, so the aggregate serves as a contract between the Case and the Task implementation. Having an aggregate as contract also means that the data is only consistent with the Dossier model, so this is shared between all tasks.

Case-Matadata (DomeinZaakMetadataAfleiding, Basis_ZaakMetadata)

The metadata definition is shared between Case-Types (at least when lists are needed for multiple Case-Types on one page). Therefore this module is shared from an (external) library and cannot be altered. In this Case-Type we have top derive the right values for each relevant metadata field. This is done in the DomeinZaakMetadataAfleiding module. This module has access to the Dossier and Process domain, so rules can be constructed to derive the metadata fields in the metadata module. 

Case-Process (ProcesDomeinAfleiding, ProcesDomein)

In DCM, we want the preconditions and milestone to be derivatives from the data. Therefore we need a module to access the data, and determine the values of all task preconditions and milestones. The values are needed in the process module (different module type), but this module cannot access the dossier data. To prevent sending all data to the process and derive the next state there (which would duplicate all data). There is an interaction module to do this for us. All preconditions are then sent to the process to do its magic.

The ProcesDomein module is a copy of the relevant domain in the process. The ProcesDomeinAfleiding is a module containing all rules to derive the attributes, based on the data of the ZaakA_Dossier and the Basis_ZaakMetadata modules.

Case-Webservices (ZaakA_Webservice)

Any modelled webservices can be found in this module. The Foundation has examples of creating cases, triggering migrations, set an involvement and some more. This should be a separate function, but needs to be in the entrymodule of the Case-Type. Therefore it is under the Implementation. It should be possible to access the dossier (for example to read a case in your webservice), so this explains the position in the graph.

There is an implementation module where the actual interface is maintained (ZaakA_Webservice_Interface). This can be shared with other Blueriq models implementing on the REST services at hand. To make this possible, the interface module can be moved to an internal library and shared. Datamappings are made between the interface and webservice module, they can be found in the  WebserviceMapping configuration module, along with the Baars definition.

Case-Implementation (ZaakA_Implementation)

All User-interaction is modeled in the Case Implementation module. It can access the dossier when processing (user) tasks. So Task Implementation flows can be found in this module, along with Widget flows to show Case Details to a user. The entrypoint is also used by the Case-Engine to determine the next state of the Case, so the Implementation model can (at this time) access all data, including the dossier, metadata and process data.