You are viewing the documentation for Blueriq 18. Documentation for other versions is available in our documentation directory.

Tags

DCM, DCM 2.0, Dynamic Case management, Case-Modelling, DCM-Dashboard

Type of accelerator

A quick start for a Dynamic case management (DCM) project

How to get

branch export (latest version)

Compatibility

Blueriq 17.10 and higher

Description

This is a starterpack for modelling a DCM application. Many concepts are already available in the package, together with a small basic Case-Type.

You can either run the model exports, or import the branch to alter yourself.

More information on the models can be found at the design guide (2. DCM-Foundation - a quick-start DCM application)

Version History

ChangesVersionCompatibility minimal Blueriq versionPackageDownloads
  • Changed all message events to work with the MessageEvent FlowType
  • Deleted the precondition entity, data is sent to the process using "Results"
  • Simplified archiving, added a task to chose archiving method when not set
  • Changed Taskwidget, case is loaded so the CaseType can be sent with the result (instead of hard-coded ZaakType_A)
  • Reference is set with timestamp instead of UUID
7.3.417.10


model exports

branch export

  • fixed process-types with archiving. New validations pointed out a small error in the structure
  • simplified document upload using the latest container changes
  • added the flowtype "automatic task" to all automatic task implementations
7.3.317.7

DCMFoundation-V7_3_3.workspace.json (branch export)

model exports

branch export

  • Created separate widget for sidepanel. Limiting the amount of CaseReads needed for one case details screen.
  • Changed the way the documents upload work. documents are the functional items needed in the case,
    files are attached to documents to match the requested documents. Documents stay in the dossier,
    while files move to the DMS eventually.
  • Documents and files are part of the dossier, and moved to the case details screen
  • Moved Baars interface to an internal library, for easy sharing to other models
  • Fixed archive aggregate type
  • Added archive timestamp to dossier and metadata
7.3.217.3

DCMFoundation-V7_3_2.workspace.json (branch export)


  • added example of using the "SearchTaskByName"
  • added example of a notification for lock status (GetCaseInfo)
7.3.117.1

DCMFoundation-V7_3_1.workspace.json (branch export)


  • Dashboard model is added
  • changed pattern for processing incoming message events using the GetCaseInfo service
  • introduced the "reference" as standard field in the lists
  • CaseTypes field uses valuelist for display purposes (possibly different languages)
  • Task Names are used as display name on top of the widget
  • Audit model references deleted since they are no longer needed
  • Added a 2-man-rule example (Beoordeling Controleren)
  • cases that need a specific type of involvement can be derived and shown in a caselist
7.3.016.8

download

dashboard model is included in the branch export

download branch export


  • Updated to latest Blueriq Libraries, including addition of DCM_CaseSearch service
  • Fixed searching cases by reference
  • Added roles at all API's in the model
  • Minor changes in page information
7.2.116.4download
  • Updated to work with new BlueriqLibraries
7.2.016.0download

Fundamental changes (in comparison to v4.9.x):

Change topicBackground informationRemarks
Default Blueriq library changes

As we want Case modelling to be failover compliant we cannot support the services and containers any more that produce nested sessions. These services and containers were mainly incorporated in the former Dashboard Library in Blueriq 15. This library is no longer needed and all supported services and containers can now be found in the new Blueriq Case Modelling Library

Please use Case Modelling library v1.0.0 (and up)

Introduced the new DCM Widget flow for communication with the dashboard for specific actions: start new case, open case, start task from case.

When you select this flow type you will a number of options be set or become available (highlighted in the screenshots below):

  1. The purple highlight: all DCM Widgets flows are by default set to exposed. This means they are the entry points of your Blueriq implementation models. Also you should not set this flow type for any other nested or non-DCM-Dashboard flow.
  2. The blue highlight: for each entry point of the DCM Widget flow you can set request parameters in a specific tab of the property panel of the flow. In the first version of the DCM Dashboard these request parameters were handled by the AQ_RequestParameter service. Now we have made it a default feature of the flow type so your flow definition is not poluted with boiler plate defitions.
  3. The green highlight: the DCM Widget flow has its own exit events. These events will communicate to the DCM Dashboard application. There are three specific events for all actions available in the DCM Dashboard. Each event requires its own parameters to be set, which then of course are linked to the entry point parameters. In the first version these exit events were managed with a service call that had to be modeled in the flow. Just like we did with the entry point we now made the exit events into native concepts to eliminate the need for boiler plate modelling.

Please use DCM library v2.0.2 (and up)
Project structure Main_Dashboard

Deleted the External flow contract and related mapping 

The "Home"-page with the different widgets modeled on it as containers is no longer needed.

Instead, the containers now have there own implemented DCM widget flows:

Project structure ZaakType_A

Deleted:

  • the External flow contract and related mapping
  • the Zaak_Dashboard modules and related mappings
  • the Execute task module

Moved:

  • Contents of the case intake (ZaakIntake) module has been moved into the Implementation module
  • The ZaakA_Intake module itself has then been removed

Task execution is now completely handled in the background and is not necessary for the Business Engineer to model any more.

The ZaakA_Implementatie has been made the Root module (and thus entry point) for the project.

Removed all external flows

This decoupling method is not necessary in the default DCM Foundation.

We do see use cases for the external flows within DCM, but at the moment they are NOT supported yet


Created new DCM Widget flows with pages for the different widgets for Tasks, Notes, Documents, etc.

The new DCM Dashboard application start DCM Widget flows from a regular Blueriq project. 

Each widget on a dashboard page can be modeled in a single DCM Widget flow


Nested sessions in any form are not supported by the new DCM Dashboard
Only the DCM Dashboard and Case Modelling are designed and able to run in a failover architecture
Authorisation and authentication is handled with Oauth through OpenID connect (which is mandatory) using Keycloak



  • No labels

Didn't find the answer you were looking for? Try the advanced search!