Core - Cambios y Soluciones

Esta página detalla todo lo necesario para comenzar con la versión IPF 2025.3.0.

Nuevo

IPF Common Starter

Core

Conectores y Transportes

  • Eventos del sistema para reflejar los estados de los conectores (consulte System Event Catalogue):

    • ConnectorStarted

    • ConnectorAvailable

    • ConnectorStopped

    • ConnectorShutdownInitiated

    • ConnectorUnavailable

  • Evento del sistema para distinguir entre un transporte disponible (existente TransportAvailable) y cuando ha comenzado a procesar (nuevo TransportStarted)

  • Se añadió la capacidad de enmascarar la configuración sensible al utilizar el api-de-operaciones-de-conectores, vea Operaciones del Conector

Filtrado Bancario Cache

  • Configuración añadida que permite deshabilitar la caché en bank-filtering-parent. Por defecto, la caché está habilitada, consulte Configuración de Caché.

Fijo

Cambiado

Conectores

  • La creación del índice de correlación ahora admite la especificación del custom la configuración del quórum de confirmación, se puede realizar proporcionando un valor para ipf.connector.correlation.commit-quorum propiedad

  • Se ha reestructurado la forma en que se determina la salud del conector con un nuevo procesador de eventos de salud del conector que utiliza eventos del sistema de salud del conector y del transporte.

    • Tener al menos un transporte UP con un interruptor en un CLOSED el estado resultará en un informe del conector UP

  • Se ha añadido una nueva propiedad de configuración.timestamp-archived-and-failed-files que se utiliza en LocalDirectoryConnectorTransport. Cuando se establece en true, los archivos movidos a la carpeta /archive o /failed son automáticamente sellados con una marca de tiempo (es decir,file_20251020_143530.xml). El valor predeterminado es false para preservar el comportamiento existente.

Procesador de Entradas de Pago (anteriormente Liberador de Pagos)

Se realizaron los siguientes cambios para que el Procesador de Entradas de Pagos pueda hacer coincidir los pagos almacenados con los suministrados.ProcessingEntity:

  • Open APIespecificación actualizada:

    • Todo HTTP las solicitudes pueden incluir opcionalmente un ProcessingEntity en el cuerpo de la solicitud. Habilita la coincidencia de pagos almacenados contra el ProcessingEntity campos. Si el ProcessingEntity si no se proporciona en el cuerpo de la solicitud, entonces no se lleva a cabo ninguna lógica de coincidencia.

    • Todo HTTP los cuerpos de solicitud son ahora opcionales

  • Interfaces de Java implementadas por el PaymentReleaserController actualizado (generado a partir del actualizado OpenAPI especificación):

    • el prepareReleaseInstruction el método toma Mono<PrepareReleaseInstructionRequest> como argumento

    • el releaseInstruction y releaseTransaction métodos ya no toman Mono<SupportingContext> como argumento

    • el releaseInstruction y releaseTransaction métodos toman Mono<ReleaseRequest> como un argumento de método

  • PaymentEntriesProcessor cambios en la interfaz de java:

    • el prepareInstruction el método toma ProcessingEntity como un argumento de método (opcional)

    • el processInstruction el método toma ProcessingEntity como un argumento de método (opcional)

    • the processTransaction el método toma ProcessingEntity como un argumento de método (opcional)

  • el ExecutionInfo java objeto (devuelto por processInstruction y processTransaction métodos en el PaymentEntriesProcessor la interfaz) ha sido refactorizada:

    • introducción de PaymentHandlingInfo paymentHandlingInfo campo

    • movimiento del ProcessingActionType actionType y SupportingContext supportingData campos de ExecutionInfo objeto en PaymentHandlingInfo objeto.

    • adición de ProcessingEntity processingEntity campo a PaymentHandlingInfo objeto.

  • PaymentDataSource se actualizaron las firmas de métodos de la interfaz java:

    • the getPaymentInitiation,getPaymentInstruction,getPaymentTransactions y getPaymentTransaction métodos todos requerían un (nullable)ProcessingEntity argumento del método

  • el BasePaymentWarehouseDataSource la lógica de clase para devolver una Entrada de Pago ahora puede coincidir con ProcessingEntity, con la lógica como sigue:

    • si un ProcessingEntity es proporcionado por el llamante, entonces el ProcessingEntity en la Entrada de Pago debe coincidir para ser devuelto.

    • si un ProcessingEntity no es proporcionado por el llamante, entonces el ProcessingEntity en la Entrada de Pago no se toma en consideración.

IPF Common Starter

Core

  • ConnectorsHealthIndicator ahora utiliza un agregado de ConnectorHealth en lugar de TransportHealth

Administrador de Archivos

  • FileWriter API write y reactiveWrite métodos ahora devuelven un envuelto WriteResponse objeto que contiene un version campo de cadena.

    • Para el Administrador de Archivos S3, el version representa el versionId del archivo S3 cargado si el bucket S3 tiene Versioning habilitado. Si el bucket S3 no tiene Versioning habilitado, el version el campo será nulo.

    • Para el Administrador de Archivos Local, el version el campo será nulo.

Cambios Importantes

Serialización

  • El IPF Akka el serializador ha sido actualizado para alinearse con el SerializationHelper implementación. La configurada Jackson JsonFactory La visibilidad ha cambiado de ANY to DEFAULT.

    • Ver com.fasterxml.jackson.annotation. PropertyAccessor y fasterxml.github.io/jackson-annotations/javadoc/2.5/com/fasterxml/jackson/annotation/JsonAutoDetect. Visibility.html[com.fasterxml.jackson.annotation. JsonAutoDetect. Visibility] Valores de enumeración para más información.

    • La configuración anterior de ANY significaba que todos los campos (incluidos los privados y protegidos) son serializados.

    • En particular, esto puede afectar Java campos donde uno de los primeros dos caracteres es mayúscula (por ejemplo,aFieldName or BFieldName).

      • Con FIELD = DEFAULT configurado, los campos de ejemplo anteriores se serializan a afieldName y bfieldName respectivamente, lo que puede causar problemas durante la deserialización.

    • Esto es un conocido Problema de Jackson(fijo en Jackson 3.0), donde se aconseja utilizar el @JsonProperty anotación para estos campos.

    • Si esa no es una solución ideal, puede revertir al uso de la configuración anterior configurando:

akka.serialization.jackson.ipf-akka-serializer.visibility.FIELD = ANY

Conectores

Transport Message Encabezados

  • Obsoleto ProcessingContext Las claves de encabezado han sido eliminadas.

  • Obsoleto MessageHeaders.fromProcessingContext() y MessageHeaders.toProcessingContext() se han eliminado los métodos

Ver Notas de migración para obtener detalles adicionales.

Creación del índice de correlación

  • Nombre de la propiedad de configuración ipf.correlation.index-creation.enabled(para habilitar/deshabilitar la creación automática de un índice de correlación) se cambia a ipf.connector.correlation.create-indexes

  • Nombre de la propiedad de configuración ipf.connector.correlation-timestamp-field-name(el nombre de la columna de marca de tiempo de creación) se cambia a ipf.connector.correlation.timestamp-field-name

  • Nombre de la propiedad de configuración ipf.connector.correlation-expiry(el nombre de la columna de marca de tiempo de creación) se cambia a ipf.connector.correlation.time-to-live

Contexto de Procesamiento

  • Claves de encabezado de mensaje en desuso uowId,requestId,processingEntity y associationId se eliminan a favor de las claves definidas en ContextPropagationSettings clase. Ver Notas de migración para obtener detalles adicionales.

API

  • ConnectorHealth la clase ya no contiene una lista de TransportHealth, ahora acepta un String para el nombre del conector

Administrador de Archivos

  • FileWriter API cambios importantes a continuación. Ver API Referencia para obtener detalles sobre el WriteResponse objeto.

    • write el método devuelve CompletionStage<WriteResponse>, anteriormente esto devolvía CompletionStage<Void>

    • reactiveWrite el método devuelve Mono<WriteResponse>, anteriormente esto devolvía Mono<Void>

Kafka Message Logger