Versions Compared

Old Version 3

changes.mady.by.user Deny Raatgever

Saved on

compared with

New Version 4

changes.mady.by.user Deny Raatgever

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DataComponentDatasource
process and tasksCase Engineprocess-sql-store
case documentCase EngineCase Engine mongo store
metadata aggregateCustomerdata serviceaggregregate store
dossier aggregateCustomerdata serviceaggregate store
case and user tasksDCM Lists serviceDCM Lists mongo store
CommentsRuntimecomments-sql-store

Data with manual lifecycle

Other datasources will remain in the database, and should be actively maintained by a user to keep the system running smoothly. The data remains to offer the possibility to archive the data after the case has been finished.

DataComponentDatasource
process and tasks
CommentsRuntimecomments-sql-store
ReportsRuntimereports-sql-store
TimelineRuntime/ Case Engine
process
timeline-sql-store
case document
TraceRuntime/ Case Engine
Case Engine mongo
trace-sql-store
metadata aggregateCustomerdata serviceaggregregate storedossier aggregateCustomerdata serviceaggregate storecase and user tasksDCM Lists serviceDCM Lists mongo store
AuditAudit consumeraudit-sql-store
Failed messagesDCM Maintenance APPmaintenance mongo store

This data is used from the case context, but might remain relevant even when the case is finished. Therefore this data is kept in the database.

Info

Some form of maintenance has to be done at these data sources to keep the DCM system running smoothly, since they are never archived automatically.

Note

Sources like the Trace and Audit can generate much data. When used, make sure the database is configured to handle this data. It is advised to archive this data at regular intervals to keep the solution running smoothly. Consider whether you need the data in the first place, and switch the components off when they are not needed in your situation.

Outbox and Inbox data

In the DCM configuration an outbox pattern is used. The following data is being stored in the database when using DCM:

DataComponentDatasource
Process outboxCase Engineprocess-sql-store
Timeline inboxRuntime/ Case Enginetimeline-sql-store
Trace inboxRuntime/ Case Enginetrace-sql-store

The outbox mechanism prevents message events to be picked up multiple times, even when they are sent to the queue more than once. Each message is constructed and stored in the outbox. When the message is put to the queue, the message is deleted from the outbox again. So the outbox should remain almost empty when the system is running properly.

The receiving components all contain an inbox. Before they start processing the message, the message ID is checked in the inbox table. When the message is already stored, it is already processed before, so not processed again. When the message is not yet stored in the inbox, it is stored and processed. However, since the receiving component cannot know whether the message will be re-queued again from the outbox in the future (or already waiting on the queue), the message ID will be not deleted programmatically. When the system is running properly, the outbox and queue should not contain many messages at any time. However, since the components could be hosted on different databases, we cannot know from one component whether messages are completely processed.

Note

Make sure to create a maintenance process for the inbox data. Messages that are not stored in the outbox anymore, and also not present on the queue anymore, should be deleted.