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 local e2e test s contra Azure Cosmos DB

Al ejecutar e2e test s, conjunto 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 processing data, 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 ingerido process flow events.

purgeReports

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

expiryReports

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

archiverCandidateSelectionState

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

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 conexión son los mismos, las implementaciones del motor de base de datos subyacente difieren para MongoDB y bases de datos CosmosDB, 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 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 18. 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 19. 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 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" : "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" : "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 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 24. 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 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 de la ods-ingestión-core módulo,SummaryHandler utiliza akka-jackson-serialización 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 se marcan como clases que deben ser serializadas/deserializadas a través de akka-jackson-serialización.

@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
      }
    }
  }
}

Customizations

La configuración:`deserialization-features. ADJUST_DATES_TO_CONTEXT_TIME_ZONE` se anula para que las fechas y horas proporcionadas con un desplazamiento (por ejemplo, OffsetDateTime, ZonedDateTime..) no se ajusten a UTC cuando los mensajes se deserializan entre instancias del actor SummaryHandler. 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].