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

Case-Modelling has been in beta stage in the Blueriq 15 major. At the latest minor, all Blueriq 16.0 changes have been merged back to Blueriq 15.13. From this point on Case-Modelling is out of beta and can be used.

Please make sure to upgrade to at least Blueriq 15.13 when using Case-Modelling, possibly in a production environment. Earlier minor versions are not supported.

DCM 2.0 consists of multiple components that are linked to the Blueriq Runtime. Because these components are separated from each other, they need a way to communicate with each other. To do that, aside from using HTTP protocol, the AMQP (Advanced Message Queueing Protocol) is used. This technology enables multiple components to send messages to each other via multiple so-called queues. Queues are essential for the new DCM architecture.

One of the advantages of messaging is that communication is asynchronous. This means that when a message has been sent, the producing component does not have to wait for an answer and can continue doing other tasks. The receiving component does not need to be running to be able to send a message to it. When a message has been delivered to the exchange, it will be placed in the bound queue and will be read when the receiving component is online. Also the order of receival is kept within the queue, and delivered in the same order to the receiving component.

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.

The overview on the Blueriq DCM architecture overview page shows the different components that communicate with each other using a queue.

RabbitMQ

To use the asynchronous communication with queues, we need software that manages these queues. This software is called a message broker. The message broker is where queues are defined together with the corresponding exchanges.

Blueriq supports RabbitMQ as the message broker.

The following page describes how to install RabbitMQ: Installation of RabbitMQ

The following page describes how to configure RabbitMQ: Configuring RabbitMQ


  • No labels