Page History

For the DCM setup, we use several queues and exchanges. We use dead letter queues to store messages that could not be processed, because an error occurred when processing. The error should be visible in the log file. Messages on these dead letter queues will be automatically retried by the DCM Maintenance Application. If it exceeds the configured amount of retries it should be reviewed manually by a system administrator instead. There is no notification mechanism for dead letter messages, so Blueriq advises to check the dead letter queues periodically.

Its possible to configure RabbitMQ manually using the following steps:

1. Create nine exchanges where events will be published on:
   1. Create an exchange where the Case Engine and Runtime will publish DCM events to named dcmEvents. The type of this exchange should be 'fanout'.
   2. Create an exchange where the Case Engine and Runtime will publish dead letter DCM events to named dlx.dcmEvents The type of this exchange should be 'fanout'.
   3. Create an exchange where the Case Engine will publish DCM Lists events to named dcmListsEvents. The type of this exchange should be 'fanout'.
   4. Create an exchange where the Case Engine will publish DCM Maintenance events to named dcmMaintenanceEvents. The type of this exchange should be 'fanout'.
   5. Create an exchange where the Case Engine will publish scheduled events to named dcmScheduledEvents. The type of this exchange should be 'fanout'.
   6. Create an exchange where the Case Engine will publish dead letter scheduled events to named dlx.dcmScheduledEvents. The type of this exchange should be 'fanout'.
   7. Create an exchange where the Case Engine will publish task events to named dcmTasksEvents. The type of this exchange should be 'fanout'.
   8. Create an exchange where the Case Engine will publish dead letter task events to named dlx.dcmTasksEvents. The type of this exchange should be 'fanout'.
   9. Create an exchange where the Case Engine and Runtime will publish timeline events to named timelineEvents. The type of this exchange should be 'fanout'.
   10. Create an exchange where the Case Engine and Runtime will publish trace events to named traceEvents. The type of this exchange should be 'fanout'.
2. Create nine queues where events will be published on:
   1. Create a queue where the RabbitMQ will publish failed intake events to, e.g. dcmIntakeEventsQueueDlq. 
   2. Create a queue where the runtime will publish intake events on, e.g. dcmIntakeEventsQueue. Configure the exchange created in step 1a as the dead letter exchange for this queue. You can do so by setting a x-dead-letter-exchange argument with the exchange name as its value.
3. Bind the queues to their respective exchanges
   1. Open the exchange created in step 1a and add a binding to the queue created in step 2a.
   2. Open the exchange created in step 1b and add a binding to the queue created in step 2b.
   3. Open the exchange created in step 1c and add a binding to the queue created in step 2b.
4. Configure the properties to include the queues and exchanges
   1. Configure the exchange name created in step 1b in the Service call type: DCM_CaseCreate configuration and the queue name, configured in step 2b, in the Case Engine Properties configuration.
   2. Configure the exchange name created in step 1c in the Case Engine Properties configuration.