Documentation for a newer release is available. View Latest

Núcleo - Cambios y Correcciones

Esta página cubre los cambios y correcciones del núcleo incluidos en la versión IPF-2025.2.0.

MongoDB

Cambiado

Esta versión añade soporte para MongoDB Cifrado de Campo a Nivel de Cliente (CSFLE). Para más detalles vea Inicio con Mongo DB.

Conector

Cambiado

  • El tipo de excepción del transporte ha cambiado de IllegalStateException a NoAvailableTransportException, que extiende IllegalStateException.

  • Los mensajes ahora intentan cada transporte solo una vez antes de fallar. Anteriormente probaban todos los transportes hasta que todos los disyuntores se abrieran.

Corregido

  • RequestReplySendConnector ahora lanza una excepción, en lugar de devolver la respuesta al llamador, cuando la validación de bean de respuesta está habilitada y la(s) verificación(es) especificada(s) por el validador de bean de respuesta proporcionado falla(n).

  • El tipo de retorno de la etapa de la interfaz DeadLetterAppender cambió de CompletableFuture<Void> a CompletionStage<Void>

Procesador de Entradas de Pago (renombrado desde Payment Releaser)

Payment Releaser se ha convertido en un Procesador Genérico de Entradas de Pago, capaz de hacer más que simplemente liberar entradas de pago para la ejecución. Además del lanzamiento resiliente de instrucciones y transacciones individuales para la ejecución, ahora es posible cancelar todas las transacciones de una instrucción programada para la ejecución.

Añadido

  • Nuevo módulo: payment-scheduler-adaptor-kafka. Adaptador para scheduler-received-connector-kafka. Permite el consumo de mensajes de Kafka publicados por las aplicaciones Persistent Scheduler que usan el módulo scheduler-external-trigger-kafka. El consumo de este mensaje dispara los métodos prepareInstruction o processTransaction (renombrado de releaseTransaction) del PaymentEntriesProcessor (renombrado de PaymentReleaser), con configuración predeterminada sobreescribible. Los detalles se pueden encontrar en Cómo activar el Releaser desde Persistent Scheduler vía Kafka

  • La aplicación real de acciones de RELEASE y/o CANCEL a las Entradas de Pago se realiza a través de implementaciones de la interfaz ProcessingStrategy. Para que el Procesador de Entradas de Pago pueda procesar una Acción (RELEASE, CANCEL o cualquier personalizada), debe proporcionar un bean que implemente la interfaz ProcessingStrategy. También debe proporcionar implementaciones de las interfaces ProcessingRequestCreator y RequestProcessor, y usarlas en su implementación de ProcessingStrategy.

Cambiado

Múltiples cambios en el proceso de hacer genérico Payment Releaser:

  • La ruta raíz de configuración ipf.core.payment-releaser cambió a ipf.core.payment-entry-processor

  • La colección de base de datos releaseExecutionInfos fue renombrada a executionInfos

  • Interfaces y clases renombradas:

    • La interfaz PaymentReleaser se renombró a PaymentEntriesProcessor

    • La clase AkkaPaymentReleaser se renombró a AkkaPaymentEntriesProcessor

    • La clase ReleaserExecutor se renombró a InstructionExecutorActor

    • La interfaz PaymentRequestCreator se renombró a ProcessingRequestCreator

    • La interfaz PaymentRequestSender se renombró a RequestProcessor

    • La interfaz ReleaserStore se renombró a ExecutionInfoStore

    • La clase MongoReleaserStore se renombró a MongoExecutionInfoStore

Capacidad de pasar información adicional para el servicio de ejecución downstream. Incluye los siguientes cambios incompatibles:

  • Se actualizaron las firmas de métodos de la interfaz PaymentEntriesProcessor (renombrada de PaymentReleaser):

    • los métodos processInstruction (renombrado de releaseInstruction) y processTransaction (renombrado de releaseTransaction) ahora tienen un argumento adicional SupportingContext para aceptar datos de apoyo para la ejecución del pago

  • Se actualizó la especificación OpenAPI, generando interfaces Java actualizadas y afectando por lo tanto las firmas de métodos de PaymentReleaserController

    • el método prepareReleaseInstruction ya no toma Mono<SupportingBusinessDataMapForPrepareOperation> como argumento

    • el método processInstruction (renombrado de releaseInstruction) ya no toma Mono<SupportingBusinessDataMapForReleaseOperation> como argumento

    • el método processInstruction (renombrado de releaseInstruction) toma Mono<SupportingContext> como argumento

    • el método processTransaction (renombrado de releaseTransaction) toma Mono<SupportingContext> como argumento

  • Los cambios de la especificación OpenAPI requieren actualizaciones a las interfaces ClientPort para acomodar:

    • los métodos de la interfaz PrepareInstructionClientPort ya no toman SupportingBusinessDataMapForPrepareOperation como argumento

    • los métodos de la interfaz ReleaseInstructionClientPort ya no toman SupportingBusinessDataMapForReleaseOperation como argumento

    • los métodos de la interfaz ReleaseInstructionClientPort pueden tomar SupportingContext como argumento

    • los métodos de la interfaz ReleaseTransactionClientPort pueden tomar SupportingContext como argumento

  • Los cambios de OpenAPI significan que ProcessingContext ya no es requerido en el cuerpo para:

    • POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/prepare-release

    • POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/release

  • ProcessingRequestCreator (renombrado de PaymentRequestCreator) recibe SupportingContext, permitiendo que la Solicitud de Pago construida incorpore datos de apoyo antes de pasarse al servicio de ejecución

    • Cambio a la firma del método getPaymentInitiation() en PaymentDataSource; ahora devuelve Mono<Optional<INIT>>

    • initationAggregatorFunction, suministrada a BasePaymentWarehouseDataSource ahora es un bean opcional, ya que no todos los usuarios necesitarán suministrar una función de iniciación.

Programador Persistente de IPF

Añadido

  • Nuevo módulo: scheduler-external-trigger-kafka. Permite enviar un ExternalTriggerCommand (implementación de SchedulingCommand) a través de un Kafka SendConnector para ser procesado por otro servicio en la fecha-hora programada.

  • Nuevo módulo: scheduler-received-connector-kafka. Permite la recepción de ExternalTriggerCommand vía Kafka. Este módulo debe incluirse como dependencia en los sistemas receptores.

  • Soporte en el Floclient del Programador para enviar/recibir ejecuciones programadas mediante un ExternalSchedulingHelper específico que dispara el dominio y proporciona un comando de entrada de "finalización" cuando se ejecuta el ExternalSchedulingCommand.

Cambiado

  • Incompatible: la SchedulerConnectorInterface (del artefacto maven scheduler-client-connector-http) usa modelos de la API HTTP como argumentos de métodos, en lugar de modelos "core".

  • Incompatible: la API HTTP recibe el objeto ExternalTriggerCommand en el payload anidado para programar nuevos trabajos

  • Floclient del Programador: PaymentAsyncScheduleCompletedCommand renombrado a SchedulePaymentReleaseCommand

Gestor de Tareas Humanas

Cambiado

Anteriormente, el flujo del Gestor de Tareas emitía un evento de dominio adicional, Registered, en respuesta al evento de dominio Flow Initiated. No hay cambios en los estados del flujo ni en su camino de ejecución. La única modificación es que se ha eliminado el evento de dominio Registered, y el evento de dominio Flow Initiated ha sido renombrado a Registered. Como resultado, las tareas recién creadas ya no tendrán el evento de dominio Flow Initiated almacenado en la base de datos.

NOTA: Este cambio no afecta la funcionalidad de la aplicación, ya que se ha proporcionado un adaptador de eventos apropiado. Si algún consumidor dependía del evento de dominio Flow Initiated, puede usar con seguridad el evento de dominio Registered en su lugar, ya que contiene los mismos datos de negocio.

Serialización

Cambiado

Corrige un error por el cual la Serialización de IPF perdía ceros a la derecha de decimales al deserializar en una instancia de JsonNode, por ejemplo el decimal en {"number": 123.450} se convertía en 123.45, y el decimal en {"number": 123.000} se convertía en 123.

Marco de Pruebas

Cambiado

El marco de pruebas ahora se ejecuta exclusivamente en JUnit 5 (Jupiter). Podría encontrar fallos de compilación si usa anotaciones o clases de aserción específicas de JUnit 4. Vea migración para pasos más específicos de migración.