Documentation for a newer release is available. View Latest

Pasos de Migración para IPF-2025.2.0

Migración para Conectores

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

Migración para Conectores Kafka

akka.kafka.consumer.restart-settings ahora se define por defecto en ipf.connector.default-transport-settings.restart-settings. Dado que todos los ajustes de consumidor Kafka ahora heredan de esta configuración por defecto, ya no es necesario especificar restart-settings al declarar un transporte de consumidor Kafka.

Si antes configuraba sus restart-settings a akka.kafka.consumer.health-check-settings.restart-settings o ipf.connector.default-transport-settings.restart-settings, ahora puede eliminar esas líneas de su HOCON.

Migración para Conectores HTTP

Las excepciones internas com.iconsolutions.ipf.core.connector.transport.HttpErrors.HttpStatusErrorException ahora tienen encapsulación más estricta y sus constructores ya no son accesibles públicamente. Si necesita crear una instancia para pruebas, 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 mediante un nuevo método write que acepta reactor.core.publisher.Flux<ByteBuffer>. También se añadió un método para leer contenido de archivo a reactor.core.publisher.Flux<ByteBuffer>. Para más detalles, consulte Referencia de API de File Manager.

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, configurar el sistema de archivos de salida requería deshabilitar el que no se usaba. Ahora se simplifica con una sola propiedad ipf.bulker.output.file-system que permite especificar explícitamente el sistema de archivos destino. Vea Bulk Productor para detalles adicionales

Migración para Programador Persistente de IPF

API HTTP

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

Antes era un modelo API de SchedulingCommand con un campo @class, ahora es un modelo API de ExternalTriggerCommand. Este modelo ya no tiene el campo @class y tiene campos adicionales necesarios para programar la liberación de pagos.

SchedulerConnectorInterface

Si usa SchedulerConnectorInterface para interactuar con los HTTP RequestReplySendConnectors en el artefacto scheduler-client-connector-http, deberá migrar los modelos pasados como argumentos de métodos y tipos de retorno. Los modelos ahora provienen de la especificación de la API HTTP en lugar de modelos 'core'.

Migración para IPF Scheduler Floclient

Comandos del Scheduler FloClient

Si previamente usaba PaymentAsyncScheduleCompletedCommand de los comandos del Scheduler Floclient, ahora debe usar SchedulePaymentReleaseCommand. Esto extiende ExternalTriggerCommand de los modelos de la API HTTP, que a su vez implementa la interfaz existente SchedulingCommand.

Los campos priority y scheduleDate ya no se incluyen en el objeto PaymentAsyncScheduleCompletedCommand (refactorizado a SchedulePaymentReleaseCommand). Estos campos estaban, y siguen, sin ser usados por la API del Scheduler, Floclient y Core.

Dominio Externo del Programador Persistente de IPF

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

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

Migración para Payment Releaser (Procesador de Entradas de Pago)

Refactorización de Payment Releaser a Procesador Genérico de Entradas de Pago

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 cambiar de ipf.core.payment-releaser a ipf.core.payment-entry-processor

  • El procesador de Entradas de Pago ahora usa una nueva colección de base de datos executionInfos, requiriendo un nuevo índice compuesto unitOfWorkId_1_actionType_1. La colección releaseExecutionInfos ya no se usa y puede eliminarse, a menos que sus contenidos se requieran para datos históricos; en ese caso puede archivarse antes de eliminar.

Renombrado de referencias

  • Todas las referencias a PaymentReleaser deben reemplazarse por PaymentEntriesProcessor

  • Todas las referencias a ReleaserExecutor deben reemplazarse por InstructionExecutorActor

  • Todas las referencias a PaymentRequestCreator deben reemplazarse por ProcessingRequestCreator

  • Todas las referencias a PaymentRequestSender deben reemplazarse por RequestProcessor

  • Todas las referencias a ReleaserStore deben reemplazarse por ExecutionInfoStore

  • Todas las referencias a TransactionReleaseService deben reemplazarse por PaymentEntriesProcessingService

  • Todas las referencias a ReleaserExecutorProperties deben reemplazarse por PaymentEntryProcessorProperties

  • Todas las referencias a InstructionReleaseCompletionService deben reemplazarse por InstructionProcessingCompletionService

Cambios en definición de beans

La definición del bean TransactionReleaserService debe sustituirse por un bean PaymentEntriesProcessingServiceImpl. Esta clase ahora depende de processingStrategyProvider — este bean ya se define en el core de PaymentEntriesProcessor, solo debe cablearse aquí.

Implementación de la estrategia de procesamiento

Debe crear una implementación de la interfaz ProcessingStrategy y registrarla como bean. Su implementación debe usar el tipo de acción ProcessingActionTypes.RELEASE para especificar acción de liberación, y devolver sus implementaciones existentes de ProcessingRequestCreator y RequestProcessor. Para más detalles sobre Estrategias de Procesamiento, consulte Documentación de Estrategia de Procesamiento.

Añadiendo SupportingContext a processInstruction y processTransaction

En toda la interfaz PaymentEntriesProcessor (renombrada de PaymentReleaser), PaymentReleaserController y las interfaces ClientPort (por ejemplo ReleaseInstructionClientPort) y sus conectores HTTP Send implementados (por ejemplo ReleaseInstructionConnector) los métodos processInstruction y processTransaction se actualizan para incluir un SupportingContext. Estos métodos en estas clases tienen un argumento adicional SupportingContext para pasar datos adicionales desde el servicio llamador al servicio de ejecución destino. Si no necesita este campo durante la migración puede pasar null o SupportingContext.empty(). En el caso de PaymentReleaserController, está envuelto en un Mono como Mono<SupportingContext>, por lo que puede pasar un Mono.empty() si este campo no se requiere en su migración. Las opciones anteriores (null o vacío) se manejarán correctamente.

PaymentRequestCreator

Su implementación de la interfaz ProcessingRequestCreator (renombrada de PaymentRequestCreator) ahora incluirá un argumento SupportingContext en el método create. Esto permite proporcionar datos adicionales al servicio de ejecución destino.

En su migración puede elegir usar o ignorar el SupportingContext proporcionado al crear su solicitud de pago.

Migración para Pagos con Fecha Futura

Payment Releaser

El cambio a la initationAggregatorFunction, suministrada a BasePaymentWarehouseDataSource significa que cuando se procesa la respuesta, se debe devolver un Optional.empty si no se suministra ninguna initationAggregatorFunction.

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

API de Gestión de Cuentas

  • Actualice su servicio que implementa esta API para devolver ahora 'RetrievePartyDetailsResponse.names', que ahora es una lista de nombres. Esto reemplaza el campo 'RetrievePartyDetailsResponse.nm'.

Verificación del Beneficiario - Respondedor

  • Anteriormente, los umbrales de coincidencia se definían solo por tipo de cuenta. En esta versión los umbrales deben definirse por entidad de proceso 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}
    ]
  }
}

Equivalente Post 2025.2.0:

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 Debe definirse una entidad de proceso por defecto
2 Estructura de configuración cambiada para incluir scoring en la jerarquía
3 score-lowerbound renombrado a lowerbound
4 score-upperbound renombrado a upperbound

Verificación del Beneficiario - Solicitante

  • La configuración ipf.verification-of-payee.requester.scheme-membership-ids se ha eliminado de la jerarquía. Los clientes que sobrescriben valores (por ejemplo processing-entities) bajo esta ruta deben eliminar scheme-membership-ids de la ruta.

  • La entidad de proceso por defecto antes era "". Esto se ha actualizado a default en lugar de cadena vacía, consistente con VoP Respondedor

  • El parámetro rvm debe especificarse 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 proceso por defecto

Equivalente Post 2025.2.0:

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, EPC usando FPAD como RVM se configuraba solo con el parámetro name. Ahora también debe especificarse rvm: FPAD, y se define como un Enum
3 La entidad de proceso por defecto ahora se identifica como "default"

Migración para Configuraciones Dinámicas de Procesamiento (DPS)

Como parte de IPF 2025.2, el servicio CSM Reachability se está integrando con la librería DPS V2 (antes estaba integrado con DPS V1).

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

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

El principal beneficio de esta migración es un mejor rendimiento de consultas de base de datos.

Pasos para la migración

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

    • Party Entity Directory (Bank Directory Plus, Bank Master 3.0)

    • IBAN Plus, Exclusion List, IBAN Structure

  2. El siguiente conjunto de archivos a ingerir en CSM Participant después de absorber CSM Reachability integrado con DPS V2 debe ser FULL:

    • STEP2 CST, RT1, TIPS, SicInst

  3. Para cada colección DPS verifique si hay datos no actualizados usando el siguiente script

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

  1. Si hay documentos que no se han actualizado, por favor abra un ticket de soporte.

Migración para el Marco de Pruebas

Como resultado de la migración a JUnit 5, si está incluyendo Reglas de JUnit 4 usando la anotación @ClassRule en sus pruebas, o ejecutando suites de prueba usando la anotación @Suite, por favor migre estas a Extensiones de JUnit Jupiter y Suites, respectivamente.

La tabla siguiente muestra usos comunes de JUnit 4 en el marco de pruebas y su equivalente en JUnit 5:

Funcionalidad Fragmento JUnit 4 del Marco de Pruebas Equivalente en 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();
    //...
}

NOTA: Puede estar usando otras Reglas de JUnit 4 no listadas arriba. Consulte la documentación de las librerías que usa para sus equivalentes en JUnit 5.