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". 

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.

* 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. 

...
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:

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):

...
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:

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:

blueriq.trace.event.publisher.channel.amqp.rabbitmq.exchangeName=traceEvents
...

If the Timeline publisher is enabled add the following to the Case Engine 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:

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:

blueriq.dcm.rabbitmq.exchangeName=dcmEvents
...
blueriq.dcm.rabbitmq.queueNames=dcmTasksEventsQueue
...

If the Trace publisher is enabled add the the following to the Runtime 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:

blueriq.trace.event.listener.amqp.rabbitmq.queueNames=traceQueue
...

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

blueriq.timeline.event.publisher.amqp.rabbitmq.exchangeName=timelineEvents
...

If the Timeline SQL Store is enabled add the following to the Runtime 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:
      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:   
        dlq:
          listener:
            rabbitmq:
              queueNames:                  
				- dcmEventsDlq
                - dcmTasksEventsDlq
                - dcmScheduledEventsDlq
                - traceDlq
                - timelineDlq
                - dcmMaintenanceEventsDlq
                - auditEventsDlq
				- dcmListsServiceEventsDlq
                ...

        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.