Documentation for a newer release is available. View Latest

Persistence

Bases de datos compatibles

Actualmente, ipf-ods solo es compatible con MongoDB, pero también puede funcionar con Azure Cosmos DB ya que implementa el protocolo de red de MongoDB.

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@

Ejecutar pruebas e2e locales contra Azure Cosmos DB

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

Colecciones

Nombre Descripción

payments

Contiene objetos de pago ISO 20022.

pds

Contiene tipos PDS definidos por IPF y específicos del cliente

processes

Datos relacionados con el procesamiento de un pago. Estos documentos tienen un objectType para indicar el tipo de datos de procesamiento, 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 bruto de las otras colecciones.

unitOfWorks

Metadatos para un unitOfWorkId dado, construidos a partir de eventos de flujo de proceso ingeridos.

purgeReports

Entrada diaria que documenta los detalles de una ejecución de purge. Creada durante ODS-Purging

expiryReports

Entrada diaria que documenta el número de unitOfWorks que deberían expirar en n días.

archiverCandidateSelectionState

Rastrea el estado de selección de candidatos para archivado. Creado durante Candidate Selection

Indexación

De forma predeterminada, las aplicaciones ingestion e inquiry intentarán crear todos los índices necesarios al inicio. Para desactivar este comportamiento y crear los índices manualmente, proporcione la siguiente configuración:

ods.persistence.indexing.enabled = false

Aunque los protocolos de red son iguales, las implementaciones del motor de base de datos subyacente difieren entre MongoDB y CosmosDB, lo que impacta las opciones de indexación. Por ello, las aplicaciones ODS crearán un conjunto diferente de índices dependiendo de a qué base de datos hablen, siendo el modo de creación de índices para MongoDB 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" : "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" : "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"
        },
        {
            "direction" : "ASC",
            "key" : "entityId"
        }
    ]
}

Highly selective, there will exist a small number (depending on implementation, tens to low hundreds) of process flow events for an entityId. Only applicable to process flow event process objects
Tabla 18. Indexes for summaries collection
Index definition Comments 
{
    "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" : "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 19. Indexes for payments collection
Index definition Comments 
{
    "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 20. Indexes for customObjects collection
Index definition Comments 
{
    "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" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of 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 21. Indexes for processes collection
Index definition Comments 
{
    "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" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of documents for any given 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

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

Highly selective, there will exist a small number (depending on implementation, tens to low hundreds) of process flow events for an entityId. Only applicable to process flow event process objects
Tabla 22. Indexes for pds collection
Index definition Comments 
{
    "keys-spec" : [
        {
            "direction" : "DESC",
            "key" : "sequenceNumber"
        }
    ]
}

Latest PDS object search does a descending sort on sequenceNumber
Tabla 23. Indexes for payments collection
Index definition Comments 
{
    "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" : "processingEntity"
        }
    ]
}

Very low selectivity, there will be a large number of 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.
Tabla 24. Indexes for summaries collection
Index definition Comments 
{
    "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" : "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)

Akka Jackson Serialization

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

Las clases que implementan la interfaz SummaryCommand extends CborSerializable están marcadas como clases que deben serializarse/deserializarse a través de akka-jackson-serialization.

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

En la configuración siguiente, la interfaz compartida de IPF CborSerializable se vincula al serializador jackson-json predeterminado; por lo tanto, todo lo que implemente esta interfaz también se vincula 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

El ajuste de configuración: deserialization-features.ADJUST_DATES_TO_CONTEXT_TIME_ZONE se anula para que las dateTimes con un desplazamiento (p. ej., OffsetDateTime, ZonedDateTime…​) no se ajusten a UTC cuando los mensajes se deserializan entre instancias del actor SummaryHandler. Puede encontrar más información en la documentación de Jackson.

La anotación @JsonInclude(JsonInclude.Include.NON_EMPTY) aplicada a SummaryCommand se utiliza para excluir valores vacíos o nulos de la serialización y deserialización. Puede encontrar más información en la documentación de Jackson.