Salida Processing Data
Resumen
El módulo de salida contiene:
-
Transportes que pueden publicar IPF Processing Data sobres, p. ej.kafka or http puntos finales
-
Plugins que traducen datos de IPF en el común IPF Processing Data formato, compuesto por los tipos conocidos,MDS, PDS, domain events,message logs,system events, etc.
-
Poms iniciales con un conjunto predeterminado de complementos
Modelo de Datos &Versioning
El modelo de datos que se utiliza 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.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 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 kafka egreso, cualquier cosa que no sea |
El comportamiento predeterminado es entregar todos IPF Processing Data tipos a los IPF_PROCESSING_DATA tema.
Es posible entregar diferentes data type s a diferentes temas, por ejemplo, cuando un event conteniendo un pacs. 008 MDS objeto, y un JourneyType PDS el objeto es producido-cada uno de esos tipos (event,MDS, PDS) podría viajar junto en un solo sobre a un solo tema, o en tres sobres separados a tres temas diferentes.
El predeterminado kafka la configuración se encuentra bajo la ruta de configuración ipf.processing-data.egress.kafka, p. ej.
| Propiedad | Valor Predeterminado | Descripción |
|---|---|---|
|
|
El predeterminado Kafka tema al que todos ipf processing data se publica cuando no hay adicionales 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 el http salida, cualquier cosa que no sea |
|
|
El anfitrión de la http ipf processing data punto de entrada de ingreso |
|
|
El puerto de la http ipf processing data punto de entrada de ingreso |
El http egress 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.
Plugins
Se proporcionan complementos para aplicaciones de flujo de procesamiento IPF que producen IPF processing data. 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 system event exporter el módulo registra una instancia de com.iconsolutions.payments.systemevents.api. EventProcessor que publicará system events al transporte configurado.
Entrega como máximo una vez. El system event exporter puede configurarse para ser de tipo "fire-and-forget" o, opcionalmente, propagar errores del transporte de vuelta al llamador. System events puede ser almacenado 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 en el system event exporter nivel, y segundo en la implementación de ipf-processing-data.
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 sistema-event-plugin de exportación |
|
|
|
Buffers system events y los envía como consolidados DataEnvelopes, agrupados por su respectivo contexto de procesamiento. |
|
|
|
El número de system events para almacenar en búfer antes de consolidar procesando el contexto |
|
una duración como |
|
El tiempo de espera antes de consolidar system events 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 event hasta que se envíe, hasta send-buffer-timeout. Esto asegura events nunca se pierden, a costa de añadir esa latencia al procesamiento de transacciones en cada uno de los event que se envía como parte de la ejecución del flujo.
|
Message Logger
El message logger el módulo registra una instancia de com.iconsolutions.ipf.core.messagelogger. CheckpointAwareMessageLogger que publicará message logs al transporte configurado. Esto permite conectores que utilizan esto MessageLogger para mantener la relación causal entre "pseudo-events " a través de " Punto de control.
Entrega como máximo una vez. El message logger puede configurarse 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. |
|
|
|
Buffers message log ingresa y los envía como consolidados DataEnvelopes, agrupados por su respectivo contexto de procesamiento |
|
|
|
El número de message log entradas al búfer antes de consolidar procesando el contexto |
|
una duración como |
|
El tiempo de espera antes de consolidar message log 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 message log hasta que se envíe, hasta send-buffer-timeout. Esto asegura message logs nunca se pierden, a costa de añadir esa latencia al procesamiento de transacciones en cada uno de los message log que se envía como parte de la ejecución del flujo.
|
Model Exporter
El Model Exporter recoge *todas*process flow metadatos del flujo de procesamiento de la aplicación cuando se inicia y publica los metadatos en un solo sobre.
Puede haber muchas aplicaciones desplegadas que contengan el mismo process flow, y al iniciar la aplicación/restart todos publicarán lo mismo process flow metadatos. Esto es esperado, y los duplicados deben ser gestionados más adelante.
Sobrescribe el id único para process flow metadata, que está compuesto por el process flow nombre, y su identificador.
Entrega al menos una vez. El sobre se publica inmediatamente cuando la aplicación se inicia, incluyendo en restarts.
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-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 model exporter plugin |
Journal Processor
The journal processor el módulo registra un com.iconsolutions.ipf.platform.read.processor. EventProcessor instancia que consume toda la persistencia events del diario.
Extrae MDS objetos y PDS objetos de cada event, 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 usar 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 journal processor plugin |
Direct Data Exporter
El direct data exporter el módulo 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.
|
Cuando utilice Kafka connector transport s, 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.
El 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 tipo PdsObject.
Exportador de Registros de Mensajes
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 es aplicable.
Business data elementos específicos para el procesamiento
Al extraer process objects from domain events, el journal processor busca predefinido business data elementos.
Si se encuentran alguno de los siguientes elementos entre un domain event’s business data entradas con la categoría PAYMENT_PROCESSING, se tratarán como metadatos de procesamiento relacionados con el event’s unit of work.
-
PaymentType, representando el tipo de pago según lo definido por el cliente en el IPF Solution 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 un relacionado unit of work, 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 journal processor:
-
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.