Pasos de Migración para IPF-2025.2.0

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

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-flujo-de-salida-api-ipf-bulker-flujo-salida-local-ipf-bulker-flujo-salida-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 campo triggerCommand 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.

Mientras que 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 'core' modelos.

Migración para IPF Scheduler Floclient

Scheduler FloClient Comandos

Si usted utilizó anteriormente PaymentAsyncScheduleCompletedCommand from the Scheduler Floclient comandos, usted debe ahora 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 Scheduler API, Floclient y Core.

IPF Persistent Scheduler Dominio Externo

El dominio externo IPF Persistent Scheduler solicitudes Schedule Instruction Release y Schedule Transaction Release puede ahora devolver las respuestas Scheduled Instruction Release Completion y Scheduled Transaction Release Completion respectivamente. Estas nuevas respuestas son notifications que el scheduled la liberación de la instrucción/transacción ha sido triggered para la ejecución. Estas respuestas difieren de las existentes Scheduled Instruction Release Response y Scheduled Transaction Release Response, que informan el flujo que la liberación de la instrucción/transacción ha sido scheduled(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 Scheduler aplicación (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, requiriendo 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

Bean definition cambios

TransactionReleaserService bean definition debe ser reemplazado por un PaymentEntriesProcessingServiceImpl bean definition. Esta clase ahora depende de processingStrategyProvider— esto bean ya se está definiendo en core PaymentEntriesProcessor, solo necesita ser conectado 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 a processInstruction y processTransaction

A través de la PaymentEntriesProcessor(renombrado de PaymentReleaser) interfaz,PaymentReleaserController y las interfaces ClientPort (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 desde el 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.

CreadorDeSolicitudDePago

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

Liberador de Pagos

Cambie al initationAggregatorFunction, suministrado a BasePaymentWarehouseDataSource significaría que cuando se procese la respuesta, 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 ahora devuelve 'RetrievePartyDetailsResponse.names', que ahora es una lista de nombres. Esto reemplaza el campo 'RetrievePartyDetailsResponse.nm'.

Verificación del Pagador Respondedor

  • 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}
    ]
  }
}

Publicación 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 con default in 2025.2.0 para denotar la entidad de procesamiento predeterminada

Publicación 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 de IPF 2025.2, CSM Reachability service se está integrando con DPS V2 biblioteca (en comparación con integrada con DPS V2 before).

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 Partes (Directorio Bancario Plus, Maestro Bancario 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 datos que no están actualizados utilizando el siguiente script

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

  1. 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 esto a JUnit Júpiter Extensiones y Suites, respectivamente.

La tabla a continuación muestra comunes JUnit 4 usos en el test framework, y sus JUnit 5 equivalente:

Característica Test Framework JUnit 4 fragmento JUnit 5 Equivalente

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.