Flujos de Datos
Para que el estado del pago notifications para ser enviado, es necesario recibir tanto el domain events(acting as a trigger) y los detalles del mensaje de pago inicial (PAIN. 001) para extraer los datos necesarios para completar el PAIN. 002 mensaje que forma la notificación del estado de pago real. El servicio en sí mismo se mantiene independiente y no requiere, por ejemplo, el Almacén de Datos de Operación (ODS). Esto significa que los datos deben ser cached en algún lugar.
El primer diagrama a continuación muestra la recepción de un Domain Event que contiene un PAIN. 001 que ha sido expuesto o publicado desde el IPF Application. Es el inicial event conteniendo el PAIN. 001 mensaje que se utiliza como la fuente de todos los parámetros de pago que se utilizarán para completar el PAIN. 002. Para los fines de notifications esto es lo que necesita ser cached, para que pueda ser accedido en un momento posterior.
Para producir una notificación, al recibir un Domain Event el original PAIN. 001 los datos se recuperan de la cache. Notifications se crean únicamente donde el siguiente events que pasa un filtro basado en el domain event nombre. Luego, basado en la configuración de notificaciones, el servicio producirá una Notificación de Estado de Pago.
Para ofrecer esta capacidad, el servicio utiliza los siguientes componentes:
-
IPF Processing Data ingreso: consumir Domain Events que se publican como parte de IPF application procesamiento. Estos events se consumen de Kafka y esto se logra técnicamente añadiendo lo siguiente maven dependency:
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-ingress-kafka</artifactId>
</dependency>
-
IPF Caching: para almacenar y recuperar datos, añadiendo lo siguiente maven dependency:
<dependency>
<groupId>com.iconsolutions.ipf.core.platform</groupId>
<artifactId>ipf-cache-infinispan</artifactId>
</dependency>
-
Configuración de Notificación de Estado de Pago: a customise campos específicos al producir el PAIN. 002. Más sobre el tema aquí.
-
Dolor 002 Mapper: mapea un PAIN. 002 desde el original Domain Event y el original PAIN. 001 recuperado de la cache
-
Send Connector: utilizando un AlpakkaKafkaProducerConfiguration para producir la Notificación de Estado de Pago
-
IPF Processing Data salida: publicar Message Logs to Kafka, añadiendo lo siguiente maven dependencies:
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-message-logger</artifactId>
</dependency>
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-kafka</artifactId>
</dependency>