Core - Cambios y Soluciones

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

Nuevo

IPF Inicio Común

Core

Conectores y Transportes

  • System events para reflejar los estados de los conectores (consulte System Events)

    • ConnectorStarted

    • ConnectorAvailable

    • ConnectorStopped

    • ConnectorShutdownInitiated

    • ConnectorUnavailable

  • System event 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 cache in bank-filtering-parent. Por defecto,cache está habilitado, 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

  • Reformuló cómo se determina la salud del conector con una nueva salud del conector.event procesador utilizando la salud del conector y del transporte system events

    • Tener al menos un transporte UP con un interruptor en un CLOSED state resultará en un informe de conector UP

  • Se añadió una nueva propiedad de configuración.timestamp-archived-and-failed-files que se utiliza en LocalDirectoryConnectorTransport. Cuando se establece en true, archivos movidos a /archive o /failed los directorios se marcan automáticamente 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:

  • Especificación OpenAPI 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 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):

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

    • the 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 java cambios en la interfaz:

    • 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)

  • the 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 java las firmas de métodos de interfaz actualizadas:

    • el 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 llamador, 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 la implementación de SerializationHelper. La configuración Jackson La visibilidad de JsonFactory 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) están 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