Persistencia

Bases de datos soportadas

Actualmente, ipf-ods solo admite MongoDB, pero también puede funcionar con Azure Cosmos DB ya que implementa MongoDB protocolo de conexión.

MongoDB

ipf.mongodb.url = "mongodb://mongo:27017/ipf"

CosmosDB

ipf.mongodb.url = "<<cosmos-db-url>>"

//You may need this
spring.data.mongodb.database = "ipf"

//Or even the full url
spring.data.mongodb.uri = "<<cosmos-db-url>>"

Ejemplo de URL de Cosmos DB

mongodb://ipfcosmosdbdemo:vooQt7iRpI0WyUVC5IIKbq7RT058xJCKdtnjdbOhFnQK2QDLiaWeCrN2TDIEzeBLwLFTEHT47iSSKUowEtrmWw==@ipfcosmosdbdemo.mongo.cosmos.azure.com:10255/ipf?ssl=true&replicaSet=globaldb&retrywrites=false&maxIdleTimeMS=120000&appName=@ipfcosmosdbdemo@

Ejecutando pruebas e2e locales contra Azure Cosmos DB

Al ejecutar pruebas e2e, establezca spring.data.mongodb.uri en local-e2e-test application.properties.

Colecciones

Nombre Descripción

payments

Contiene objetos de pago ISO 20022.

pds

Contiene IPF definido y específico para el cliente,PDS tipos

processes

Datos relacionados con el procesamiento de un pago. Estos documentos tienen un objectType para indicar el tipo de procesamiento de datos, como MESSAGE_LOG,SYSTEM_EVENT,PROCESS_FLOW_EVENT etc.

customObjects

Datos específicos del cliente relacionados con un pago.

summaries

Tipo de alto nivel que representa un pago, construido a partir de los datos en las otras colecciones.

unitOfWorks

Meta-datos para un dado unitOfWorkId, construido a partir de eventos de flujo de proceso ingeridos.

purgeReports

Una entrada diaria documentando los detalles de la ejecución de una purga. Creada durante ODS-Purging

expiryReports

Una entrada diaria documentando el número de unitOfWorks que debe expirar en n días.

archiverCandidateSelectionState

Rastrea el estado de selección de candidatos para el archivo. Creado durante Selección de Candidatos

Esquema Versioning

Documentos dentro de ODS las colecciones contienen un numérico schemaVersion campo que indica la versión del esquema en el momento en que se persistió el documento, por ejemplo.{schemaVersion: 1}. Cuando se añaden o eliminan nuevos campos de un tipo, se incrementa el número de versión.

El siguiente es un ejemplo simplificado de un documento versionado.

{
  "schemaVersion": 1,
  "_id": {
    "$oid": "675f0c96f58c972c1d30bac2"
  },
  "createdAt": {
    "$date": "2025-11-16T09:15:00Z"
  },
  "field": "value",
}

Cuando un campo newField se añade, la versión del esquema se incrementa

{
  "schemaVersion": 2,
  "_id": {
    "$oid": "675f0c96f58c972c1d30bac2"
  },
  "createdAt": {
    "$date": "2025-11-16T09:15:00Z"
  },
  "field": "value",
  "newField": "some value"
}
No todos los documentos contendrán un schemaVersion campo, y se asume que la versión es 1 en estos casos, excepto por PDS que tiene tres versiones conceptuales antes de que se introdujera la versionado de esquemas. ODS detectará la versión correcta del esquema pds de un documento no versionado al leer.
El versionado de esquemas se aplica a la colección en su totalidad y al processes La colección contiene documentos que representan objetos de diferentes tipos. El número de versión se incrementará para todos los tipos cuando se añada un campo a solo uno de esos tipos. Esto resulta en que algunos tipos tengan múltiples números de versión sin cambiar dentro de esas versiones.

Las versiones del esquema están alineadas con las versiones de IPF, no con cada cambio distinto, lo que significa que puede haber múltiples cambios dentro de un solo número de versión incrementado. Si la versión del esquema es 1 en la versión de IPF 2025.4, y se añaden o eliminan campos para estar en la versión de IPF 2026.1, la versión del esquema para esa versión de IPF será 2. En la siguiente versión 2026.2, puede haber más cambios, y la versión del esquema será 3.

Cambios en el esquema

Hay algunas reglas que seguiremos.

Regla 1: Compatibilidad hacia atrásODS podrá leer documentos de todas las versiones de esquema anteriores.

Al leer documentos,ODS transformará documentos de una versión de esquema anterior a la última versión que conoce.

Si ODS lee una versión mayor que su versión actual, por ejemplo, durante una actualización continua donde una instancia más nueva de ODS ha escrito datos en V2, pero existente ODS las instancias aún están utilizando V1, se asume que los cambios de V2 no son disruptivos.

Regla 2: Compatibilidad hacia adelante Si ODS Cuando v1 del esquema lee un documento v2, puede asumir con seguridad que el documento es compatible con v1.

Teniendo en cuenta estas reglas, para cualquier aumento de versión de esquema dado, solo son posibles dos tipos de cambio: agregar campos y eliminar campos.

Agregar nuevos campos es generalmente un cambio seguro de realizar de una versión a otra, pero los documentos más antiguos no tendrán el campo, por lo que debe ser opcional en la nueva versión, o se debe asignar un valor predeterminado.

La eliminación de campos es posible si la versión anterior no tiene un requisito estricto sobre el campo, es decir, si el campo es opcional o no se utiliza en v1, puede ser eliminado de manera segura en v2.

Dada la aproximación anterior, usted podría estar preguntándose cómo podríamos llevar a cabo cambios más complejos, como renombrar un campo o cambiar su tipo.

Renombrar Campos y Cambiar Tipos

Estos cambios son de múltiples pasos y deben ocurrir en dos o más versiones de IPF.

Ejemplo: En el esquema v1, el campo fieldA tiene un tipo de String.

Renombrando a fieldB en v2 requiere primero introducir fieldB como un duplicado de fieldA, completando ambos campos. Luego en v3,fieldA puede ser eliminado.

Cambiar el tipo de campo sigue el mismo proceso. En v2 fieldB se introduce con su nuevo tipo. Ambos fieldA y fieldB se escribirá bajo el esquema v2. En v3,fieldA puede ser eliminado.

Indexación

Por defecto, las aplicaciones de ingestión e indagación intentarán crear todos los índices requeridos al iniciar. Para deshabilitar este comportamiento y crear los índices manualmente, proporcione la siguiente configuración:

ods.persistence.indexing.enabled = false

Aunque los protocolos de red son los mismos, las implementaciones del motor de base de datos subyacente difieren para MongoDB y CosmosDB bases de datos, lo que afecta las opciones de indexación. ODS las aplicaciones, por lo tanto, estarán creando un conjunto diferente de índices dependiendo de a qué base de datos se estén refiriendo, con MongoDB el modo de creación de índices siendo el predeterminado. Para cambiar el modo a CosmosDB, proporcione la siguiente configuración:

ods.persistence.indexing.mode = cosmosdb

Indexes declared by the ODS Ingestion App

Indexes declared in MongoDB mode

Tabla 1. Indexes for purgeReports collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "executionDate"
        }
    ],
    "options" : {
        "unique" : true
    }
}

A single report exists per day, and is retrieved by the executionDate
Tabla 2. Indexes for processes collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Used in upserts in order to de-duplicate process objects as they’re ingested.
Tabla 3. Indexes for summaries collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Summaries are uniquely identified by unitOfWorkIds.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "lastUpdated"
        }
    ]
}

Updated each time a summary changes.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "enrichmentSignal"
        }
    ],
    "options" : {
        "sparse" : true
    }
}

Set and updated for Batch Summaries AND Payment Summaries that contain a relatedUnitOfWorkId Used for Payment Summary enrichment of identification fields from the related Batch Summary High selectivity as this is set as a UUID
Tabla 4. Indexes for payments collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "paymentObjectId"
        },
        {
            "direction" : "ASC",
            "key" : "processObjectReference"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Used in upserts in order to de-duplicate MDS objects as they’re ingested.
Tabla 5. Indexes for customObjects collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Used in upserts in order to de-duplicate custom objects as they’re ingested.
Tabla 6. Indexes for pds collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

PDS objects are retrieved by unitOfWorkId directly

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "name"
        },
        {
            "direction" : "ASC",
            "key" : "sequenceNumber"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Each PDS object version is stored as a single document, where sequenceNumber identifies its version.
Tabla 7. Indexes for unitOfWorks collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ],
    "options" : {
        "unique" : true
    }
}

UnitOfWorks are uniquely identified by unitOfWorkIds. Used in upserts in order to de-duplicate UnitOfWork objects as they’re ingested.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "startedAt"
        }
    ]
}

UnitOfWorks startedAt is used to determine candidates for purging.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "finishedAt"
        }
    ]
}

UnitOfWorks are eligible and retrieved for archiving by the finishedAt field. UnitOfWorks finishedAt is used to determine candidates for purging.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "archivedAt"
        }
    ]
}

UnitOfWorks archivedAt is used to determine candidates for purging.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "journeyType"
        }
    ]
}

Archiving can be configured to only delete unit of works with a defined journey type

Indexes declared in CosmosDB mode

Tabla 8. Indexes for purgeReports collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "executionDate"
        }
    ],
    "options" : {
        "unique" : true
    }
}

A single report exists per day, and is retrieved by the executionDate
Tabla 9. Indexes for processes collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Used in upserts in order to de-duplicate process objects as they’re ingested.
Tabla 10. Indexes for expiryReports collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "expiryDate"
        }
    ],
    "options" : {
        "unique" : true
    }
}

A single report exists per day, and is retrieved by the expiryDate
Tabla 11. Indexes for summaries collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Summaries are uniquely identified by unitOfWorkIds.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "lastUpdated"
        }
    ]
}

Updated each time a summary changes, and used to determine candidates for purging

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "enrichmentSignal"
        }
    ],
    "options" : {
        "sparse" : true
    }
}

Set and updated for Batch Summaries AND Payment Summaries that contain a relatedUnitOfWorkId Used for Payment Summary enrichment of identification fields from the related Batch Summary High selectivity as this is set as a UUID
Tabla 12. Indexes for payments collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "paymentObjectId"
        },
        {
            "direction" : "ASC",
            "key" : "processObjectReference"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Used in upserts in order to de-duplicate MDS objects as they’re ingested.
Tabla 13. Indexes for customObjects collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Used in upserts in order to de-duplicate custom objects as they’re ingested.
Tabla 14. Indexes for pds collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

PDS objects are retrieved by unitOfWorkId directly

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        },
        {
            "direction" : "ASC",
            "key" : "name"
        },
        {
            "direction" : "ASC",
            "key" : "sequenceNumber"
        }
    ],
    "options" : {
        "unique" : true
    }
}

Each PDS object version is stored as a single document, where sequenceNumber identifies its version.
Tabla 15. Indexes for unitOfWorks collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ],
    "options" : {
        "unique" : true
    }
}

UnitOfWorks are uniquely identified by unitOfWorkIds. Used in upserts in order to de-duplicate UnitOfWork objects as they’re ingested.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "startedAt"
        }
    ]
}

UnitOfWorks startedAt is used to determine candidates for purging.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "finishedAt"
        }
    ]
}

UnitOfWorks are eligible and retrieved for archiving by the finishedAt field. UnitOfWorks finishedAt is used to determine candidates for purging.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "archivedAt"
        }
    ]
}

UnitOfWorks archivedAt is used to determine candidates for purging.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "journeyType"
        }
    ]
}

Archiving can be configured to only delete unit of works with a defined journey type

Indexes declared by the ODS Inquiry App

Indexes declared in MongoDB mode

Tabla 16. Indexes for customObjects collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "associationId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "createdAt"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.
Tabla 17. Indexes for processes collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ]
}

Unique per unitOfWorkId and possibly also unique globally so offers high selectivity. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

High selectivity - depending on the implementation, should identify double to triple digit objects. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "primaryAssociation"
        }
    ]
}

High selectivity, similar to unitOfWorkId - will usually hold either a unitOfWorkId or a flow ID. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Likely unique and therefore highly selective, in most cases we would expect only a few objects for a given value. There will, however, be many process objects with the value 'UNKNOWN' which can give low selectivity if this is used as a search value. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "DESC",
            "key" : "createdAt"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "objectType"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.
Tabla 18. Indexes for pds collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "pdsObjectId"
        }
    ]
}

Unique per unit of work only, e.g., there will be 1+ pds objects with the same pdsObjectId per unitOfWorkId

 
{
    "keys-spec" : [
        {
            "direction" : "DESC",
            "key" : "sequenceNumber"
        }
    ]
}

Latest PDS object search does a descending sort on sequenceNumber
Tabla 19. Indexes for summaries collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "journeyType"
        },
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Has low selectivity, we can expect a large number of summaries with the same value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value. May eventually be removed since the clientRequestId is also present in the alternativeIds.value index

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "relatedUnitOfWorkId"
        }
    ]
}

Links a summary, to the parent/related summary. Many summaries could link to the same "parent" summary, e.g. many batches link to a single bulk, or many payments link to a single batch which means a summary can have [0..1] parents, and [0..n] children.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "alternativeIds.value"
        }
    ]
}

Values should be highly selective, if there’s any duplication, results should be small enough to be sorted in-memory

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "startedAt.value"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.uetr"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "chargeAmount.value"
        }
    ]
}

chargeAmount will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "chargeAmountCurrency.value"
        }
    ]
}

chargeAmountCurrency has low selectivity, we can expect a large number of summaries with the same currency

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructionId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.originalInstructionId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.transactionId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.originalTransactionId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.messageId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.cancellationId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.originalMessageId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.originalEndToEndId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a given value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debtorAccount"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will usually have a high selectivity (small number of payments for a single account for example) but in some cases (bulk) accounts may have a very large number of outgoing payments and therefore selectivity will be lower

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debtorAgentBIC"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Would likely have low selectivity, for example many outgoing payments will have the same bic value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debtorName"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Probably highly selective, but in some cases it may have low selectivity (bulk?)

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditorAccount"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will usually have a high selectivity (small number of payments for a single account for example) but in some cases (bulk) accounts may have a very large number of outgoing payments and therefore selectivity will be lower

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditorAgentBIC"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Would likely have low selectivity, for example many incoming payments will have the same bic value

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditorName"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Probably highly selective, but in some cases it may have low selectivity (bulk?)

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructingParty"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For outbound recalls, this represents the client bank, for inbound recalls, this represents the other bank Selectivity is probably on the low-end

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructedParty"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For outbound recalls, this represents the other bank, for inbound recalls, this represents the client bank Selectivity is probably on the low-end

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructingAgent"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Selectivity is probably on the low-end

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructedAgent"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Selectivity is probably on the low-end

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.initiatingPartyName"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Selectivity is probably on the low-end

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditAccount"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will usually have a high selectivity (small number of payments for a single account for example) but in some cases (bulk) accounts may have a very large number of outgoing payments and therefore selectivity will be lower

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debitAccount"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will usually have a high selectivity (small number of payments for a single account for example) but in some cases (bulk) accounts may have a very large number of outgoing payments and therefore selectivity will be lower

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.acceptanceDateTime"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.interbankSettlementDate"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.originalInterbankSettlementDate"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.csm"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Selectivity of a single field index for csm would probably be on the low-end
Tabla 20. Indexes for payments collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "paymentObjectId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "parentPaymentObjectId"
        }
    ]
}

For instant payments, likely to be highly selective, we would expect only a few documents for a given value. For bulk payments there could be tens of thousands of documents for some values..

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "primaryAssociation"
        }
    ]
}

For instant payments, likely to be highly selective, we would expect only a few documents for a given value. For bulk payments there could be tens of thousands of documents for some values..

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "createdAt"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.messageId"
        }
    ]
}

For instant payments, likely unique and therefore highly selective, we would expect only a single document for any given value. For bulk payments there could be tens of thousands of documents for a single instruction.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.originalMessageId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructionId"
        }
    ]
}

For instant payments, likely unique and therefore highly selective, we would expect only a single document for any given value. For bulk payments there could be tens of thousands of documents for a single instruction.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.transactionId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.endToEndId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.uetr"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.assignmentId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.cancellationId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.returnId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.statusRequestId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.cancellationStatusId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.paymentInstructionId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.initiatingPartyName"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.initiatingPartyId"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructingAgent"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.instructedAgent"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debtorName"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debtorAccount"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.debtorAgentBIC"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditorName"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditorAccount"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.creditorAgentBIC"
        },
        {
            "direction" : "DESC",
            "key" : "_id"
        }
    ]
}

For instant payments, probably highly selective, we would expect only a few documents for any given value. For bulk payments there could be tens of thousands of documents for a single instruction. Field value will be lower case, and searches will be a starts with regex.

Indexes declared in CosmosDB mode

Tabla 21. Indexes for customObjects collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "associationId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "createdAt"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "source"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.
Tabla 22. Indexes for processes collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "idempotencyKey"
        }
    ]
}

Unique per unitOfWorkId and possibly also unique globally so offers high selectivity. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

High selectivity - depending on the implementation, should identify double to triple digit objects. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "primaryAssociation"
        }
    ]
}

High selectivity, similar to unitOfWorkId - will usually hold either a unitOfWorkId or a flow ID. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Likely unique and therefore highly selective, in most cases we would expect only a few objects for a given value. There will, however, be many process objects with the value 'UNKNOWN' which can give low selectivity if this is used as a search value. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "createdAt"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "source"
        }
    ]
}

Has low selectivity, we can expect a large number of documents with the same value. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "objectType"
        }
    ]
}

Has low selectivity, we can expect a large number of documents with the same value. Applicable to all process object types

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "direction"
        }
    ]
}

Has low selectivity, we can expect a large number of documents with the same value. Only applicable to message log process objects

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "type"
        }
    ]
}

Has low selectivity, we can expect a large number of documents with the same value. Only applicable to system event process objects

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "name"
        }
    ]
}

Has low selectivity, we can expect a large number of documents with the same value. Only applicable to system event process objects

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "level"
        }
    ]
}

Has low selectivity, we can expect a large number of documents with the same value. Only applicable to system event process objects
Tabla 23. Indexes for pds collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "pdsObjectId"
        }
    ]
}

Unique per unit of work only, e.g., there will be 1+ pds objects with the same pdsObjectId per unitOfWorkId

 
{
    "keys-spec" : [
        {
            "direction" : "DESC",
            "key" : "sequenceNumber"
        }
    ]
}

Latest PDS object search does a descending sort on sequenceNumber
Tabla 24. Indexes for summaries collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect a single summary for a clientRequestId. May eventually be removed since the clientRequestId is also present in the alternativeIds.value index

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "relatedUnitOfWorkId"
        }
    ]
}

Links a summary, to the parent/related summary. Many summaries could link to the same "parent" summary, e.g. many batches link to a single bulk, or many payments link to a single batch which means a summary can have [0..1] parents, and [0..n] children.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "alternativeIds.value"
        }
    ]
}

Values should be highly selective, if there’s any duplication, results should be small enough to be sorted in-memory

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "startedAt.value"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "globalStatus.value"
        }
    ]
}

Has low selectivity, we can expect a large number of summaries with the same value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "paymentType.value"
        }
    ]
}

Has low selectivity, we can expect a large number of summaries with the same value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "journeyType"
        }
    ]
}

Has low selectivity, we can expect a large number of summaries with the same value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "totalAmount.value"
        }
    ]
}

totalAmount will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "totalAmountCurrency.value"
        }
    ]
}

totalAmountCurrency has low selectivity, we can expect a large number of summaries with the same currency

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "chargeAmount.value"
        }
    ]
}

chargeAmount will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "chargeAmountCurrency.value"
        }
    ]
}

chargeAmountCurrency has low selectivity, we can expect a large number of summaries with the same currency

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.$**"
        }
    ]
}

CosmosDB’s unique way of indexing all the fields within document; will be a mix of high (uetr, ID fields, accounts numbers, creditor/debtor names etc) and low selectivity fields (reason codes, amounts, currency, BICs)
Tabla 25. Indexes for payments collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "paymentObjectId"
        }
    ]
}

Likely unique and therefore highly selective, we would expect only a single document for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "parentPaymentObjectId"
        }
    ]
}

For instant payments, likely to be highly selective, we would expect only a few documents for a given value. For bulk payments there could be tens of thousands of documents for some values..

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "primaryAssociations"
        }
    ]
}

For instant payments, likely to be highly selective, we would expect only a few documents for a given value. For bulk payments there could be tens of thousands of documents for some values..

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "unitOfWorkId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "clientRequestId"
        }
    ]
}

Highly selective, we would expect only a few documents for any given value.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "objectType"
        }
    ]
}

Usually very low selectivity, there will be a large number of documents for most lookups. High selectivity for rare ISO types like R-messages.

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "createdAt"
        }
    ]
}

Will be used in ranged queries, where the upper or lower bound could be missing. If both bounds are present the selectivity could be very high for small enough ranges. If the range is large, or a bound is missing then the selectivity could be very low.

 
{
    "keys-spec" : [
        {
            "direction" : "DESC",
            "key" : "sequenceNumber"
        }
    ]
}

Latest payment object search does a descending sort on sequenceNumber

 
{
    "keys-spec" : [
        {
            "direction" : "ASC",
            "key" : "searchFields.$**"
        }
    ]
}

CosmosDB’s unique way of indexing all the fields within document; will be a mix of high (uetr, ID fields, accounts numbers, creditor/debtor names etc) and low selectivity fields (reason codes, amounts, currency, BICs). Some ID fields may offer medium to low selectivity for bulk payments where a single instruction may create tens of thousands of payment objects.

Akka Jackson Serialización

Dentro del módulo ods-ingestion-core,SummaryHandler utiliza akka-jackson-serialization para manejar la serialización y deserialización de mensajes transmitidos entre actores que se ejecutan en diferentes hosts.

Clases que implementan SummaryCommand extends CborSerializable Las interfaces están marcadas como clases que deben ser serializadas/deserializadas a través de akka-jackson-serialization.

@JsonInclude(JsonInclude.Include.NON_EMPTY)
public interface SummaryCommand extends CborSerializable {
}

En la configuración a continuación, el ipf compartido CborSerializable la interfaz está vinculada al predeterminado jackson-json el serializador, por lo tanto, cualquier cosa que implemente esta Interfaz también está sujeta a este serializador.

akka {
  actor {
    provider = cluster
    serialization-bindings {
      "com.iconsolutions.ipf.core.shared.domain.CborSerializable" = jackson-json
    }
  }
  serialization.jackson {
    jackson-json {
      deserialization-features {
        ADJUST_DATES_TO_CONTEXT_TIME_ZONE = off
      }
    }
  }
}

Personalizaciones

La configuración:`deserialization-features. ADJUST_DATES_TO_CONTEXT_TIME_ZONE` se anula para que se proporcione dateTimes con un desplazamiento (por ejemplo,OffsetDateTime,ZonedDateTime..) no se ajustan a UTC cuando los mensajes son deserializados entre instancias de la SummaryHandler actor. Se puede encontrar más información en el link:https://fasterxml.github.io/jackson-annotations/javadoc/2.8/com/fasterxml/jackson/annotation/JsonFormat. Feature.html#ADJUST_DATES_TO_CONTEXT_TIME_ZONE[Jackson docs].

El @JsonInclude(JsonInclude. Include. NON_EMPTY) anotación aplicada a SummaryCommand se utiliza para excluir valores que están vacíos o nulos de ser serializados y deserializados. Puede encontrar más información en el link:https://fasterxml.github.io/jackson-annotations/javadoc/2.7/com/fasterxml/jackson/annotation/JsonInclude. Include.html#NON_EMPTY[Jackson docs].