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

DCM_20_Foundation_7_1_0.package.zip

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

Change topicBackground informationRemarks
Updated the Dashboard library so it longer has any servicetypes or containertypes related to starting applications/sessions

As we want DCM2 to be failover compliant we cannot support the services and containers any more that produce nested sessions.

Please use Dashboard library v3.x (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


DCM_Tasklist container is not supported (as is it not able to be made failover compliant), that's why the DCM_Worklist is still implemented
Nested sessions in any form are not supported by the new DCM Dashboard
Only the DCM Dashboard and DCM2.0 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!