Servicio de Ingesta

ODS consume xref:core:processing-data:home.adoc[IPF Processing Data] from Kafka, lo transforma en el ODS modelo de datos y 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 para un único pago/unit of work

  • associationId - identifica el flujo del cual se originó los datos

  • clientRequestId - el identificador de solicitud original del cliente para el pago/unit of work

  • processingEntity - agrupa los pagos bajo diferentes entidades

El flujo general de alto nivel para IPF processing data a persistir ODS data es:

ingestion

UnidadDeTrabajo

Se persiste una única UnidadDeTrabajo en la base de datos para cada unitOfWorkId que es procesado por IPF, esto sirve como meta-datos para una unidadDeTrabajo dada.

Process Flow Event Las marcas de tiempo se persisten en los objetos UnitOfWork y se utilizan para identificar el inicio y el final del ciclo de vida de un unitOfWork.

Resumen

Algunos de los persistidos ODS Los datos se publican a un actor de resumen de pagos, que aplica los datos a su vez para crear/actualizar una vista de resumen persistente.

Los datos se mapean en campos de resumen, como se describe en el Resumen de Mapeo página.

Soportado Data Type s

El soportado data type s para datos pertenecientes a un pago se desglosan en cuatro categorías,mds,pds, proceso, y custom.

MDS Objetos

 MDS Los objetos son aquellos que se originan a partir de objetos ISO 20022.- por ejemplo un pain. 001 instrucción contiene un encabezado de grupo, uno o más instructions, y dentro de cada instrucción, una o más transacciones de transferencia de crédito.
Cada uno se considera un distinto MDS objeto, que pertenece al pago original o unit of work.
Cuando un pain. 001 es recibido por un flujo de procesamiento IPF, se descompone en partes, y todas esas partes se publican en ODS en un solo mensaje.

PDS Objetos

 PDS los objetos son tipos definidos por IPF, por ejemplo,Csm, o JourneyType, o son definidos por el cliente custom tipos.
A unit of work puede tener solo un único PDS objeto 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 específico PDS el objeto se considera la versión "más reciente" de ese objeto.

Duplicar PDS objetos, donde el nombre y el número de secuencia son los mismos para un dado unit of work, son ignorados.

Process Objects

Process objects son aquellos que se originan en torno al procesamiento de un pago, por ejemplo un process object se produce para cada mensaje intercambiado con otro sistema por el flujo de procesamiento del IPF.
 Process objects se les asigna un identificador único por defecto, que está compuesto por la "asociación primaria" y un uuid generado aleatoriamente.
Este ID único es utilizado por ODS para determinar si process objects 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 Objetos

Los objetos personalizados ya no son ingeridos por ODS, pero los archivos adjuntos aún son compatibles y se almacenan en el custom colección de objetos. 
 Custom Los objetos representan datos que pertenecen a un pago que no es un ISO 20022. MDS objeto, o un process object.
Es probable que este objeto contenga customer-datos específicos relacionados con el pago.
Custom Los objetos de datos suelen ser pares clave/valor.

Vistas

Las vistas se actualizan a medida que se reciben los datos (resúmenes de pagos), o son una agregación de datos que ya existen (detalles de pagos).

Versioning

ODS mantiene la compatibilidad hacia atrás con la versión del esquema de IPF Processing Data producido por IPF. La siguiente tabla detalla las versiones.
Versión Compatibilidad

1

Compatible pero obsoleto

2

Soportado

Bulk Escribe

ODS Ingestion utiliza bulk escribir comandos al insertar documentos en la base de datos. El número de documentos que se insertan en un solo comando depende del número de Data Envelopes suministrado por IPF Processing Data Ingreso a ODS Ingestion's xref:core:processing-data:guides/consume-processing-data.adoc#_batched[BatchedIpfProcessingDataHandler] implementación.

Para un rendimiento óptimo de Ingesta, puede que necesite ajustar la configuración de Ingress. Consulte la documentación de Ingress.configuración de lote de ajuste documentación para más detalles.

Las métricas están habilitadas por defecto para monitorear el número de documentos que se insertan por comando de base de datos; estas deben ser utilizadas junto con las métricas de Ingress para ajustar. ODS Ingestion rendimiento. Estos pueden ser deshabilitados configurando ods.metrics.enabled = false.

Cuando esté habilitado, se emitirán las siguientes métricas:

Nombre de la métrica Etiquetas posibles descripción

ipf_ods_persistence_writes

tipo → " MDS ", " PDS ", "PROCESO", "UNIDAD_DE_TRABAJO", "RESUMEN"
op → "insertar", "actualizar"

A métrica de resumen que registra el número de documentos que se están escribiendo en un único comando de inserción.

ipf_ods_persistence_duplicate_key_errors

type → " MDS ", " PDS ", "PROCESO", "UNIDAD_DE_TRABAJO", "RESUMEN"

A métrica de contador diseñado para rastrear la ocurrencia de excepciones de clave duplicada durante la inserción de documentos.

En el contexto de la MDS, PDS, y Procese colecciones, estas excepciones son desestimadas, considerando su naturaleza de solo anexar. Sin embargo, cualquier excepción de este tipo para las colecciones UnitOfWork y Summary activa las actualizaciones de documentos apropiadas.

Manejo de Errores

Cualquier error generado durante la ejecución de una tarea se registra como una advertencia sin que se tome ninguna acción por defecto. Sin embargo, usted puede configurar opcionalmente system event OdsIngestionFailed,ipf.procesamiento-datos-salida. La tarea se ejecutará nuevamente en breve y la funcionalidad continuará en ejecuciones posteriores.