Salida Processing Data
Resumen
El módulo de salida contiene:
-
Transportes que pueden publicar IPF Processing Data sobres, p. ej. kafka o puntos finales http
-
Plugins que traducen datos de IPF en el común IPF Processing Data formato, compuesto por los tipos conocidos,MDS, PDS, domain events, registros de mensajes, eventos del sistema, etc.
-
Poms iniciales con un conjunto predeterminado de complementos
Modelo de Datos &Versioning
El modelo de datos utilizado para exportar los datos está definido por un Open API especificación, y se admiten múltiples versiones. Solo se exportará una versión para cualquier aplicación que utilice los complementos de salida.
Los complementos de salida exportan datos utilizando la última versión del modelo de datos. Cuando una nueva versión esté disponible, los complementos comenzarán a producir datos en esa versión.
La versión puede ser fijada a cualquier versión mediante la siguiente configuración.
Ruta de Configuración |
Descripción |
|
No hay un valor predeterminado. Si la versión no está configurada explícitamente, se utiliza la última versión. |
Actualmente hay dos versiones del modelo de datos para elegir, la versión 1, y versión 2. Si no está configurado explícitamente, la versión 2 se utiliza.
Ejemplo
Los complementos de salida pueden ser configurados para producir datos utilizando la versión 1 del modelo de datos con ipf.processing-data.egress.schema-version = 1.
Una vez que esta configuración exista, todos los datos producidos por los complementos estarán en esta versión, incluso cuando nuevas versiones del modelo de datos estén disponibles.
Cuando esté listo para pasar a la nueva versión, la configuración debe ser eliminada o cambiada, por ejemplo.ipf.processing-data.egress.schema-version = 2.
Transporte
Es posible depender de ambos Kafka y HTTP transportes en una sola aplicación, pero no es determinista en cuanto a cuál se habilitará por defecto, y deberá configurarlo explícitamente.ipf.processing-data.egress.transport a su transporte deseado.
La versión de la IPF Processing Data El modelo contenido en la carga útil se proporciona en el encabezado.ipf_schema_version, para todos los transportes.
La carga útil también contendrá el encabezado.schema-version.Este encabezado está obsoleto, la versión final de IPF que admitirá este encabezado es 2026.4, no será compatible en la versión 2027.1 de IPF. Mientras esté soportado, la carga útil incluirá tanto ipf_schema_version y schema-version encabezados y tendrán el mismo valor.
|
Kafka
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-kafka</artifactId>
</dependency>No necesitará depender de esto directamente si está utilizando uno de los poms iniciales, que ya incluye una dependencia de transporte.
Habilitado por defecto cuando está presente como una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valor Predeterminado | Descripción |
|---|---|---|
|
|
Habilite o deshabilite el egress de kafka, cualquier cosa diferente de |
El comportamiento predeterminado es entregar todos IPF Processing Data tipos a los IPF_PROCESSING_DATA tema.
Es posible entregar diferentes tipos de datos a diferentes temas, por ejemplo, cuando un evento que contiene un pacs.008 MDS objeto, y un JourneyType PDS el objeto es producido-cada uno de esos tipos (evento,MDS, PDS) podría viajar junto en un solo sobre a un solo tema, o en tres sobres separados a tres temas diferentes.
La configuración predeterminada de kafka se encuentra en la ruta de configuración.ipf.processing-data.egress.kafka, p. ej.
| Propiedad | Valor Predeterminado | Descripción |
|---|---|---|
|
|
El predeterminado Kafka tema al que se publican todos los datos de procesamiento de ipf cuando no hay adicional Kafka los temas están configurados |
Vea el guía de cómo para más información sobre la configuración IPF Processing Data para exportar a múltiples Kafka Temas.
HTTP
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-http</artifactId>
</dependency>No necesitará depender de esto directamente si está utilizando uno de los poms iniciales, que ya incluye una dependencia de transporte.
Habilitado por defecto cuando está presente como una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valor Predeterminado | Descripción |
|---|---|---|
|
|
Habilite o deshabilite la salida http, cualquier cosa diferente de |
|
|
El anfitrión del punto de entrada de datos de ingreso de procesamiento http ipf |
|
|
El puerto del punto de entrada de datos de procesamiento http ipf |
La salida http utiliza un http send connector, configuración adicional bajo la clave ipf.processing-data.egress.http.* se puede encontrar en el Documentación del conector IPF.
Complementos
Se proporcionan complementos para aplicaciones de flujo de procesamiento IPF que generan datos de procesamiento IPF. Puede tomar todos, o tomar solo aquellos que necesita. Los poms iniciales proporcionan todos los complementos.
Todos los sobres producidos por los complementos de salida contienen un source campo que es el valor de la propiedad ipf.processing-data.egress.source. El valor predeterminado para esta propiedad es un marcador de posición para ipf.application.name.
Si ipf.application.name no está definido, el complemento de salida no podrá configurarse y la aplicación no podrá iniciarse. Defina el nombre, o defina explícitamente ipf.processing-data.egress.source. Esto probablemente vendrá gratis si utiliza el ipf-platform módulo ipf-common-starter-core.
|
System Event Exporter
El módulo exportador de eventos del sistema registra una instancia de com.iconsolutions.payments.systemevents.api. EventProcessor que publicará eventos del sistema al transporte configurado.
Entrega como máximo una vez. El exportador de eventos del sistema puede configurarse para ser de tipo "fire-and-forget" o, opcionalmente, propagar errores del transporte de vuelta al llamador. Los eventos del sistema pueden ser almacenados en búfer, donde múltiples System Events con el mismo contexto de procesamiento se consolidan en un solo DataEnvelope antes de ser egresado.
Cómo Utilizar
Si no utiliza un pom inicial, puede usar este complemento directamente con
<dependency>
<groupId>com.iconsolutions.ipf.core.processingdata</groupId>
<artifactId>ipf-processing-data-egress-system-event-processor</artifactId>
</dependency>Este complemento es una implementación de com.iconsolutions.ipf.core.systemevents.api. EventProcessor y por lo tanto tiene dos niveles de configurabilidad, el primero a nivel del exportador de eventos del sistema, y el segundo en la implementación de procesamiento de datos ipf.
Habilitado por defecto cuando está presente como una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valores | Valor por Defecto | Descripción |
|---|---|---|---|
|
|
|
Habilite o deshabilite el complemento system-event-exporter. |
|
|
|
El sistema de búferes agrupa los eventos y los envía de manera consolidada. DataEnvelopes, agrupados por su respectivo contexto de procesamiento. |
|
|
|
El número de eventos del sistema que se deben almacenar en búfer antes de consolidar por contexto de procesamiento. |
|
una duración como |
|
El tiempo de espera antes de consolidar los eventos del sistema procesando el contexto cuando el búfer no está lleno. |
|
|
|
Define si los fallos deben ser propagados al llamador al intentar exportar datos. |
Configuración propagate-transport-errors to true aplicará presión de retroceso en cada evento hasta que se envíe, 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 que se envía como parte de la ejecución del flujo.
|
Message Logger
El módulo de registro de mensajes registra una instancia de com.iconsolutions.ipf.core.messagelogger. CheckpointAwareMessageLogger que publicará los registros de mensajes en el transporte configurado. Esto permite a los conectores que utilizan esto MessageLogger para mantener la relación causal entre "pseudo-eventos" a través de Punto de control.
Entrega como máximo una vez. El registrador de mensajes puede ser configurado para ser de tipo "fire-and-forget" o, opcionalmente, propagar errores del transporte de vuelta al llamador. Message Logs puede ser almacenado en búfer, donde múltiples Message Logs con el mismo contexto de procesamiento se consolidan en uno solo DataEnvelope antes de ser egresado.
Cómo Utilizar
Si no utiliza un pom inicial, puede utilizar este complemento 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 una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilite o deshabilite el complemento de registro de mensajes |
|
|
|
El tamaño de la cola de conectores que indica el número de entradas que pueden ser almacenadas en búfer. |
|
|
|
Agrupa las entradas del registro de mensajes y las envía de forma consolidada. DataEnvelopes, agrupados por su respectivo contexto de procesamiento |
|
|
|
El número de entradas del registro de mensajes que se deben almacenar en búfer antes de consolidar por contexto de procesamiento. |
|
una duración como |
|
El tiempo de espera antes de consolidar las entradas del registro de mensajes procesando el contexto cuando el búfer no está lleno. |
|
|
|
Define si los fallos deben ser propagados al llamador al intentar exportar datos. |
Configuración propagate-transport-errors to true aplicará presión de retroceso en cada registro de mensaje hasta que se envíe, hasta send-buffer-timeout. Esto asegura que los registros de mensajes nunca se pierdan, a costa de añadir esa latencia al procesamiento de transacciones en cada registro de mensaje que se envía como parte de la ejecución del flujo.
|
Model Exporter
El Model Exporter recoge toda la metadata del flujo de procesos de la aplicación de flujo de procesamiento cuando se inicia y publica la metadata en un solo sobre.
Puede haber muchas aplicaciones desplegadas que contengan el mismo flujo de procesos, y al iniciar/reiniciar la aplicación, todas publicarán los mismos metadatos del flujo de procesos. Esto es esperado, y los duplicados deben ser gestionados más adelante.
Sobrescribe el identificador único para los metadatos del flujo de proceso, que se compone del nombre del flujo de proceso y su identificador.
Al menos una entrega. El sobre se publica inmediatamente cuando la aplicación se inicia, incluyendo en reinicios.
Cómo Utilizar
Si no utiliza un pom inicial, puede utilizar este complemento 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 una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilite o deshabilite el complemento exportador de modelos. |
Journal Processor
El módulo del procesador de revistas registra un com.iconsolutions.ipf.platform.read.processor. EventProcessor instancia que consume todos los eventos persistidos del diario.
Extrae MDS objetos y PDS objetos de cada evento y los agrupa en un solo sobre.
Al menos una entrega. El sobre se publica inmediatamente.
Cómo Utilizar
Si no utiliza un pom inicial, puede utilizar este complemento 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 una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilite o deshabilite el complemento del procesador de registros. |
Direct Data Exporter
El módulo de exportador de datos directo proporciona la capacidad de publicar directamente estructuras de datos como (MDS, PDS, etc.) al transporte configurado.
Entrega como máximo una vez. El exportador puede configurarse para ser de tipo "fire-and-forget" o, opcionalmente, propagar errores del transporte de vuelta al llamador. Los datos exportados pueden ser almacenados en búfer, donde múltiples estructuras de datos con el mismo contexto de procesamiento se consolidan en uno solo. DataEnvelope antes de ser egresado.
|
Al utilizar Kafka conectores de transporte, a Direct Data Exporter el búfer solo puede ser configurado cuando el Kafka tema para Estructuras de Datos y Message Logs son los mismos. Vea el guía de cómo para más información sobre la configuración IPF Processing Data para exportar a múltiples Kafka Temas. |
Cómo Utilizar
Puede utilizar este complemento 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 una dependencia, pero puede ser configurado explícitamente con:
| Propiedad | Valores | Valor por defecto | Descripción |
|---|---|---|---|
|
|
|
Habilite o deshabilite el complemento de registro de mensajes |
|
|
|
El tamaño de la cola de conectores que indica el número de entradas que pueden ser almacenadas en búfer. |
|
|
|
Agrupa las entradas y las envía de forma consolidada. DataEnvelopes, agrupados por su respectivo contexto de procesamiento. |
|
|
|
El número de entradas a almacenar en búfer antes de consolidar por contexto de procesamiento. |
|
una duración como |
|
El tiempo de espera antes de consolidar entradas procesando el contexto cuando el búfer no está lleno. |
|
|
|
Define si los fallos deben ser propagados al llamador al intentar exportar datos. |
Configuración propagate-transport-errors to true aplicará presión de retroceso en cada exportación de datos hasta que se envíe, 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 de datos que se envía como parte de la ejecución del flujo.
|
MDS Exportador
El IpfProcessingDataEgressMdsExporter la interfaz se utiliza para exportar MDS estructuras de datos al transporte configurado.
The MDS las estructuras de datos están envueltas por un MdsWrapper instancia que le permite proporcionar lo deseado id y parentId para el nivel superior MDS objeto a exportar.
Si el id y parentId no se proporcionan en el MdsWrapper instancia, la implementación predeterminada generará un único id(y si corresponde,parentId) para el exportado MDS objetos
PDS Exportador
El IpfProcessingDataEgressPdsExporter la interfaz se utiliza para exportar PDS estructuras de datos al transporte configurado.
A name puede ser especificado como un identificador único para el PDS objeto a exportar.
Si un name no se proporciona, la implementación predeterminada generará un name para el exportado PDS objeto utilizando el PdsObject tipo.
MessageLog Exportador
El IpfProcessingDataEgressMessageLogExporter la interfaz se utiliza para exportar Message Log estructuras de datos al transporte configurado.
El exportador devuelve un uniqueId y reference.uniqueId es un identificador para el exportado Message Log el objeto, se genera 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 empresariales específicos para el procesamiento
Al extraer objetos de proceso de domain events, el procesador de diarios busca elementos de datos comerciales predefinidos.
Si se encuentran alguno de los siguientes elementos entre un domain event las entradas de datos empresariales con la categoría PAYMENT_PROCESSING, se tratarán como metadatos de procesamiento relacionados con la unidad de trabajo del evento.
-
PaymentType, representando el tipo de pago según lo 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 Mecanismo de Compensación y Liquidación que fue seleccionado como parte del procesamiento de pagos. -
Priority, representando la prioridad del pago relacionado con el SLA, tanto el valor de prioridad (como el comportamiento subsiguiente) es configurable por solución de cliente IPF. -
TimeZone, que representa el desplazamiento para la zona horaria del sistema de procesamiento. -
RelatedUnitOfWork, que es el unitOfWorkId de una unidad de trabajo relacionada, por ejemplo, el pago original que se está recuperando, o el lote principal del pago.
Métricas
Las siguientes métricas serán reportadas por el procesador de la revista:
-
ipf_processing_data_journal_latency, que registra la duración entre el momento en que un domain event ha sido creado y el tiempo que ha sido enviado a ODS; las duraciones serán sensibles a la desviación temporal entre los servidores, por lo que deben ser tratadas únicamente como estimaciones.