Page History

...

• cases used for searching cases, for example in the DCM_CaseList container or the DCM_CaseSearch service. Contains one document for each case, with the case data (from the case-engine store), but also the process profile data, case-metadata and dossier-metadata. Each case document contains all data that could be filtered in the lists containers.
• tasks used for searching manual tasks, for example in the DCM_WorkList container. This is a subset of all tasks of the process-engine, with only tasks that are open (or started) now and could be relevant on a tasklist. Each task document contains task-specific data, and also a copy of the case-data as stated in the cases collection. This means duplicate data, but can be searched without having to join queries and other documents.

Determine which field(s) to index

Indexing the right field is can be needed to facilitate the lists/searches in the lists service most efficiently. The query will be performed in memory where possible, and only a subset of the documents are needed to read from disk to search beyond the index.

The database might use the index to filter the collection, and afterwards sort the collection. It is customary build an index with the best filteroption first (using filtering out the most results for your use), and end with the sorting attribute where possible.

Example

In the DCM Foundation there is a list for cases where the user is involved. To tune this list, we could have a look at the specific container:

Image Added

There is a filter on Case metadata - BetrokkenenReferentieIds. If we want to optimise this list, we could add an index for the field which is being queried on. For applicants, they usually only have a limited amount of cases, so this might be a good starting point for an index. The case document in the lists service for this specific Case-Type might look like this:

{
  "_id": {
    "$numberLong": "5"
  },
  "caseId": "667524bbde495a136891c493",
  "name": "ToevoegenBewijsstukken",
  "priority": 0,
  "required": false,
  "startDate": {
    "$date": "2024-06-21T06:59:07.849Z"
  },
  "caseLastUpdated": {
    "$date": "2024-06-21T06:59:07.535Z"
  },
  "status": "open",
  "customFields": {},
  "displayNames": {
    "nl-nl": "Toevoegen bewijsstukken",
    "en-gb": "Add supporting documents"
  },
  "roles": [
    "Behandelaar",
    "Aanvrager"
  ],
  "teams": [],
  "users": [],
  "unauthorizedUsers": [],
  "caseLocked": false,
  "applicationName": "studio-DCMFoundation-ZaakType_A",
  "applicationVersion": "0.0-V7_3_2",
  "attributes": {
    ...
  },
  "metadata": {
    "WorkflowStatus": "open",
    "Fase": "aanvragen",
    "Betrokkenen": [
      "aanvrager"
    ],
    "Status": "opvoeren",
    "Zaaktype": "ZaakType_A",
    "Kenmerk": "ce5c0272-ac30-48d8-a6de-4595b11a5193",
    "BetrokkenenRollen": [
      "aanvrager"
    ],
    "AanmaakMoment": {
      "$numberLong": "1718953144974"
    },
    "MigratieVersie": 1,
    "BetrokkenenReferentieIds": [
      "aanvrager"
    ]
  },
  "dossierMetadata": {},
  "caseReference": "ce5c0272-ac30-48d8-a6de-4595b11a5193",
  "_class": "com.blueriq.dcm.lists.repository.mongo.document.TaskDocument"
}

Creating indices

Based on the filter options in the model, it can help to create indices in the MongoDB. Make sure the most distinguishable field is indexed first, and the default sorting attribute is the last item in your index. When no sorting attribute is sent in the filter, the _id field is used for sorting (otherwise requesting the first 10 results might lead to different results the second time).

Example

One example is the use of a case-specific worklist. One of the key filters on this list is the Case ID. Since filtering on Case ID might already limit the amount of possible documents to just a few documents, this might be a useful index to have.

...