Blueriq DCM architecture overview

DCM Dashboard

The DCM Dashboard application is used as an entry point for DCM solutions. It is a seperate application from the Blueriq Runtime and the Blueriq Case Engine. It doesn't use our rule engine and usual way of modelling. 

The DCM Dashboard doesn't persist data besides the HTTP session data that is stored in Redis.

The DCM Dashboard (front-end) communicates with:

• With the Security gateway via REST to manage authentication and authorization (1)
  • The DCM Dashboard Service which serves definitions to display a dashboard application (2)
  • With the DCM infrastructure via REST to interact with the Runtime (3)

Runtime

The Blueriq Runtime is used for user interaction and task execution.

The Runtime manages persistent data for Comments, Timeline and Trace in a SQL database.

The Runtime communicates:

• With the Case Engine via Rest to start a task for a case (4)
• With the Case Engine via AMQP to create a case (5)
• With the Case Engine via AMQP to finish (complete/abort) a task for a case (6)
• With itself via AMQP for trace events that do not concern processes (7)
  • The runtime will put these events that cannot be processed in the trace event DLQ exchange (part of 8), to be processed by the DCM Maintenance App
• With the Security gateway via REST to manage authentication and authorization (9)

Case Engine

The Case Engine is responsible for managing cases and the processes that belong to the cases.

The Case Engine manages persistent data in a SQL database (process data), in a SQL database (scheduler data) and in a MongoDB database (case data and case locks)

The Case Engine communicates:

• With the Customer Data Service via Rest (OData) to read and insert/update aggregate data (10)
• To the DCM Lists Service via AMQP to send changes to the tasks for a case (11)
• With itself via AMQP to handle timer events asynchronously (12)
  • The Case Engine will put these events that cannot be processed in the timer event DLQ exchange (part of 8), to be processed by the DCM Maintenance App
• With the Runtime via AMQP to notify that an automatic task should be executed (6)
  • The Runtime will put these events that cannot be processed in the DCM Event DLQ exchange (part of 8), to be processed by the DCM Maintenance App
• With the Runtime (or an external system) via AMQP to send timeline and/or trace events (6)
  • The Runtime will put these events that cannot be processed in the timeline event DLQ exchange or trace event DLQ exchange (part of 8), to be processed by the DCM Maintenance App
• With the Maintenance App via AMQP to notify that a case has been unlocked (15)
  • The Maintenance App will put these events that cannot be processed in the Maintenance App DLQ exchange (part of 8), to be processed by the DCM Maintenance App

Customer Data Service

The Customer Data Service is used for storage of the Case Dossier.

The Customer Data Service manages persistent data in a SQL database.

The Customer Data Service communicates with the Case Engine via Rest (OData) to read and insert/update aggregate data (10)

DCM Lists Service

The DCM Lists Service is responsible for managing content for case lists, work lists and task lists.

The DCM Lists Service manages persistent data in a MongoDB database.

The DCM Lists Service communicates:

• From an AMQP queue to receive changes to the tasks for a case (11)
  • The DCM List Service will put these events that cannot be processed in the List event DLQ exchange (part of 8), to be processed by the DCM Maintenance App
• With the runtime to provide case/task/work list data (13)

DCM Maintenance App

The DCM Maintenance App is responsible for managing AMQP messages that could not be processed. Additionally, it provides a dashboard for functional maintainers that gives insight in the status of cases.

The DCM Maintenance App manages persistent data in a MongoDB database.

The DCM Maintenance App communicates:

• From AMQP queues that are designated as Dead Letter Queues (DLQ) (8)
  • Because AMQP does support DLQ, we user normal queues and functionally use them as Dead Letter Queues
• To the original AMQP queues of the DLQ where a message was received from (14)
• From an AMQP queue to receive messages from the Case Engine (15)
• With the Case Engine via Rest to receive case status (16)
• With the Security gateway via REST to manage authentication and authorization (17)

DCM Services Download Locations