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 a 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 instructions y transacciones individuales para la ejecución que ya fue soportada, ahora es posible cancelar todas las transacciones de una instrucción.scheduled para la ejecución.

Añadido

  • Nuevo módulo: pago-scheduler-adaptador-kafka. Adaptador para el scheduler-recibido-connector-kafka. Permite el consumo de Kafka mensajes publicados por el Persistent Scheduler aplicaciones que utilizan el scheduler-disparador-kafka módulo. 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 vía 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: * el processInstruction(renombrado de releaseInstruction) y processTransaction(renombrado de releaseTransaction El método tiene un argumento adicional de SupportingContext para aceptar datos de apoyo para la ejecución del pago. Especificación OpenAPI actualizada, generando actualización Java interfaces y, por lo tanto, afectando el PaymentReleaserController firmas de método * the 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 * el processInstruction(renombrado de releaseInstruction) el método toma Mono<SupportingContext> como un argumento de método * el processTransaction(renombrado de releaseTransaction) el método toma Mono<SupportingContext> como un argumento de método Especificación OpenAPI actualizada, requiriendo actualizaciones a las interfaces ClientPort para acomodar: * the PrepareInstructionClientPort los métodos de interfaz ya no aceptan SupportingBusinessDataMapForPrepareOperation como argumento * el ReleaseInstructionClientPort métodos de 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 Los cambios en la especificación OpenAPI significan que ProcessingContext ya no es necesario 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

Agregado

  • Nuevo módulo:scheduler-disparador-kafka. Permite un ExternalTriggerCommand(implementación de SchedulingCommand) para ser enviado a través de un Kafka SendConnector ser procesado por otro servicio en el scheduled fecha-hora.

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

  • Programador Floclient soporte para enviar/recibir ejecutado scheduled-liberaciones a través de medios de un 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, a diferencia de 'core' modelos.

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

  • Programador 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 la ruta de ejecución del flujo. La única modificación es que la 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 un apropiado event se ha proporcionado un adaptador. 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 lo mismo business data.

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 en 123.

Test Framework

Cambiado

El test framework ahora funciona 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.