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. Note that the DCM 2.0 beta installation includes the DCM maintenance application including configuration.

Once deployed, the application will be available on http://<hostname>:<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

Authentication is handled by a users.properties file. The setup is the same as for the Runtime: it contains users, passwords and roles. For the maintenance function (excluding the audit logs) there is one role: maintainer. 

blueriq={noop}welcome,ROLE_maintainer

Other supported roles are used for controlling access to audit logs. Please refer to: Viewing audit logs in DCM Maintenance Application for more information about that.

Example Configuration

admin={noop}admin, ROLE_development-team-member, ROLE_maintainer-interactor
admin2={bcrypt}$2a$12$EKvBV4aV0DLuPVI1mvAHle9Njinm83gE1K6cldBuXwQQvIB5C06pW,ROLE_maintainer

The application is stateless, this means that after login, a token is generated which is used for every request. A token validity can be set to increase or decrease the inactivity time before a new login is requested. The default is 30 minutes.

Since a token can be intercepted, it is recommended to run the application behind a HTTPS enabled reverse proxy. 

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:

blueriq:
  default:
    rabbitmq:
      host: rabbitmq
      port: 5672
      username: guest
      password: guest
      virtualHost: /
      ssl:
        enabled: false
  dcm:
    maintenance:
      app:
#        dlq: # can be used to override queue configuration from blueriq.default.rabbitmq setting and default queueNames
#          listener:
#            rabbitmq:
#               queueNames: 
#                - dcmEventsDlq
#				 - dcmScheduledEventsDlq
#    			 - traceDlq
#                - timelineDlq
#                - dcmMaintenanceEventsDlq
#                - auditEventsDlq
#				 - dcmTasksEventsDlq
#        case-engine:
#          listener:
#            rabbitmq:
#               queueNames: dcmMaintenanceEventsQueue
#	            errorExchange: dlx.dcmMaintenanceEvents


        mongodb:
          host: localhost
          port: 27017           
          database: failedMessages
          username: mongodb-user
          password: mongodb-password
          authentication-database: auth
        retry:
          delay: 1m
          max-retries: 3
        users:
          file: ${spring.config.additional-location}users.properties
    case-engine:
      url: http://localhost:18081/server/caseengine/maintenance
      username: caseengine-user
      password: caseengine-password
token:
  validity: 30m

Viewing audit logs

Please refer to Viewing audit logs in DCM Maintenance Application for more information on how to configure the DCM Maintenance Application for viewing audit logs.

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: 

logging:
  level:
	root: INFO
  file:
    name: </path/to/your/specific/file>