Egreso de Processing Data
Resumen
El módulo de egress contiene:
-
Transportes que pueden publicar sobres de IPF Processing Data, por ejemplo, endpoints kafka o http
-
Plugins que traducen los datos de IPF al formato común de IPF Processing Data, compuesto por los tipos conocidos, MDS, PDS, domain events, message logs, system events, etc.
-
POMs “starter” con un conjunto predeterminado de plugins
Modelo de datos y versionado
El modelo de datos utilizado para exportar los datos está definido por una especificación Open API, y se admiten varias versiones. Solo se exportará una versión para cualquier aplicación que use los plugins de egress.
Los plugins de egress exportan datos utilizando la última versión del modelo de datos. Cuando haya una nueva versión disponible, los plugins comenzarán a producir datos en esa versión.
La versión se puede fijar mediante configuración a cualquier versión con la siguiente configuración.
Ruta de config |
Descripción |
|
No hay valor por defecto. Si la versión no se configura explícitamente, se utiliza la última versión. |
Actualmente hay dos versiones del modelo de datos para elegir, la versión 1 y la versión 2. Si no se configura explícitamente, se usa la versión 2.
Ejemplo
Los plugins de egress pueden configurarse para producir datos utilizando la versión 1 del modelo de datos con ipf.processing-data.egress.schema-version = 1.
Una vez que exista esta configuración, todos los datos producidos por los plugins estarán en esa versión, incluso cuando haya nuevas versiones del modelo de datos disponibles.
Cuando esté listo para pasar a la nueva versión, la configuración debe eliminarse o cambiarse, p. ej., ipf.processing-data.egress.schema-version = 2.
Transporte
Es posible depender de ambos transportes, Kafka y HTTP, en una sola aplicación, pero no es determinista cuál quedará habilitado por defecto; deberá configurar explícitamente ipf.processing-data.egress.transport con el transporte deseado.
La versión del modelo IPF Processing Data contenido en el payload se proporciona en la cabecera schema-version, para todos los transportes.
Kafka
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-kafka</artifactId>
</dependency>No necesitará depender de esto directamente si utiliza uno de los POMs starter, que ya incluyen una dependencia de transporte.
Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valor por defecto | Descripción |
|---|---|---|
|
|
Habilita o deshabilita el egress por kafka; cualquier valor distinto de |
El comportamiento por defecto es entregar todos los tipos de IPF Processing Data al topic IPF_PROCESSING_DATA.
Es posible entregar distintos tipos de datos a distintos topics; por ejemplo, cuando se produce un evento que contiene un objeto MDS pacs.008 y un objeto PDS JourneyType, cada uno de esos tipos (event, MDS, PDS) podría viajar junto en un solo sobre a un único topic, o en tres sobres separados a tres topics diferentes.
La configuración por defecto de kafka está bajo la ruta de configuración ipf.processing-data.egress.kafka, por ejemplo:
| Propiedad | Valor por defecto | Descripción |
|---|---|---|
|
|
El topic de Kafka predeterminado al que se publica todo el ipf processing data cuando no se configuran topics adicionales de Kafka |
Vea la guía de configuración para más información sobre cómo configurar IPF Processing Data para exportar a múltiples topics de Kafka.
HTTP
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-http</artifactId>
</dependency>No necesitará depender de esto directamente si utiliza uno de los POMs starter, que ya incluyen una dependencia de transporte.
Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valor por defecto | Descripción |
|---|---|---|
|
|
Habilita o deshabilita el egress por http; cualquier valor distinto de |
|
|
El host del endpoint http de ingress de IPF Processing Data |
|
|
El puerto del endpoint http de ingress de IPF Processing Data |
El egress por http utiliza un conector http de envío; puede encontrar más configuración bajo la clave ipf.processing-data.egress.http.* en la documentación de IPF Connector.
Plugins
Se proporcionan plugins para las aplicaciones de flujo de procesamiento de IPF que producen IPF processing data. Puede tomarlos todos o solo los que necesite. Los POMs starter proporcionan todos los plugins.
Todos los sobres producidos por los plugins de egress contienen un campo source cuyo valor es la propiedad ipf.processing-data.egress.source. El valor por defecto de esta propiedad es un marcador que remite a ipf.application.name.
NOTA: Si ipf.application.name no está definido, el plugin de egress fallará al configurarse y la aplicación no arrancará. Defina el nombre o defina explícitamente ipf.processing-data.egress.source. Esto probablemente vendrá dado si utiliza el módulo de la plataforma ipf-common-starter-core.
System Event Exporter
El módulo system event exporter registra una instancia de com.iconsolutions.payments.systemevents.api.EventProcessor que publicará los system events en el transporte configurado.
Entrega como máximo una vez (At-most once). El system event exporter puede configurarse para ser fire-and-forget u opcionalmente propagar errores del transporte de vuelta al invocador. Los system events pueden almacenarse en buffer, de modo que múltiples System Events con el mismo contexto de procesamiento se consoliden en un único DataEnvelope antes de egresarse.
Cómo usarlo
Si no utiliza un POM starter, puede usar este plugin directamente con
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-system-event-processor</artifactId>
</dependency>Este plugin es una implementación de com.iconsolutions.ipf.core.systemevents.api.EventProcessor y por lo tanto tiene dos niveles de configuración, el primero a nivel del system event exporter y el segundo a nivel de la implementación de ipf-processing-data.
Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilita o deshabilita el plugin system-event-exporter |
|
|
|
Almacena system events en buffer y los envía como DataEnvelopes consolidados, agrupados por su contexto de procesamiento respectivo. |
|
|
|
Número de system events a almacenar en buffer antes de consolidar por contexto de procesamiento |
|
duración como |
|
Tiempo de espera antes de consolidar system events por contexto de procesamiento cuando el buffer no se llena. |
|
|
|
Define si deben propagarse los fallos al invocador al intentar exportar datos |
NOTA: Establecer propagate-transport-errors en true aplicará back pressure en cada evento hasta que sea enviado, hasta send-buffer-timeout. Esto asegura que los eventos nunca se pierdan, a costa de añadir esa latencia al procesamiento de transacciones en cada evento enviado como parte de la ejecución del flujo.
Message Logger
El módulo message logger registra una instancia de com.iconsolutions.ipf.core.messagelogger.CheckpointAwareMessageLogger que publicará message logs al transporte configurado. Esto permite que los conectores que utilizan este MessageLogger mantengan la relación causal entre “pseudo-events” mediante Checkpointing.
Entrega como máximo una vez (At-most once). El message logger puede configurarse para ser fire-and-forget u opcionalmente propagar errores del transporte de vuelta al invocador. Los Message Logs pueden almacenarse en buffer, de modo que múltiples Message Logs con el mismo contexto de procesamiento se consoliden en un único DataEnvelope antes de egresarse.
Cómo usarlo
Si no utiliza un POM starter, puede usar este plugin directamente con
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-message-logger</artifactId>
</dependency>Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilita o deshabilita el plugin message-logger |
|
|
|
Tamaño de la cola del conector que indica el número de entradas que pueden almacenarse en buffer |
|
|
|
Almacena message logs en buffer y los envía como DataEnvelopes consolidados, agrupados por su contexto de procesamiento respectivo |
|
|
|
Número de message logs a almacenar en buffer antes de consolidar por contexto de procesamiento |
|
duración como |
|
Tiempo de espera antes de consolidar message logs por contexto de procesamiento cuando el buffer no se llena |
|
|
|
Define si deben propagarse los fallos al invocador al intentar exportar datos |
NOTA: Establecer propagate-transport-errors en true aplicará back pressure en cada message log hasta que sea enviado, hasta send-buffer-timeout. Esto asegura que los message logs nunca se pierdan, a costa de añadir esa latencia al procesamiento de transacciones en cada message log enviado como parte de la ejecución del flujo.
Model Exporter
El Model Exporter recopila todo el metadato del process flow de la aplicación de flujo de procesamiento cuando arranca y publica el metadato en un único sobre.
Puede haber muchas aplicaciones desplegadas que contengan el mismo process flow y, al arrancar/reiniciar la aplicación, todas publicarán el mismo metadato del process flow. Esto es esperado y los duplicados deben manejarse aguas abajo.
Sobrescribe el id único para el metadato del process flow, que se compone del nombre del process flow y su identificador.
Entrega al menos una vez (At-least once). El sobre se publica inmediatamente cuando arranca la aplicación, incluidos los reinicios.
Cómo usarlo
Si no utiliza un POM starter, puede usar este plugin directamente con
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-model-exporter</artifactId>
</dependency>Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilita o deshabilita el plugin model exporter |
Journal Processor
El módulo journal processor registra una instancia de com.iconsolutions.ipf.platform.read.processor.EventProcessor que consume todos los eventos persistidos del journal.
Extrae objetos MDS y PDS de cada evento y los agrupa en un único sobre.
Entrega al menos una vez (At-least once). El sobre se publica inmediatamente.
Cómo usarlo
Si no utiliza un POM starter, puede usar este plugin directamente con
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-journal-processor</artifactId>
</dependency>Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilita o deshabilita el plugin journal processor |
Direct Data Exporter
El módulo direct data exporter proporciona la capacidad de publicar directamente estructuras de datos (MDS, PDS, etc.) al transporte configurado.
Entrega como máximo una vez (At-most once). El exporter puede configurarse para ser fire-and-forget u opcionalmente propagar errores del transporte de vuelta al invocador. Los datos exportados pueden almacenarse en buffer, de modo que múltiples estructuras de datos con el mismo contexto de procesamiento se consoliden en un único DataEnvelope antes de egresarse.
|
Cuando se usan transportes de conector Kafka, un buffer de Direct Data Exporter solo puede configurarse cuando el topic de Kafka para Data Structures y Message Logs es el mismo. Vea la guía para más información sobre cómo configurar IPF Processing Data para exportar a múltiples topics de Kafka. |
Modo de uso
Puede usar este plugin directamente con
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-exporter</artifactId>
</dependency>Habilitado por defecto cuando está presente como dependencia, pero puede configurarse explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilita o deshabilita el plugin message-logger |
|
|
|
Tamaño de la cola del conector que indica el número de entradas que pueden almacenarse en buffer |
|
|
|
Almacena entradas en buffer y las envía como DataEnvelopes consolidados, agrupados por su contexto de procesamiento respectivo. |
|
|
|
Número de entradas a almacenar en buffer antes de consolidar por contexto de procesamiento. |
|
duración como |
|
Tiempo de espera antes de consolidar entradas por contexto de procesamiento cuando el buffer no se llena. |
|
|
|
Define si deben propagarse los fallos al invocador al intentar exportar datos |
NOTA: Establecer propagate-transport-errors en true aplicará back pressure en cada exportación de datos hasta que sea enviada, hasta send-buffer-timeout. Esto asegura que las exportaciones de datos nunca se pierdan, a costa de añadir esa latencia al procesamiento de transacciones en cada exportación enviada como parte de la ejecución del flujo.
MDS Exporter
La interfaz IpfProcessingDataEgressMdsExporter se utiliza para exportar estructuras de datos MDS al transporte configurado.
Las estructuras de datos MDS se envuelven en una instancia MdsWrapper que le permite proporcionar el id y parentId deseados para el objeto MDS de nivel superior a exportar.
Si no se proporcionan id y parentId en la instancia MdsWrapper, la implementación por defecto generará un id único (y si aplica, parentId) para los objetos MDS exportados
PDS Exporter
La interfaz IpfProcessingDataEgressPdsExporter se utiliza para exportar estructuras de datos PDS al transporte configurado.
Se puede especificar un name como identificador único para el objeto PDS a exportar.
Si no se proporciona un name, la implementación por defecto generará un name para el objeto PDS exportado usando el tipo PdsObject.
MessageLog Exporter
La interfaz IpfProcessingDataEgressMessageLogExporter se utiliza para exportar estructuras de datos Message Log al transporte configurado.
El exporter devuelve un uniqueId y reference. uniqueId es un identificador para el objeto Message Log exportado; se genera si no se especifica explícitamente. reference es el identificador de un Message Log almacenado externamente debido a su tamaño de archivo, si corresponde.
Elementos de datos de negocio específicos del procesamiento
Al extraer process objects de los domain events, el journal processor busca elementos de datos de negocio predefinidos.
Si se encuentra cualquiera de los siguientes elementos entre las entradas de datos de negocio de un domain event con la categoría PAYMENT_PROCESSING, se tratarán como metadatos de procesamiento relacionados con la unidad de trabajo del evento.
-
PaymentType, que representa el tipo de pago definido por el cliente en la Solución IPF en un momento dado. -
PaymentJourneyType, que representa el tipo asignado a una colección de objetos de pago ISO que representan un pago. -
Csm, que representa el Clearing & Settling Mechanism seleccionado como parte del procesamiento del pago. -
Priority, que representa la prioridad del pago en relación con el SLA; tanto el valor de prioridad (y el comportamiento subsiguiente) es configurable por solución de cliente IPF. -
TimeZone, que representa el desfase de la zona horaria del sistema de procesamiento. -
RelatedUnitOfWork, que es el unitOfWorkId de una unidad de trabajo relacionada, p. ej., el pago original que se está reclamando, o el lote padre del pago.
Métricas
Se informará la siguiente métrica por el journal processor:
-
ipf_processing_data_journal_latency, que registra la duración entre el momento en que se ha creado un domain event y el momento en que se ha enviado a ODS; las duraciones serán sensibles a la desviación horaria entre servidores, por lo que deben considerarse estimaciones únicamente