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

Automatic configuration

After RabbitMQ has been installed, we can configure the queues, exchanges and the bindings between the exchanges and queues. A default configuration is available (definitions.json). This is a JSON file which contains all queues, exchanges and bindings necessary for the DCM setup. It can be imported in the RabbitMQ dashboard in the "Overview" tab, under "Import definitions". 

The following steps will overwrite any existing configuration. So make sure any other relevant configuration is backed up before trying the automatic configuration step.


After importing the file it might be necessary to reconfigure the users, to add a new user so you can remove the guest user. please see: https://www.rabbitmq.com/access-control.html

Manual configuration

Its possible to configure RabbitMQ manually using the following steps:

  • The exchanges should be created with type "fanout", all other properties can be left on their default value.
  • All queues should be created with the default values.
  • For each exchange, create a binding to the corresponding queue on the right.
  • For each dead letter exchange, create a binding to the corresponding dead letter queue on the right.

All names below can be changed if needed however, the 'dlx.' prefix for dead letter exchanges is mandatory and the dead letter exchange name should be the same as its corresponding exchange.

Producing Component(s)

Exchange

Queue

Consuming

Component(s)

Dead letter exchange

Dead letter queue

Case Engine, Runtime

dcmEvents

dcmEventsQueue

Case Engine

dlx.dcmEvents

dcmEventsDlq

Case Engine

dcmListsEvents

dcmListsServiceEventsQueue

DCM Lists Service

dlx.dcmListsEvents

dcmListsServiceEventsDlq

Case Engine

dcmMaintenanceEvents

dcmMaintenanceEventsQueue

DCM Maintenance App

dlx.dcmMaintenanceEvents

dcmMaintenanceEventsDlq

Case Engine

dcmScheduledEvents*

dcmEventsQueue

Case Engine

dlx.dcmScheduledEvents

dcmScheduledEventsDlq

Case Engine

dcmTasksEvents

dcmTasksEventsQueue

Runtime

dlx.dcmTasksEvents

dcmTasksEventsDlq

Case Engine, Runtime

timelineEvents

timelineQueue

Case Engine OR Runtime

 dlx.timelineEvents

timelineDlq

Case Engine, Runtime

traceEvents

traceQueue

Case Engine OR Runtime

 dlx.traceEvents

traceDlq

Audit ConsumerauditEventsauditEventsQueueCase Engine or Runtimedlx.auditEventsauditEventsDlq
DCM Maintenance APPdlx.dcmMaintenanceAppdcmMaintenanceAppDlqNo Consumer
--

* This exchange publishes to the same queue as the dcmEvents exchange.

Application properties

For each component that uses RabbitMQ, one or more queues/exchanges need be configured including the properties of the RabbitMQ instance.

Each component needs to know where the RabbitMQ instance is hosted, which port it is using, what the user credentials, which virtual host is needed and of course what the exchange and/or queue names are.

Dcm needs to know the values of these properties. This can be achieved two ways.

Per DCM component you can declare the common properties: host, port, username, password, virtualhost and ssl just once and all listeners and publishers will use the same properties. 

application.properties
...
blueriq.default.rabbitmq.host=localhost
blueriq.default.rabbitmq.port=30010
blueriq.default.rabbitmq.username=guest
blueriq.default.rabbitmq.password=guest
blueriq.default.rabbitmq.virtualHost=/
blueriq.default.rabbitmq.ssl.enabled=false
# From blueriq version 16.9 it is possible to declare multiple hosts (RabbitMQ Cluster)
blueriq.default.rabbitmq.addresses=localhost:30012,otherhost:25102

You can also do this for a multi-tenant setup with the following properties:

application.properties
blueriq.multitenancy.default.rabbitmq.tenants.google.host=localhost
blueriq.multitenancy.default.rabbitmq.tenants.google.port=5672
blueriq.multitenancy.default.rabbitmq.tenants.google.username=google
blueriq.multitenancy.default.rabbitmq.tenants.google.password=welcome
blueriq.multitenancy.default.rabbitmq.tenants.google.virtualHost=google
blueriq.multitenancy.default.rabbitmq.tenants.google.ssl.enabled=true

blueriq.multitenancy.default.rabbitmq.tenants.apple.host=localhost
blueriq.multitenancy.default.rabbitmq.tenants.apple.port=5672
blueriq.multitenancy.default.rabbitmq.tenants.apple.username=apple
blueriq.multitenancy.default.rabbitmq.tenants.apple.password=welcome
blueriq.multitenancy.default.rabbitmq.tenants.apple.virtualHost=DefaultEverest
blueriq.multitenancy.default.rabbitmq.tenants.apple.ssl.enabled=true
# From blueriq version 16.9 it is possible to declare multiple hosts (RabbitMQ Cluster)
blueriq.multitenancy.default.rabbitmq.tenants.apple.addresses=localhost:30012,otherhost:25102


Add these properties to the application.properties file of the component (i.e. Runtime, Case Engine etc.) to override common RabbitMQ properties for each queue/exchange. The queue and exchange names of the definitions.json file will still be used. Or for .yml (for example the Maintenance App or the DCM Lists Service):

application.yml
...
blueriq:
	default:
		rabbitmq:
			host: localhost
			port: 30010
			username: guest
			password: guest
			virtualHost: /
			ssl:
				enabled: false
			# From blueriq version 16.9 it is possible to declare multiple hosts (RabbitMQ Cluster) 
			addresses: localhost:30012,otherhost:25102

If desired, it is possible to configure other exchanges/queues in each component individually. To do that, the following properties can be used.

Note that not all properties have been described. The host, port, virtualHost, username, password etc. are omitted for brevity and replaced by "..." in the configuration below. Examples of the property files can be viewed at the page of its corresponding component.  

if the property ssl.enabled is not set at all it will default to false regardless.

Case Engine

Add the following exchanges and queues to the Case Engine properties when you want to override queues and exchanges with your own:

application-case-engine.properties
blueriq.case.engine.maintenance.rabbitmq.exchangeName=dcmMaintenanceEvents
...
blueriq.case.engine.rabbitmq.queueNames=dcmEventsQueue
...
blueriq.case.engine.rabbitmq.exchangeName=dcmEvents
...
blueriq.case.engine.scheduler.rabbitmq.exchangeName=dcmScheduledEvents
...
blueriq.process.engine.v2.automatic-task.rabbitmq.exchangeName=dcmTasksEvents
...

If the Trace publisher is enabled add the the following to the Case Engine properties:

application-trace-event-publisher.properties
blueriq.trace.event.publisher.channel.amqp.rabbitmq.exchangeName=traceEvents
...

If the Timeline publisher is enabled add the following to the Case Engine properties:

application-timeline-event-publisher-amqp.properties
blueriq.timeline.event.publisher.amqp.rabbitmq.exchangeName=timelineEvents
...

For the Case Engine to communicate to the DCM Lists Service add the following to the Case Engine properties:

application-dcm-lists-publisher.properties
blueriq.dcm.lists-publisher.rabbitmq.exchangeName=dcmListsEvents
...

Runtime

Add the following exchanges and queues to the Runtime properties when you want to override queues and exchanges with your owns:

application-case-engine-client.properties
blueriq.dcm.rabbitmq.exchangeName=dcmEvents
...
blueriq.dcm.rabbitmq.queueNames=dcmTasksEventsQueue
...

If the Trace publisher is enabled add the the following to the Runtime properties:

application-trace-event-publisher-amqp.properties
blueriq.trace.event.publisher.channel.amqp.rabbitmq.exchangeName=traceEvents
...

If the Trace SQL Store is enabled add the the following to the Runtime properties:

application-trace-sql-store.properties
blueriq.trace.event.listener.amqp.rabbitmq.queueNames=traceQueue
...

If the Timeline publisher is enabled add the following to the Runtime properties:

application-timeline-event-publisher-amqp.properties
blueriq.timeline.event.publisher.amqp.rabbitmq.exchangeName=timelineEvents
...

If the Timeline SQL Store is enabled add the following to the Runtime properties:

application-timeline-sql-store.properties
blueriq.timeline.event.listener.amqp.rabbitmq.queueNames=timelineQueue
...

DCM Lists Service

Add the following queue to the DCM Lists Service properties  when you want to override queues and exchanges with your own:

blueriq-dcm-lists.yml
blueriq:
  dcm:
    lists:
      event:
        consumer:
          rabbitmq:
            queueNames: dcmListsServiceEventsQueue
			...

DCM Maintenance App

Add the following to the DCM Maintenance App properties  when you want to override queues and exchanges with your own:

blueriq-dcm-maintenance-app.yml
blueriq:
  dcm:
    maintenance:
      app:   
        dlq:
          listener:
            rabbitmq:
              queueNames:                  
				- dcmEventsDlq
                - dcmTasksEventsDlq
                - dcmScheduledEventsDlq
                - traceDlq
                - timelineDlq
                - dcmMaintenanceEventsDlq
                - auditEventsDlq
				- dcmListsServiceEventsDlq
                ...
            errorExchange: dlx.dcmMaintenanceApp

        case-engine:
          listener:
            rabbitmq:
              queueNames: 
                - dcmMaintenanceEventsQueue
              errorExchange: dlx.dcmMaintenanceEvents
      		  ...

Concurrent consumers

For the trace-sql-store, timeline-sql-store, case-engine-client components as well as the Case Engine, it's possible to set a number of concurrent consumers.

We have implemented the concurrentConsumers  and maxConcurrentConsumers properties, which will affect the concurrent consuming of messages from the queue. More on these properties can be found here: Listener concurrency.

The property page of each component will show the properties to use. Please note the considerations on the following page: Deployment considerations DCM.