Almacenamiento y Lectura de Información de Pago
La información de pago (detalles de iniciación, instrucción y transacción) se almacena inicialmente mediante un flujo de procesamiento.
Cualquier cancelación/cambio posterior de los detalles de pago no actualizará la entrada original. En su lugar, se insertarán nuevas entradas. Este ajuste de las Entradas de Pago puede ser creado de dos maneras diferentes, ya sea:
-
manteniendo únicamente el detalle específico del ajuste que se está actualizando, o
-
manteniendo un Mensaje de Pago completo y actualizado, incluyendo los ajustes que se están aplicando
Elegir una de las opciones anteriores afecta cuál implementación de la fuente de datos del Almacén de Pagos es adecuada para su caso de uso. Análogamente a las opciones anteriores, hay 2 implementaciones apropiadas de la fuente de datos del Almacén de Pagos a su disposición:
-
Fuente de datos del almacén de entradas agregadas
-
Última Entrada Fuente de Datos del Almacén
Fuente de Datos del Almacén de Entradas Agregadas
Almacenar únicamente los detalles de ajuste significa que el almacenamiento no contiene una versión singular de una entrada de información de pago actualizada, con todos los ajustes aplicados. La fusión de información relacionada se realiza en el lado de lectura al recuperar la información de pago almacenada.
| La implementación del origen de datos del Almacén de Entradas Agregadas es responsable de aplicar cualquier ajuste adicional realizado a la información de pago almacenada inicialmente. |
Agregación de información
La implementación de la fuente de datos del Almacén de Pagos de Entradas Agregadas lee los datos del Almacén de Pagos y los agrega. Para observar cómo funciona la fusión, podemos utilizar un ejemplo de Entrada de Pago por Instrucción.
Cuando un flujo de procesamiento almacena inicialmente detalles sobre una Instrucción de Pago, crea un PaymentEntry objeto y lo almacena en el Almacén.
{
"_id": "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19|0",
"unitOfWorkId": "f4c5d646-fe8e-4586-bf32-496ce8814344",
"relatedUnitOfWork": "63051ca7-3592-40b1-a5d2-b7e69e602b8d",
"clientRequestId": "ac541cde-00fc-427f-be5f-23c2f091718e-filehappy",
"associationId": "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19",
"processingEntity": "BANK_ENTITY_1",
"sequence": 0,
"globalState": "PENDING",
"type": "BULK",
"data": [
{
"objectId": "5945909f-0cfc-43f8-a28d-b92d1823e6a9",
"parentObjectId": "2c235f35-b6b2-414a-a298-caf86f1e4e45",
"name": "Pain001Instruction",
"category": "MDS",
"contentType": "com.iconsolutions.iso20022.message.components.payment_instruction.payment_instruction30.PaymentInstruction30",
"content": "{.......}"
}
],
"_class": "com.iconsolutions.ipf.warehouse.port.mongo.repository.MongoPaymentEntry"
}
Cualquier cambio posterior (ajuste de datos o cancelación) resulta en almacenar un adicional PaymentEntry entrada de objeto. La nueva entrada se crea con un idéntico unitOfWorkId valor como el inicial PaymentEntry el objeto y su valor de secuencia aumentaron en uno.
{
"_id" : "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19|1",
"unitOfWorkId" : "f4c5d646-fe8e-4586-bf32-496ce8814344",
........
"sequence" : 1,
"globalState" : "CANCELLED"
}
AggregateEntriesWarehouseDataSource`encapsula la lógica para aplicar instrucciones adicionales `PaymentEntry ajustes en una interfaz funcional definida como:
Function<List<PaymentEntry>, MyPaymentWarehouseInstruction> instructionAggregatorFunction
De manera similar, también existen interfaces funcionales para la agregación de información de Iniciación y Transacción:
-
Function<List<PaymentEntry>, <Optional<MyPaymentWarehouseInitiation>> initationAggregatorFunction, y -
Function<List<PaymentEntry>, MyPaymentWarehouseTransaction> transactionAggregatorFunction
Proporcionando initationAggregatorFunction es opcional. Puede omitirse si no está almacenando información del nivel de Iniciación en primer lugar.
|
Última Entrada Fuente de Datos del Almacén
Cuando aplique cada ajuste sobre los ajustes anteriores (y la información de pago almacenada inicialmente), entonces la entrada de pago más reciente tendrá información completa y actualizada.
Utilizando un ejemplo similar al anterior, el inicial PaymentEntry El objeto creado por el flujo de procesamiento y almacenado en el almacén será idéntico en este caso también.
{
"_id": "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19|0",
"unitOfWorkId": "f4c5d646-fe8e-4586-bf32-496ce8814344",
"relatedUnitOfWork": "63051ca7-3592-40b1-a5d2-b7e69e602b8d",
"clientRequestId": "ac541cde-00fc-427f-be5f-23c2f091718e-filehappy",
"associationId": "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19",
"processingEntity": "BANK_ENTITY_1",
"sequence": 0,
"globalState": "PENDING",
"type": "BULK",
"data": [
{
"objectId": "5945909f-0cfc-43f8-a28d-b92d1823e6a9",
"parentObjectId": "2c235f35-b6b2-414a-a298-caf86f1e4e45",
"name": "Pain001Instruction",
"category": "MDS",
"contentType": "com.iconsolutions.iso20022.message.components.payment_instruction.payment_instruction30.PaymentInstruction30",
"content": "{.......}"
}
],
"_class": "com.iconsolutions.ipf.warehouse.port.mongo.repository.MongoPaymentEntry"
}
Nuevamente, cualquier cambio posterior (ajuste de datos o cancelación) resultará en el almacenamiento de un adicional PaymentEntry objeto, teniendo el idéntico unitOfWorkId valor como el inicial PaymentEntry objeto, y aumentando su valor de secuencia en uno.
Solo esta vez, `Payment Entry' contendrá una entrada inicial completa y se le aplicarán los ajustes.
{
"_id": "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19|0",
"unitOfWorkId": "f4c5d646-fe8e-4586-bf32-496ce8814344", (1)
"relatedUnitOfWork": "63051ca7-3592-40b1-a5d2-b7e69e602b8d",
"clientRequestId": "ac541cde-00fc-427f-be5f-23c2f091718e-filehappy",
"associationId": "BatchInitiation|6e6cf57a-7201-43db-b9db-a8c33e3a0b19",
"processingEntity": "BANK_ENTITY_1",
"sequence": 1, (2)
"globalState": "CANCELLED", (3)
"type": "BULK",
"data": [
{
"objectId": "5945909f-0cfc-43f8-a28d-b92d1823e6a9",
"parentObjectId": "2c235f35-b6b2-414a-a298-caf86f1e4e45",
"name": "Pain001Instruction",
"category": "MDS",
"contentType": "com.iconsolutions.iso20022.message.components.payment_instruction.payment_instruction30.PaymentInstruction30",
"content": "{.......}"
}
],
"_class": "com.iconsolutions.ipf.warehouse.port.mongo.repository.MongoPaymentEntry"
}
<1>`unitOfWorkId` idéntico al de la Entrada de Pago inicial <2>`sequence` el valor aumentó en uno <3> Cambio de estado CANCELLED aplicado a los datos iniciales
En este caso, la fusión de datos en el lado de lectura no es necesaria. Solo el Registro de Pago que se está leyendo necesita ser mapeado al mensaje de pago de Iniciación/Instrucción/Transacción apropiado. Fetching y mapping es manejado por la propia Fuente de Datos, usted solo necesita implementar y conectar las siguientes interfaces funcionales:
-
Función<PaymentEntry,MyPaymentWarehouseInstruction>instructionMapper
-
Función<PaymentEntry,MyPaymentWarehouseTransaction>transactionMapper
-
Función<PaymentEntry,MyPaymentWarehouseInitiation>initiationMapper
Proporcionando initiationMapper es opcional. Puede omitirse si no está almacenando información del nivel de Iniciación en primer lugar.
|