Ingestion Service
ODS consume IPF Processing Data desde Kafka, lo transforma al modelo de datos ODS y lo persiste en la base de datos.
Los datos relacionados con un pago llegan con un contexto de procesamiento compuesto por:
-
unitOfWorkId- agrupa todos los datos de un único pago/unidad de trabajo -
associationId- identifica el flow del que se originaron los datos -
clientRequestId- el id de solicitud original del cliente para el pago/unidad de trabajo -
processingEntity- agrupa pagos bajo distintas entidades
El flujo general de alto nivel desde los datos de procesamiento IPF a los datos ODS persistidos es:
UnitOfWork
Se persiste un único UnitOfWork en la base de datos por cada unitOfWorkId que es procesado por IPF; esto sirve como metadatos para un unitOfWork dado.
Las marcas de tiempo de Process Flow Event se persisten en los objetos UnitOfWork y se utilizan para identificar el inicio y el fin del ciclo de vida de un unitOfWork.
Summary
Parte de los datos ODS persistidos se publican a un actor de payment summary, que aplica los datos sucesivamente para crear/actualizar una vista persistida de summary.
Los datos se mapean a campos de summary, como se describe en la página Summary Mapping.
Tipos de datos admitidos
Los tipos de datos admitidos para datos pertenecientes a un pago se dividen en cuatro categorías: mds, pds, process y custom.
MDS Objects
Los objetos MDS son aquellos que se originan a partir de objetos ISO 20022; por ejemplo, una instrucción pain.001 contiene un group header, una o más instrucciones y, dentro de cada instrucción, una o más credit transfer transactions. Cada uno se considera un objeto MDS distinto que pertenece al pago original o unidad de trabajo. Cuando se recibe un pain.001 por un flow de procesamiento de IPF, se divide en partes y todas esas partes se publican a ODS en un único mensaje.
PDS Objects
Los objetos PDS son tipos definidos por IPF, p. ej., Csm o JourneyType, o son tipos personalizados definidos por el cliente. Una unidad de trabajo puede tener solo un objeto PDS por nombre, y rastrea diferentes versiones de ese objeto con un número de secuencia.
El mayor número de secuencia de todas las versiones de un objeto PDS específico se considera la versión "latest" de ese objeto.
Los objetos PDS duplicados, donde el nombre y el número de secuencia son los mismos para una unidad de trabajo dada, se ignoran.
Process Objects
Los objetos Process son aquellos que se originan alrededor del procesamiento de un pago; por ejemplo, se produce un objeto de proceso por cada mensaje intercambiado con otro sistema por el flow de procesamiento IPF.
A los objetos Process se les asigna un identificador único por defecto, que se compone de la "primary association" y un uuid generado aleatoriamente. Este ID único es utilizado por ODS para determinar si los objetos de proceso se han visto antes. Por ejemplo, si un objeto se publica más de una vez o se consume más de una vez, entonces solo existirá una única instancia en la base de datos siempre que los objetos recibidos tengan el mismo ID único.
Custom Objects
NOTA: Los objetos Custom ya no se ingieren en ODS, pero los attachments siguen siendo compatibles y se almacenan en la colección de custom objects.
Los objetos Custom representan datos pertenecientes a un pago que no es un objeto MDS ISO 20022 ni un objeto de proceso. Es probable que este objeto contenga datos relacionados con pagos específicos del cliente.
Los objetos de datos Custom suelen ser pares clave/valor.
Versioning
ODS mantiene compatibilidad hacia atrás con la versión de esquema de IPF Processing Data producida por IPF. La siguiente tabla describe las versiones.
| Version | Compatibility |
|---|---|
1 |
Supported but deprecated |
2 |
Supported |
Bulk Writes
ODS Ingestion utiliza comandos de escritura en bloque al insertar documentos en la base de datos. El número de documentos que se insertan en un único comando depende del número de Data Envelopes proporcionados por IPF Processing Data Ingress a la implementación de ODS Ingestion BatchedIpfProcessingDataHandler.
Para un rendimiento óptimo de Ingestion, es posible que debas ajustar la configuración de Ingress. Consulta la documentación de Ingress "tuning batch configuration" para más detalles.
Las métricas están habilitadas por defecto para monitorizar la cantidad de documentos que se insertan por comando de base de datos; estas deben usarse junto con las métricas de Ingress para ajustar el rendimiento de ODS Ingestion. Se pueden deshabilitar configurando ods.metrics.enabled = false.
Cuando están habilitadas, se emiten las siguientes métricas:
| Metric name | Possible tags | description |
|---|---|---|
|
type → "MDS", "PDS", "PROCESS", "UNIT_OF_WORK", "SUMMARY" |
Una summary metric que registra el número de documentos que se escriben en un único comando de inserción. |
|
type → "MDS", "PDS", "PROCESS", "UNIT_OF_WORK", "SUMMARY" |
Manejo de errores
Cualquier error lanzado durante la ejecución de una tarea se registra como una advertencia sin que se tome ninguna acción por defecto. Sin embargo, puedes configurar el system event opcional OdsIngestionFailed, ipf.processing-data-egress. La tarea se ejecutará nuevamente en breve y la funcionalidad continuará en ejecuciones posteriores.