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

Installing the DCM Maintenance Application

The DCM Maintenance Application is a standalone application. The corresponding WAR file can be found in the release zip. 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.  Furthermore, you need to have the Blueriq Gateway Service deployed with the right configuration. The gateway service is used as authentication mechanism. The needed configuration for the gateway service can be found below. Note that the Blueriq DCM Development Installation includes the DCM maintenance application including configuration.

Once deployed, the application will be available on http://<gateway_hostname>:<gateway_port>/dcm-maintenance.


Configuring the DCM Maintenance Application

RabbitMQ

The DCM Maintenance Application uses the same RabbitMQ (AMQP) instance that is used for the DCM 2.0 setup to be able to receive and retry failed messages. This AMQP instance should be set up in such a way that messages end up on a dead letter queue if processing the message fails. In addition to listening for messages on dead letter queues, the DCM Maintenance Application also listens to other messages from the Case Engine using a separate listener. For more information about installing and configuring RabbitMQ, please refer to: DCM queueing

MongoDB

The application requires MongoDB for persistent storage. Please refer to: Document database MongoDB for information about the installation and configuration of MongoDB

Authentication & Authorization

See  Blueriq Gateway and OAuth2 configuration for information about Authentication & Authorization

Case Engine

To be able to display the information about process cases, the maintenance application needs to connect to the Case Engine's Maintenance Rest API. The Case Engine also publishes an event to RabbitMQ if a case has been unlocked to be able to retry messages that failed due to the case being locked. 

Example configuration

To configure the options listed above, the DCM Maintenance application requires a blueriq-dcm-maintenance-app.yml file in the spring.config.additional-location you configured for it:

Example blueriq-dcm-maintenance-app.yml
blueriq:
  default:
    rabbitmq:
      host: <rabbitmq_host>
      port: <rabbitmq_port>
      username: guest
      password: guest
      virtualHost: /
      ssl:
        enabled: false
  dcm:
    maintenance:
      app:
        mongodb:
          host: <mongodb_host>
          port: <mongodb_port>
          database: failedMessages
          username: mongodb-user
          password: mongodb-password
          authentication-database: auth
        dlq:
          retry:
            delay: 1m
            max-retries: 3
    case-engine:
      url: http://<caseEngine_host>:<caseEngine_port>/server/caseengine/maintenance
      username: caseengine-user
      password: caseengine-password
spring:
  security:
    oauth2:
      resource-server:
        jwt:
          jwk-set-uri: http://<gateway_host>:<gateway-port>/realms/dcm-maintenance-app/protocol/openid-connect/certs

Queuing

The DCM-Maintenance relies on queues to work, it will listen to dead-letter-queues for messages to be corrected, and it listens to Case-State events. When nothing is configured, it uses a set of default queues, suitable in most situations. When you want to override the defaults, that can be done by the following configuration:

Example blueriq-dcm-maintenance-app.yml
blueriq:
  dcm:
    maintenance:
      app:
        dlq:
          rabbitmq:
             queueNames: 
               - dcmEventsDlq
		       - dcmScheduledEventsDlq
    		   - traceDlq
               - timelineDlq
               - dcmMaintenanceEventsDlq
               - auditEventsDlq
			   - dcmTasksEventsDlq
			   - dcmListsServiceEventsQueueDlq
        case-engine:
          rabbitmq:
            queueNames: dcmMaintenanceEventsQueue
	        errorExchange: dlx.dcmMaintenanceEvents

Logging

By default the DCM Maintenance App produces a lot of DEBUG logging. If this is not required, the logging level can be set to a higher level (e.g. INFO). Also, a file can be specified to log to.

Add the following configuration to blueriq-dcm-maintenance-app.yml: 

Example blueriq-dcm-maintenance-app.yml
logging:
  level:
	root: INFO
  file:
    name: </path/to/your/specific/file>

Root-Context

By default the DCM Maintenance App is available  on http://<gateway_hostname>:<gateway_port>/dcm-maintenance. From version 3.0.2 it is possible to change the root-context of the app. This can be useful when you want to run multiple instances of the same app on the same server but different endpoints.

To do this add the following to the blueriq-dcm-maintenance-app.yml:

Example blueriq-dcm-maintenance-app.yml
server:
  servlet:
    context-path: /<your-desired-name>

This will make the DCM Maintenance app available on http://<hostname>:<port>/<your-desired-name> instead of the default URL.