Pasos de migración para IPF-2025.4.0

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

Migración para Debulker Cliente Flo

  • Especificando un único marcador literal en Call Bulk Flow ya no se recomienda.

  • Ahora puede especificar una lista de marcadores literales o un único marcador de datos comerciales.

  • Ver Llamar Bulk Flujos para obtener detalles adicionales.

Se recomienda que usted abra cualquier solución que utilice debulker.flo client in MPS y haga clic en ok en el aviso de migración.

Procesador de Entrada de Pagos (también conocido como Liberador de Pagos)

  • BasePaymentWarehouseDataSource cambios de clase:

    • Renombrado a AggregateEntriesWarehouseDataSource, cualquier WarehouseDataSource la clase que la extienda debe ajustarse en consecuencia

    • initationAggregatorFunction el parámetro ahora es de tipo Function<List<PaymentEntry>, Optional<PaymentWarehouseInitiation>>, en lugar de ObjectProvider<Function<List<PaymentEntry>, Optional<A>>> como estaba anteriormente

  • Cambios de configuración:

    • Debe añadir @AutoConfigureBefore(WarehouseDatasourceAutoConfig.class) a su PaymentEntryProcessor AutoConfiguration clase

    • Si no almacena la información del nivel de Iniciación en el Almacén de Pagos, no debe proporcionar la initiationEntriesAggregator implementación bean ya no. Cuando bean no presente en la configuración del cliente, un valor predeterminado NoOp bean(definido en WarehouseDatasourceAutoConfig) se utilizará en su lugar.

Migración para SEPA DD

  • Añada configuración ipf.csm.sepa-dd.processing-entity para establecer los participantes directos/indirectos. El siguiente es un ejemplo de configuración

ipf.csm.sepa-dd {
  processing-entity {
    valid-agent-bics = [
      {
        direct-participant-bic = "ICONGBA0"
        indirect-participant-bics = [
          "ICONGBA1",
          "ICONGBA2"
        ]
      },
      {
        direct-participant-bic = "ICONGBA3"
        indirect-participant-bics = [
          "ICONGBA4",
          "ICONGBA5"
        ]
      }
    ]
  }
}

Migración para CSM Service

CSM Service Cliente Inicial

  • CSMDDClientAdapter la interfaz ha introducido los siguientes nuevos métodos. Sobrescriba los mismos para implementaciones específicas del cliente:

    @Override
    public CompletionStage<Void> handleNotifyDDRefundReturn(ReceivingContext receivingContext, NotifyDDRefundReturn notifyDDRefundReturn) {
        log.info("Received NotifyDDRefundReturn request {} with context {}", notifyDDRefundReturn.getRequestId(), notifyDDRefundReturn.getProcessingContext());
        return CompletableFuture.completedStage(null);
    }

    @Override
    public CompletionStage<Void> handleNotifyDDRefusalReject(ReceivingContext receivingContext, NotifyDDRefusalReject notifyDDRefusalReject) {
        log.info("Received NotifyDDRefusalReject request {} with context {}", notifyDDRefusalReject.getRequestId(), notifyDDRefusalReject.getProcessingContext());
        return CompletableFuture.completedStage(null);
    }

Migraciones para SEPACT CSM Service

Configuración de Bic(s) de Agente Válido

Con la adición de la mejora de la entidad de procesamiento entrante en este CSM servicio, el valid-agent-bics la estructura de configuración tuvo que ser adaptada y requiere cambios:

Esto solo es necesario si utiliza el valid-agent-bics validaciones y/o desea utilizar el config entidad de procesamiento tipo de procesador

Antes de 2025.4:

ipf.csm.sepa-ct.processing-entity {
  valid-agent-bics = [
    {
      direct-participant-bic = "ICONGBA0"
      indirect-participant-bics = [
        "ICONGBA1"
      ]
    }
  ]
}

2025.4 en adelante:

ipf.csm.sepa-ct.processing-entity {
  valid-agent-bics = [
    {
      direct-participant-bic {
        bic = "ICONGBA0"
        processing-entity = "BIG_BANK_1"
      }
      indirect-participant-bics = [
        {bic: "ICONGBA1", processing-entity: "BIG_BANK_MINI_1"}
      ]
    }
  ]
}

HTTP/JMS Deprecación del Método de Conector

  • Según las notificaciones en IPF 2024.3.0, los siguientes métodos serán eliminados en la próxima versión (2026.1.0):

    • withTransportConfiguration método en HttpConnectorTransport<T>. Builder:`HttpConnectorTransport. Builder<T>(String name, ClassicActorSystemProvider actorSystem, String configRootPath)` debe ser utilizado en su lugar.

    • withTransportConfiguration método en HttpReceiveConnectorTransport. Builder:`HttpReceiveTransportConfiguration` será instanciado por build() método en su lugar

    • HttpReceiveConnectorTransportFactory está obsoleto y será eliminado, utilice HttpReceiveConnectorTransport. Builder en su lugar.