Core - Cambios y Soluciones

Esta página cubre los principales cambios y correcciones proporcionados en la versión IPF-2025.2.0.

MongoDB

Cambiado

Esta versión añade soporte para MongoDB Cifrado a Nivel de Campo del Lado del Cliente (CSFLE). Para más detalles, consulte Mongo DB Inicial.

Conector

Cambiado

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

  • Los mensajes solo intentan cada transporte una vez antes de fallar. Anteriormente, intentaría cada transporte hasta que se abrieran todos los interruptores automáticos.

Fijo

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

  • DeadLetterAppender el tipo de retorno de la etapa de interfaz cambiado de CompletableFuture<Void> to CompletionStage<Void>

Procesador de Entradas de Pago (renombrado de Liberador de Pagos)

El Liberador de Pagos se ha convertido en un Procesador de Entradas de Pago genérico, capaz de hacer más que simplemente liberar entradas de pago para la ejecución. Aparte de la liberación resiliente de instrucciones y transacciones individuales para la ejecución que ya estaba soportada, ahora es posible cancelar todas las transacciones de una instrucción programada para la ejecución.

Agregado

  • Nuevo módulo: pago-scheduler-adaptador-kafka. Adaptador para el scheduler-received-connector-kafka. Permite el consumo de Kafka mensajes publicados por el Persistent Scheduler aplicaciones que utilizan el scheduler-módulo external-trigger-kafka. El consumo de este mensaje activa el prepareInstruction or processTransaction(renombrado de releaseTransaction) métodos de la PaymentEntriesProcessor(renombrado de PaymentReleaser), con configuración predeterminada que puede ser sobrescrita. Los detalles se pueden encontrar en Cómo activar el Releaser desde Persistent Scheduler a través de Kafka

  • La aplicación actual de las acciones de procesamiento de LIBERACIÓN y/o CANCELACIÓN a las Entradas de Pago se realiza a través de ProcessingStrategy implementaciones de interfaz. Para que el Procesador de Entradas de Pago pueda procesar una Acción (LIBERAR, CANCELAR o cualquier custom uno), debe proporcionar un bean implementando el ProcessingStrategy interfaz. También debe proporcionar implementaciones de ProcessingRequestCreator y RequestProcessor interfaces, y úselas en su ProcessingStrategy implementación.

Cambiado

Múltiples cambios en el proceso de hacer genérico el Liberador de Pagos:

  • ipf.core.payment-releaser la ruta raíz de configuración ha sido cambiada a ipf.core.payment-entry-processor

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

  • Interfaces y clases renombradas:

    • PaymentReleaser interfaz renombrada a PaymentEntriesProcessor

    • AkkaPaymentReleaser clase renombrada a AkkaPaymentEntriesProcessor

    • ReleaserExecutor clase renombrada a InstructionExecutorActor

    • PaymentRequestCreator interfaz renombrada a ProcessingRequestCreator

    • PaymentRequestSender interfaz renombrada a RequestProcessor

    • ReleaserStore interfaz renombrada a ExecutionInfoStore

    • MongoReleaserStore clase renombrada a MongoExecutionInfoStore

Capacidad para proporcionar información adicional para el servicio de ejecución posterior

Incluye los siguientes cambios importantes: PaymentEntriesProcessor(renombrado de PaymentReleaser) las firmas de métodos de interfaz actualizadas: * the processInstruction(renombrado de releaseInstruction) y processTransaction(renombrado de releaseTransaction) el método tiene un argumento adicional de SupportingContext para aceptar datos de soporte para la ejecución del pago Open APIespecificación actualizada, generando actualizada Java interfaces y, por lo tanto, afectando el PaymentReleaserController firmas de método * el prepareReleaseInstruction el método ya no acepta Mono<SupportingBusinessDataMapForPrepareOperation> como argumento * el processInstruction(renombrado de releaseInstruction) el método ya no acepta Mono<SupportingBusinessDataMapForReleaseOperation> como argumento * the processInstruction(renombrado de releaseInstruction) el método toma Mono<SupportingContext> como un argumento de método * the processTransaction(renombrado de releaseTransaction) el método toma Mono<SupportingContext> como un argumento de método Open APIespecificación actualizada, requiriendo actualizaciones a la ClientPort interfaces para acomodar: * el PrepareInstructionClientPort los métodos de interfaz ya no aceptan SupportingBusinessDataMapForPrepareOperation como argumento * el ReleaseInstructionClientPort Los métodos de la interfaz ya no aceptan el SupportingBusinessDataMapForReleaseOperation como argumento * el ReleaseInstructionClientPort los métodos de la interfaz pueden tomar SupportingContext como argumento * el ReleaseTransactionClientPort los métodos de la interfaz pueden tomar SupportingContext como argumento OpenAPIlos cambios en la especificación significan ProcessingContext ya no se requiere en el cuerpo de la solicitud para: * POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/preparar-lanzamiento * POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/release ProcessingRequestCreator(renombrado de PaymentRequestCreator) toma en SupportingContext, permitiendo que la Solicitud de Pago construida incorpore datos de soporte antes de ser enviada al servicio de ejecución * Cambie a la firma del método getPaymentInitiation() in PaymentDataSource; ahora devuelve Mono<Optional<INIT>> * initationAggregatorFunction, suministrado a BasePaymentWarehouseDataSource es ahora opcional bean, ya que no todos los usuarios estarán obligados a proporcionar una función de iniciación.

IPF Persistent Scheduler

Añadido

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

  • Nuevo módulo:scheduler-received-connector-kafka. Permite la recepción de `ExternalTriggerCommand’s a través de kafka. Este módulo debe ser incorporado como una dependencia en los sistemas receptores.

  • Soporte de Scheduler Floclient para el envío y recepción de lanzamientos programados ejecutados a través de un medio específico.ExternalSchedulingHelper que activa el dominio y proporciona un comando de entrada de 'completado' cuando el ExternalSchedulingCommand se ejecuta.

Cambiado

  • Breaking: el SchedulerConnectorInterface--scheduler-client-connector-http maven artefacto) utiliza HTTP API modelos como argumentos de método, en oposición a los modelos 'núcleo'.

  • Ruptura:HTTP API toma el ExternalTriggerCommand objeto en la carga útil anidada para scheduling nuevos trabajos

  • Scheduler Floclient: renombrado PaymentAsyncScheduleCompletedCommand to SchedulePaymentReleaseCommand

Human Task Manager

Cambiado

Anteriormente, el Task Manager flujo emitió un adicional domain event,Registered, en respuesta a la Flow Initiated domain event. No hay cambios en los estados o en el camino de ejecución del flujo. La única modificación es que el Registered domain event ha sido eliminado, y el Flow Initiated domain event ha sido renombrado a Registered. Como resultado, las tareas recién creadas ya no tendrán el Flow Initiated domain event almacenado en la base de datos.

Este cambio no afecta la funcionalidad de la aplicación, ya que se ha proporcionado un adaptador de eventos apropiado. Si algún consumidor estaba dependiendo de la Flow Initiated domain event, pueden utilizar de manera segura el Registered domain event en su lugar, ya que contiene los mismos datos comerciales.

Serialización

Cambiado

Corrige un error donde la serialización IPF perdería ceros a la derecha de los decimales al deserializar en un JsonNode instancia, p. ej. el decimal en {"number": 123.450} se convertiría 123.45, y el decimal en {"number": 123.000} se convertiría 123.

Test Framework

Cambiado

El marco de pruebas ahora se ejecuta exclusivamente en JUnit 5 (Júpiter). Puede enfrentar fallos de compilación si utiliza JUnit-4-específico anotaciones o clases de afirmación. Consulte migración para pasos de migración más específicos.