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

Case-Modelling has been in beta stage in the Blueriq 15 major. At the latest minor, all Blueriq 16.0 changes have been merged back to Blueriq 15.13. From this point on Case-Modelling is out of beta and can be used.

Please make sure to upgrade to at least Blueriq 15.13 when using Case-Modelling, possibly in a production environment. Earlier minor versions are not supported.

Introduction

The DCM Dashboard Service is a service which serves definitions to display a dashboard application. Dashboard definitions contains the skeleton structure and knowledge on how to structure your dashboard pages and how to transition between them.

Modelling definitions

Currently dashboard definitions needs to be created by hand and cannot be modelled using Encore or the Studio Client. This will change in the future. 

Installation

The DCM Dashboard Service is a standalone service. The corresponding WAR file can be found in the release zip or in Artifactory: https://artifactory.blueriq.com/artifactory/libs-release/com/blueriq/blueriq-dcm-dashboard-service-application/. The WAR file needs to be deployed to a supported application server, see Installing Runtime. The application requires a config location to specify the configuration outlined below. Note that the DCM 2.0 beta installation includes the DCM Dashboard Service including configuration.

System requirements

Minimal

2 CPU cores
256 MB Heap

2 CPU cores
512 MB Heap

Configuration

In order to configure the DCM Dashboard Service, a blueriq-dcm-dashboard-service.yml file needs to be present spring.config.additional-location. Here, you can specify the location of your definitions, configure some additional settings.

Authentication

The DCM Dashboard Service only support authentication using OAuth2 OpenID Connect tokens. Without configuring authentication the Dashboard Service is unable to provide dashboard definitions as it returns a filtered definition based on what the user is authorization to see. When configuring the jwk-set-uri property make sure it is configured to the host of the Gateway Service. This is essential for the token validation. 

blueriq-dcm-dashboard-service.yml
spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: http://{host}:{port}/realms/{realm}/protocol/openid-connect/certs

JWT claims path

From version 0.1.2 onwards, you can optionally configure the path in which the username (principal) and roles are located in the JWT claims. They can be configured as a comma-separated list. By default, the username will be obtained from the sub claim, and the roles will be obtained from the roles subclaim in the realm_access claim.

blueriq-dcm-dashboard-service.yml
# in this example, the username should be obtained from the 'subject' claim, 
# and the roles should be obtained from the 'rollen' subclaim in the 'realm_access' claim
blueriq:
  jwt:
    roles-path: realm_access,rollen
    username-path: subject

Dashboard Definitions

The Dashboard Service needs to know where dashboard definitions are located on disk to serve them via the REST API it provides.

blueriq-dcm-dashboard-service.yml
blueriq:
  dcm:
    dashboard:
      definitions:
        location: ${spring.config.additional-location}dashboard-definitions/

Dashboard Definition Structure

The main purpose of the Dashboard Service is to provide dashboard definitions. Currently is it not possible to create these definitions in one of Blueriq's modelling applications, therefor we have created a guide how to create these definitions including a small example.

How to create a dashboard definition