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 Consumer | auditEvents | auditEventsQueue | Case Engine or Runtime | dlx.auditEvents | auditEventsDlq |
DCM Maintenance APP | dlx.dcmMaintenanceApp | dcmMaintenanceAppDlq | No 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.
... 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 ... 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.