Conceptos

① El Servicio de Notificación de Pagos escucha a journal processor events en un Kafka tema. El pain. 001 mensaje de pago y específico domain events(pueden establecerse en la especificación de enrutamiento) son consumidos y reenviados para un manejo posterior. Todos los demás mensajes y events son descartados.

② Al recibir el inicial pain. 001 mensaje, todos los parámetros de pago relevantes son extraídos y almacenados en un sistema distribuido cache usando el unit of work ID (uowID) y persistenceId. Debería el cache nunca se perderá debido a un fallo o restart, se puede reconstruir consultando la base de datos principal.

③ Cada domain event se enruta hacia el core lógica, que consulta el servicio de configuración de ajustes de procesamiento para coincidencias exactas basadas en ambos los event el nombre de ’ y el flujo que lo generó. Puede que no encuentre coincidencias o una única coincidencia.

Los ajustes de procesamiento configurables permiten lo siguiente pain. 002 campos a definir:

Cada configuración coincidente especifica cómo transformar el event en una notificación de estado de pago y el destino de esa notificación. Los puntos finales de destino pueden definirse en la configuración de procesamiento configurable. Un único domain event puede producir varios distintos notifications, cada uno adaptado y dirigido de acuerdo con sus propias reglas de transformación.

Para cada configuración encontrada, el sistema crea un paquete de mensajes que contiene el original domain event, los metadatos de transformación especificados y los valores predeterminados para el estado (txSts), campos propietarios (prtry), código (cd) e información adicional (addtlInf). Estos paquetes se entregan al componente de “generar notificación”.

④ El mensaje de notificación generado construye el pain. 002 mensaje. La mayor parte de los datos se recupera de cache. Utiliza el sufijo del ID de persistencia (todo lo que sigue después del carácter “|”) como el cache clave. A continuación, enriquece el mensaje con cualquier campo configurable que se haya definido. Finalmente, la notificación completamente ensamblada se publica en el tema de notificación de estado de pago apropiado (por ejemplo, a través de ActiveMQ, Kafka, etc.), utilizando tanto los detalles del tema como del transporte proporcionados por el mismo servicio de configuración de ajustes.