Pasos de migración para IPF-2025.2.0

Esta página cubre los pasos de migración requeridos para la versión 2025.2.0 de IPF.

Migración para Conectores

Cualquier clase que haya implementado previamente com.iconsolutions.ipf.core.connector.receive.deadletter. DeadletterAppender tendrá un fallo de compilación. Para solucionarlo, cambie el tipo de retorno del append método de CompletableFuture<Void> a CompletionStage<Void>.

Migración para Kafka Conectores

akka.kafka.consumer.restart-settings`ahora se establece como predeterminado a `ipf.connector.default-transport-settings.restart-settings. Desde que todo Kafka la configuración predeterminada, especificando que los ajustes del consumidor ahora heredan de esta configuración.restart-settings cuando se declara un Kafka el transporte de consumidores ya no es un requisito necesario.

Si solía establecer su restart-settings to akka.kafka.consumer.health-check-settings.restart-settings or ipf.connector.default-transport-settings.restart-settings, siéntase libre de eliminar ahora esas líneas de su HOCON.

Migración para HTTP Conectores

El interno com.iconsolutions.ipf.core.connector.transport. HttpErrors. HttpStatusErrorException las excepciones ahora tienen una encapsulación más fuerte, y sus constructores ya no pueden ser accedidos públicamente. Si necesita crear una instancia para sus propósitos de prueba, por favor utilice com.iconsolutions.ipf.core.connector.transport. HttpErrors#from(StatusCode,TransportMessage).

Migración para Bulker

Se recomienda descontinuar el uso de las siguientes dependencias:

  • ipf-bulker-output-stream-api-ipf-bulker-output-stream-local-ipf-bulker-output-stream-s3

ipf-file-manager`ahora proporciona funcionalidad equivalente a las dependencias anteriores a través de un nuevo `write método que acepta un reactor.core.publisher. Flux<ByteBuffer>. También se ha añadido un nuevo método a ipf-file-manager que permite leer el contenido del archivo en un reactor.core.publisher. Flux<ByteBuffer>. Para más detalles, consulte el Administrador de Archivos API Referencia.

Elimine los siguientes parámetros de configuración si están definidos en su configuración:

ipf.bulker.outputstream.local.enabled
ipf.bulker.outputstream.s3.enabled

Anteriormente, la configuración del sistema de archivos de salida requería deshabilitar el que no estaba en uso. Esto ahora se ha simplificado con una única propiedad.ipf.bulker.output.file-system que permite especificar el sistema de archivos de destino para la salida de manera explícita. Ver Bulk Productor para obtener detalles adicionales

Migración para IPF Persistent Scheduler

HTTP API

El triggerCommand campo en el cuerpo de la solicitud de POST /api/v1/schedule-job y POST /api/v1/update-job puntos finales, así como en las respuestas de los cuatro HTTP API las operaciones, ha cambiado.

Donde anteriormente era una API modelo de SchedulingCommand con un @class campo, ahora es una API modelo de ExternalTriggerCommand. Este modelo ya no tiene el @class campo y tiene campos adicionales requeridos para scheduling la liberación de pagos.

SchedulerConnectorInterface

Si usted utiliza SchedulerConnectorInterface para interactuar con el HTTP RequestReplySendConnectors en el scheduler-client-connector-http artefacto, deberá migrar los modelos pasados como argumentos del método y utilizados como tipos de retorno. Los modelos son ahora de la HTTP API especificación en oposición a los modelos 'núcleo'.

Migración para el Programador IPF Floclient

Programador FloClient Comandos

Si usted utilizó anteriormente PaymentAsyncScheduleCompletedCommand Desde los comandos del Scheduler Floclient, ahora debe utilizar el SchedulePaymentReleaseCommand objeto. Esto extiende el ExternalTriggerCommand desde el HTTP API modelos, que a su vez implementa el existente SchedulingCommand interfaz.

priority`y `scheduleDate los campos ya no están incluidos en el PaymentAsyncScheduleCompletedCommand objeto (que ha sido refactorizado a SchedulePaymentReleaseCommand). Estos campos fueron, y siguen siendo, no utilizados por el Programador. API, Floclient y Core.

IPF Persistent Scheduler Dominio Externo

El dominio externo IPF Persistent Scheduler solicitudes Schedule Instruction Release y Schedule Transaction Release ahora puede devolver las respuestas Scheduled Instruction Release Completion y Scheduled Transaction Release Completion respectivamente. Estas nuevas respuestas son notificaciones de que la liberación de la instrucción/transacción programada ha sido triggered para la ejecución. Estas respuestas difieren de las existentes Scheduled Instruction Release Response y Scheduled Transaction Release Response, que informan que el flujo de la liberación de la instrucción/transacción ha sido programado (pero no triggered para la ejecución).

Estos nuevos comandos están conectados automáticamente si usted está utilizando el scheduler-external-trigger-kafka módulo en su aplicación Scheduler (descrito en release/IPF-2025-2-0/release-IPF-2025-2-0-core.adoc#_ipf_persistent_scheduler_added sección). Si no está utilizando el scheduler-external-trigger-kafka módulo, puede emitir estas respuestas modificando su existente SchedulingHelper implementaciones para llamar al IPFPaymentSchedulerInputPort.handle(ScheduledInstructionReleaseCompletionInput scheduledInstructionReleaseCompletion) método (o equivalente de transacción) en el execute método.

Migración para el Liberador de Pagos (Procesador de Entradas de Pago)

Refactorización del Liberador de Pagos para convertirse en un Procesador de Entradas de Pago genérico

La implementación de liberación existente debe realizar los siguientes ajustes para que funcione con el nuevo procesador genérico:

Cambios de configuración

  • La ruta raíz de configuración debe ser cambiada de ipf.core.payment-releaser to ipf.core.payment-entry-processor

  • El procesador de entrada de pagos ahora utiliza un nuevo executionInfos colección de base de datos, que requiere un nuevo compuesto unitOfWorkId_1_actionType_1 índice a ser añadido. El releaseExecutionInfos La colección ya no se utiliza y puede ser eliminada, a menos que su contenido sea necesario para datos históricos, en cuyo caso puede ser archivada en algún lugar antes de la eliminación.

Renombrar referencias

  • Todo PaymentReleaser las referencias deben ser reemplazadas por PaymentEntriesProcessor referencia

  • Todo ReleaserExecutor las referencias deben ser reemplazadas por InstructionExecutorActor referencia

  • Todo PaymentRequestCreator las referencias deben ser reemplazadas por ProcessingRequestCreator referencia

  • Todo PaymentRequestSender las referencias deben ser reemplazadas por RequestProcessor referencia

  • Todo ReleaserStore las referencias deben ser reemplazadas por ExecutionInfoStore referencia

  • Todo TransactionReleaseService las referencias deben ser reemplazadas por PaymentEntriesProcessingService referencia

  • Todo ReleaserExecutorProperties las referencias deben ser reemplazadas por PaymentEntryProcessorProperties referencia

  • Todo InstructionReleaseCompletionService las referencias deben ser reemplazadas por InstructionProcessingCompletionService referencia

Cambios en la definición de Bean

TransactionReleaserService bean la definición debe ser reemplazada por un PaymentEntriesProcessingServiceImpl bean definición. Esta clase ahora depende de processingStrategyProvider— esto bean ya se está definiendo en el núcleo PaymentEntriesProcessor, solo necesita ser cableado aquí.

Implementación de la estrategia de procesamiento

Usted necesita crear una implementación del ProcessingStrategy interfaz, y conéctelo como un bean. Su implementación debe utilizar ProcessingActionTypes. RELEASE tipo de acción para especificar la acción de liberación y devolver su existente ProcessingRequestCreator y RequestProcessor implementaciones de interfaz. Para más detalles sobre Estrategias de Procesamiento, consulte la Documentos de Estrategia de Procesamiento.

Añadiendo SupportingContext to processInstruction y processTransaction

A través de la PaymentEntriesProcessor(renombrado de PaymentReleaser) interfaz,PaymentReleaserController y el ClientPort interfaces (por ejemplo,ReleaseInstructionClientPort) y su implementación HTTP Send Connector s (por ejemplo ReleaseInstructionConnector) el processInstruction y processTransaction los métodos deben actualizarse para incluir un SupportingContext. Estos métodos en estas clases tienen un argumento adicional de SupportingContext para pasar datos adicionales del servicio que llama al servicio de ejecución objetivo. Si no tiene uso para este campo durante la migración, puede omitirlo.null or SupportingContext.empty(). En el caso de la PaymentReleaserController, está envuelto en un Mono como Mono<SupportingContext>, para que pueda pasar un Mono.empty() si este campo no es obligatorio en su migración. Las opciones anteriores (nulas o vacías) serán manejadas de manera adecuada.

PaymentRequestCreator

Su implementación de la ProcessingRequestCreator(renombrado de PaymentRequestCreator) la interfaz ahora incluirá un SupportingContext argumento del método en el create método. Esto es para permitir la provisión de datos adicionales al servicio de ejecución objetivo.

En su migración, puede optar por utilizar o ignorar el proporcionado SupportingContext al crear su solicitud de pago.

Migración para Pagos Programados en el Futuro

Liberador de Pagos

Cambie al initationAggregatorFunction, suministrado a BasePaymentWarehouseDataSource significaría que cuando la respuesta es procesada, un Optional.empty debe ser devuelto si no initationAggregatorFunction se proporciona.

Migración para la Verificación del Beneficiario VoP)

Gestión de Cuentas API

  • Actualice su servicio implementando esto. API hasta ahora devolver 'RetrievePartyDetailsResponse.names', que ahora es una lista de nombres. Esto reemplaza el 'RetrievePartyDetailsResponse.nm' campo.

Verificación del Pagador Responder

  • Anteriormente, los umbrales de coincidencia se definían solo por tipo de cuenta. En esta versión, los umbrales de coincidencia deben definirse por entidad de procesamiento y tipo de cuenta.

Pre 2025.2.0:

ipf.verification-of-payee.responder {
  name-match {
    thresholds = [
      {type: "default", score-lowerbound = 0.40, score-upperbound = 0.90}
      {type: "individual", score-lowerbound = 0.85, score-upperbound = 0.95}
      {type: "corporate", score-lowerbound = 0.75, score-upperbound = 0.85}
    ]
  }
}

Post 2025.2.0 equivalente:

ipf.verification-of-payee.responder.name-match {
  thresholds = [
    {
      processing-entity: "default", (1)
      scorings: [ (2)
        { type: "default", lowerbound = 0.40, upperbound = 0.90 } (3) (4)
        { type: "individual", lowerbound = 0.85, upperbound = 0.95 }
        { type: "corporate", lowerbound = 0.75, upperbound = 0.85 }
      ]
    },
    {
      processing-entity: "Processing Entity A",
      scorings: [
        { type: "default", lowerbound = 0.70, upperbound = 0.80 }
        { type: "individual", lowerbound = 0.75, upperbound = 0.85 }
        { type: "corporate", lowerbound = 0.65, upperbound = 0.75 }
      ]
    }
  ]
}
1 Se debe definir una entidad de procesamiento predeterminada.
2 La estructura de configuración se ha cambiado para incluir scoring en jerarquía <3>`score-lowerbound` renombrado a lowerbound <4>`score-upperbound` renombrado a upperbound

Verificación del Solicitante de Pago

  • Configuración ipf.verification-of-payee.requester.scheme-membership-ids ha sido eliminado de la jerarquía. Los clientes que sobrescriben valores (por ejemplo,processing-entities) debajo de esta ruta debe eliminar scheme-membership-ids desde la ruta.

  • El código de entidad de procesamiento predeterminado era anteriormente "". Esto ha sido actualizado a default en lugar de cadena vacía, consistente con VoP Responder

  • rvm el parámetro debe ser especificado además de name para la configuración del esquema

Pre 2025.2.0:

ipf.verification-of-payee.requester {
  scheme-membership-ids { (1)
    schemes = [
      {
        name: "EPC"
        processing-entities = [
          {processing-entity-code: "", scheme-membership-id: "ICONUK00XXX"} (2)
          {processing-entity-code: "001", scheme-membership-id: "ICONUK01XXX"}
        ]
      }
    ]
  }
}
1 Esto se elimina en 2025.2.0
2 "" ha sido reemplazado por default en 2025.2.0 para denotar la entidad de procesamiento predeterminada

Post 2025.2.0 equivalente:

ipf.verification-of-payee.requester {
   schemes = [
     {
       name: EPC (1)
       rvm: FPAD (2)
       processing-entities = [
         {processing-entity-code: "default", scheme-membership-id: "ICONUK00XXX"} (3)
         {processing-entity-code: "001", scheme-membership-id: "ICONUK01XXX"}
       ]
     }
   ]
}
1 Ahora definido como un Enum en lugar de String
2 Anteriormente, el EPC utilizando FPAD como un RVM fue configurado con solo el name parámetro de configuración. Ahora rvm: FPAD también debe ser especificado y se define como un Enum
3 La entidad de procesamiento predeterminada ahora se identifica como "default"

Migración para Dynamic Processing Settings(DPS)

Como parte de la versión 2025.2 de IPF, CSM Reachability el servicio se está integrando con DPS V2 biblioteca (en comparación con integrada con DPS V2 antes).

Las estructuras de registros de configuración dinámica difieren entre DPS V1 y DPS V2. Esto no afecta la carga útil de la configuración dinámica. Desde el punto de vista de la compatibilidad hacia atrás, ambos DPS V1 y DPS V2 los registros formateados pueden coexistir al mismo tiempo que DPS V2 puede interactuar con los registros creados utilizando DPS V1.

Sin embargo, al tratar con configuraciones dinámicas de gran volumen, si los registros en la colección siguen todos DPS V1 formato, esto puede afectar ligeramente el rendimiento. Por esta razón, se recomienda que tales configuraciones dinámicas en CSM Reachability(ej. configuraciones dinámicas de datos de la industria), se actualizan para seguir DPS V2 formato.

El principal beneficio de esta migración es la mejora en el rendimiento de las consultas a la base de datos.

Pasos para la migración

  1. Se recomienda que la implementación del cliente ingiera archivos COMPLETOS a las configuraciones dinámicas de datos de la industria después de absorber DPS V2 integrado CSM Reachability:

    • Directorio de Entidades de Parte (Directorio Bancario Plus, Banco Maestro 3.0)

    • IBAN Plus, Lista de Exclusión, Estructura del IBAN

  2. El siguiente conjunto de archivos que se van a incorporar en CSM Participante después de absorber DPS V2 integrado CSM Reachability deben ser archivos COMPLETOS.

    • PASO2 CST, RT1, CONSEJOS, SicInst

  3. Para cada DPS verifique si hay algún dato que no esté actualizado utilizando el siguiente script

    db.[<collection-name>].find({
  "_class": {
    $regex: "^com.iconsolutions.ipf.dynamicsettings.repository"
  }
})

  4. Si hay documentos que no han sido actualizados, por favor, genere un ticket de soporte.

Migración para Test Framework

Como resultado de la JUnit 5 migración, si usted está incluyendo cualquiera de JUnit 4 Reglas utilizando el @ClassRule anotación en sus pruebas, o ejecución de suites de prueba utilizando el @Suite anotación, por favor migre estos a JUnit Júpiter Extensiones y Suites, respectivamente.

La tabla a continuación muestra comunes JUnit 4 usos en el marco de prueba, y su JUnit 5 equivalente:

Característica Test Framework JUnit 4 fragmento Equivalente de JUnit 5

Suites

 
import org.junit.runner.RunWith;
import org.junit.runners.Suite;

@RunWith(Suite.class)
@Suite.SuiteClasses({MyTest1.class, MyTest2.class})
 
import org.junit.platform.suite.api.SelectClasses;
import org.junit.platform.suite.api.Suite;

@Suite
@SelectClasses({MyTest1.class, MyTest2.class})

Reglas (Extensiones)

 
import com.palantir.docker.compose.DockerComposeRule;
import org.junit.ClassRule;

@ClassRule
public static DockerComposeRule dockerComposeRule = getRule();

private static DockerComposeRule getRule() {
    DockerComposeRule dockerComposeRule = new AppComposeLauncher().getComposeRule();
    //...
}
 
import com.palantir.docker.compose.DockerComposeExtension;
import org.junit.jupiter.api.extension.RegisterExtension;

@RegisterExtension
public static DockerComposeExtension dockerComposeRule = getRule();

private static DockerComposeExtension getExtension() {
    var dockerComposeRule = new AppComposeLauncher().getComposeRule();
    //...
}
Puede estar utilizando otros JUnit 4 Reglas no listadas arriba. Consulte la documentación de las bibliotecas que está utilizando. para su JUnit 5 equivalentes.