Conceptos

① El Servicio de Notificación de Pagos escucha los eventos del procesador de diarios 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 eventos son descartados.

② Al recibir el inicial pain.001 mensaje, todos los parámetros de pago relevantes son extraídos y almacenados en una caché distribuida utilizando el ID de unidad de trabajo (uowID) y persistenceId. En caso de que la caché se pierda debido a un fallo o reinicio, puede ser reconstruida consultando la base de datos principal.

③ Cada domain event se enruta hacia la lógica central, que consulta el servicio de configuración de ajustes de procesamiento para coincidencias exactas basadas tanto en el nombre del evento como en el flujo que lo generó. Puede no encontrar coincidencias o encontrar una única coincidencia.

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

Cada configuración de coincidencia especifica cómo transformar el evento 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 varias notificaciones distintas, cada una adaptada y dirigida 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 la caché. Utiliza el sufijo de la ID de persistencia (todo lo que sigue al carácter “|”) como la clave de caché. A continuación, enriquece el mensaje con cualquier campo configurable que haya sido 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.