When running a DCM application, many different sources of data are kept track of. Most of them have a lifecycle similar to the case itself. They will be deleted when the Case is finished. Some sources remain when the Case is finished, leaving it for the maintainers of the application to decide what to do with the information.
Data during case execution
Below is a table containing different types of data with the lifespan of the case itself. When case if finished (process has finished its last node), this data will be deleted.
| Data | Component | Datasource |
|---|---|---|
| process and tasks | Case Engine | process-sql-store |
| case document | Case Engine | Case Engine mongo store |
| metadata aggregate | Customerdata service | aggregregate store |
| dossier aggregate | Customerdata service | aggregate store |
| case and user tasks | DCM Lists service | DCM Lists mongo 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.
| Data | Component | Datasource |
|---|---|---|
| Comments | Runtime | comments-sql-store |
| Reports | Runtime | reports-sql-store |
| Timeline | Runtime/ Case Engine | timeline-sql-store |
| Trace | Runtime/ Case Engine | trace-sql-store |
| Audit | Audit consumer | audit-sql-store |
| Failed messages | DCM Maintenance APP | maintenance mongo store |
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.
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:
| Data | Component | Datasource |
|---|---|---|
| Process outbox | Case Engine | process-sql-store |
| Timeline inbox | Runtime/ Case Engine | timeline-sql-store |
| Trace inbox | Runtime/ Case Engine | trace-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.
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.
Overview
Content Tools