Conceptos
Tipos de datos
El tipo principal es el sobre de IPF Processing Data, que actúa como contenedor de mensajes y puede contener cualquier número de tipos de datos admitidos. También contiene el contexto de procesamiento para los datos incluidos en el sobre.
Los tipos de datos admitidos se dividen en tres categorías: processing, MDS y PDS.
Process Objects
Los process objects son aquellos que se originan alrededor del procesamiento de un pago; por ejemplo, se produce un process object por cada mensaje que el flujo de procesamiento de IPF intercambia con otro sistema.
A los process objects se les asigna un id único por defecto, que se compone de la "primary association" y un uuid generado aleatoriamente. 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.
Estructuras de datos
MDS Objects
Un Message Data Structure (MDS) object es una estructura de datos que se origina a partir de objetos iso 20022; por ejemplo, una instrucción pain.001 contiene un encabezado de grupo, una o más instrucciones y, dentro de cada instrucción, una o más transacciones de transferencia de crédito. Cada uno se considera un objeto MDS distinto, que pertenece al pago original o unidad de trabajo.
Cuando un pain.001 es recibido por un flujo de procesamiento de IPF y se expone como un elemento de datos de negocio con el tipo MESSAGE_DATA_STRUCTURE, se divide en partes; por ejemplo, un elemento de datos pain.001 se dividiría en tres objetos: el CustomerCreditTransferInitiation de nivel superior, el PaymentInstruction y un CreditTransferTransaction, y esas partes se entregan en un único sobre.
Cada objeto individual recibe un id único y estable con el formato unit-of-work-id|data-element-name|sequence|object-name. Por ejemplo, para cada uno de los objetos pain.001 tendrían los ids uow1|DataElement1|0|CustomerCreditTransferInitiation, uow1|DataElement1|0|PaymentInstruction y uow1|DataElement1|0|CreditTransferTransaction.
Si el pain.001 contuviera múltiples instrucciones y/o transacciones, entonces cada instrucción o transacción hermana tendría su propio id único debido a la secuencia.
Debido a que este id es estable, cualquier otro evento que contenga el mismo pain.001 producirá los mismos objetos, con los mismos ids, lo que permite a los consumidores posteriores identificar duplicados.
PDS Objects
Un Processing Data Structures (PDS) object es una estructura de datos para almacenar datos que se generan durante el procesamiento de una transacción. IPF incluye un conjunto de definiciones estándar de PDS Object, y también permite la implementación de objetos PDS específicos del cliente.
Los objetos PDS se identifican por su nombre, que es único dentro del contexto de una unidad de trabajo y consistente a través de diferentes versiones del mismo objeto PDS. Las diferentes versiones de un objeto PDS con el mismo nombre se distinguen por el número de secuencia del evento del que se originaron.
Los objetos PDS estándar de IPF son:
| Nombre del objeto PDS | Descripción |
|---|---|
|
El tipo de pago específico del cliente para esta unidad de trabajo; puede ser cualquier valor que quiera el cliente. |
|
El tipo de journey específico de IPF para esta unidad de trabajo; debe ser un tipo admitido por IPF core, por ejemplo, PAYMENT, RECALL, etc. |
|
El Clearing and Settlement Mechanism asignado a esta unidad de trabajo |
|
La prioridad para esta unidad de trabajo |
|
La zona horaria para esta unidad de trabajo |
|
Los datos de divisas (foreign exchange) para esta unidad de trabajo |
|
Una unidad de trabajo relacionada con la unidad de trabajo actual; por ejemplo, para un recall podría ser el id de unidad de trabajo del pago original |
|
Un identificador que puede añadirse a esta unidad de trabajo como método alternativo de identificación |
Egress
ipf-processing-data-egress contiene módulos para publicar ipf processing data
Ingress
ipf-processing-data-ingress contiene módulos para consumir ipf processing data
Simulador
El simulador está construido sobre ipf-simulator-ng, permitiendo peticiones de requests, carga y REST de estadísticas. (Consulte la documentación para más información).
Hay una página web del simulador en /index.html en el puerto 55555, que hace uso de las llamadas REST mencionadas.
El simulador genera múltiples Data Envelopes y los envía al topic IPF_PROCESSING_DATA.
Actualmente, el simulador envía los siguientes 7 eventos al topic por cada transacción enviada:
Por defecto, el simulador produce datos usando la versión 2 del modelo de datos. Se puede configurar para producir datos usando la versión 1 del modelo de datos con ipf.processing-data.egress.schema-version = 1.
|
| Tipo de evento | Contenido |
|---|---|
MdsObjects & ProcessObjects |
MdsObjects → PAIN_001 & PAIN_001_PAYMENT_INSTRUCTION & PAIN_001_CREDIT_TRANSFER_TRANSACTION ProcessObjects → ProcessFlowEvent → Flow Initiated |
ProcessObjects |
ProcessFlowEvent → Cleared And Settled |
ProcessObjects |
ProcessFlowEvent → Sanctions Passed |
ProcessObjects |
ProcessFlowEvent → Fraud Check Passed |
ProcessObjects |
ProcessFlowEvent → Fraud Passed |
ProcessObjects |
ProcessFlowEvent → Payment Enriched |
ProcessObjects |
ProcessFlowEvent → Payment Complete |