Pasos de Migración para IPF-2025.3.0
Esta página cubre los pasos de migración requeridos para la versión de IPF 2025.3.0
Migración de Flujos DSL
El concepto previamente desaprobado de 'ResponseCodeLibrary' ha sido eliminado. Si su solución aún contiene uno de estos, simplemente debe ir a ese concepto y luego presionar F6 y seleccionar la ubicación donde desea almacenar el conjunto de códigos de respuesta.
Se recomienda que abra sus soluciones de Flo y haga clic en aceptar en el aviso de migración. Hay una migración en esta versión, aunque es solo para mejoras de la interfaz de usuario, por lo que no es obligatoria.
Un nuevo custom se ha añadido la capacidad de operación. Para esto, un nuevo método "performOperation" está disponible en la especificación del dominio. Si bien no se requieren cambios para esto, si por alguna razón ha creado su propio ModelOperations implementación (por ejemplo en pruebas), entonces deberá añadir una implementación para este método.
Migraciones para Scheme Pack s
Las pruebas de integridad de BDD ahora fallarán correctamente si TechnicalReponse or ValidateSchemeRuleResponse Los mensajes han sido enviados pero no afirmados dentro de sus pruebas. Si usted tiene failed Para afirmar que estos mensajes, su ejecución de prueba fallará en la sección afterStories.
Deberá agregar las afirmaciones adecuadas a sus pruebas para garantizar que todos los mensajes sean procesados.
Las afirmaciones de ejemplos son:
Then Payment Service receives a 'Technical Response' with values:
| status | SUCCESS |
Then the Payment Service receives a 'Validate Scheme Rules Response' with values:
| status | FAILURE |
| payload.content.reasonCode | FF01 |
Si ya ha afirmado para todos los mensajes, no son necesarios cambios.
Migración para SEPA CT
El abajo system events han sido trasladados a un diferente maven módulo y paquete diferente. Si hace referencia a lo siguiente system events deberá añadir el nuevo maven dependency y actualice el paquete.
-
System Events moved to SEPA Común
Nombre |
BulkCommandFailed |
ReceiveFromSchemeExtensionPointFailed |
ErrorAlEnviarEsquemaDeRespuesta |
SendToSchemeExtensionPointFailed |
SendToSchemeExtensionPointSuccess |
Paquete anterior:`com.iconsolutions.ipf.sepact.core.events`
Nuevo paquete:`com.iconsolutions.ipf.payments.csm.sepa.common.events`
Anterior maven módulo:
<dependency>
<groupId>com.iconsolutions.ipf.payments.csm.sepact</groupId>
<artifactId>sepact-csm-events</artifactId>
</dependency>
Nuevo maven módulo:
<dependency>
<groupId>com.iconsolutions.ipf.payments.csm.sepa.common</groupId>
<artifactId>sepa-common-events</artifactId>
</dependency>
Migración para Conectores
Transport Message Procesando encabezados de contexto
Los cambios a continuación solo deberían ser necesarios para el código de prueba, ya que la presencia de estos encabezados depende de la configuración del conector. Si se utiliza en código de producción, se debe aplicar una consideración más cuidadosa; tanto los encabezados antiguos como los nuevos pueden necesitar ser utilizados para Kafka/JMS, pero idealmente el contexto debería ser transmitido a través de la carga útil del mensaje en su lugar. |
-
Obsoleto
ProcessingContextLas claves de encabezado han sido eliminadas. Debe reemplazar todas las ocurrencias de:-
com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. UOW_ID_HEADERconcom.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. UNIT_OF_WORK_ID_CONTEXT_KEYclave -
com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. PROCESSING_ENTITY_HEADERwithcom.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. PROCESSING_ENTITY_CONTEXT_KEYclave -
com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. ASSOCIATION_ID_HEADERconcom.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. ASSOCIATION_ID_CONTEXT_KEYclave -
com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. REQUEST_ID_HEADERconcom.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. CLIENT_REQUEST_ID_CONTEXT_KEYclave
-
-
MessageHeaders.fromProcessingContext()el método ha sido eliminado, usted debe usarProcessingContextUtils.toMap()en su lugar:MessageHeaders headers = new MessageHeaders(ProcessingContextUtils.toMap(processingContext)); -
MessageHeaders.toProcessingContext()el método ha sido eliminado, debe utilizarProcessingContextUtils.fromMap()en su lugar:ProcessingContext processingContext = ProcessingContextUtils.fromMap(messageHeaders.getHeaderMap()); -
ProcessingContextUtils. ProcessingContextHeaderExtractorha sido trasladado a una clase independiente:`com.iconsolutions.ipf.core.connector.common. ProcessingContextHeaderExtractor`. Reemplacereturn t -> new ProcessingContextUtils. ProcessingContextHeaderExtractor().extract(t)with
return new ProcessingContextHeaderExtractor()
Creación del índice de correlación
-
Renombre cualquier uso de
ipf.correlation.index-creation.enabledpropiedad de configuración paraipf.connector.correlation.create-indexes. -
Renombre cualquier uso de
ipf.connector.correlation-timestamp-field-namepropiedad de configuración paraipf.connector.correlation.timestamp-field-name. -
Renombre cualquier uso de
ipf.connector.correlation-expirypropiedad de configuración paraipf.connector.correlation.time-to-live. == Migración para SEPA DD Actualmente, los clientes que dependen de SEPA Los DD aún se encuentran en desarrollo/prueba, por lo que el enfoque recomendado para migrar a esta versión es implementar con una nueva base de datos de diario.
CSM Cliente
Se han renombrado varios elementos de configuración para permitir la consolidación de temas y colas en lugar de ser por mensaje. tipo/dirección/rol a solo dirección y rol:
| Elemento de configuración antiguo | Nuevo elemento de configuración |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
CSM Service
Se han renombrado varios elementos de configuración para permitir la consolidación de temas y colas en lugar de ser por mensaje. tipo/dirección/rol a solo dirección y rol:
| Elemento de configuración antiguo | Nuevo elemento de configuración |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Migración para JAXB
Esta versión de IPF elimina el soporte para el javax.xml.bind API(JAXB) a favor de la jakarta.xml.bind API(Jakarta
XML Binding).
Puede que pueda continuar utilizando JAXB, pero se recomienda actualizar a la nueva Jakarta. XML Vinculación API para asegurar compatibilidad hacia adelante con IPF y Jakarta EE, ya que JAXB fue desaprobado en Java 9.
Paso 1: Reemplace Dependencias y Plugins
Reemplace su Maven dependencies y complementos de JAXB API y la implementación de JAXB a Jakarta, utilizando la siguiente tabla:
| Dependencia antigua | Nueva dependencia | Nota |
|---|---|---|
|
|
Este es el JAXB Maven Plugin |
|
|
Esto suele ser un JAXB Maven Plugin dependencia |
|
|
Esto es generalmente un JAXB Maven Plugin dependencia |
|
|
Paso 2: Cambiar Nombres de Paquete
Reemplace todas las ocurrencias de javax.xml.bind con jakarta.xml.bind. La API no ha cambiado, por lo que no se requieren más cambios en el código
debería ser necesario
Paso 3: Cambiar el Archivo de Vinculación
El schemaBindings archivo utilizado para personalización de la compilación del esquema
debe ser actualizado para las vinculaciones de Jakarta.
Primero, cambie el version atributo de 2.1 to 3.0.
Los siguientes espacios de nombres deben cambiar:
| Antiguo espacio de nombres | Nuevo espacio de nombres |
|---|---|
|
|
|
|
|
|
Migración para MPS Proceso de construcción
Dentro MPS, hemos introducido la capacidad para que tanto el proceso de Dot a SVG como el proceso de fusión de IPF conf se realicen como parte de la interna MPS Haga el proceso, en lugar de requerir dedicado Maven plugins.
Esto tiene muchos beneficios:
-
Simplifica el proceso de construcción y ayuda a desacoplar el proceso de construcción de IPF de Maven donde sea apropiado.
-
Previene problemas de usabilidad relacionados con maven- estructuras de carpetas transitorias específicas en el directorio de destino que se eliminan al ejecutar pruebas relacionadas con Flow dentro de un IDE. Esto se manifestaría anteriormente como un error relacionado con Akka los roles no se encuentran cuando se ejecuta la prueba en un IDE, este error persistía anteriormente incluso si la configuración del IDE "limpiar fuentes generadas" estaba correctamente DESSELECCIONADA.
Como parte de la versión actual (2025.3.0), este cambio de enfoque es opcional, no es automático, pero recomendamos migrar ahora. Cambiaremos gradualmente el comportamiento predeterminado en el futuro, deprecaremos el maven plugins y eventually este nuevo enfoque será el único mecanismo soportado.
Los procesos para seleccionar la inclusión de estos procesos como parte de la generación se configuran de manera independiente para el MPS IDE y para cuando se ejecuta en la línea de comandos.
Habilitación dentro del IDE
Dentro del IDE, para habilitar estas funciones, consulte las dos nuevas opciones en el panel de configuración.
Habilite la generación de SVG de flujo- Esto permite la producción de imágenes SVG de los gráficos de flujo como parte de la generación.
Fusionar archivos de configuración IPF generados entre modelos- Esto permite la fusión de ipf.conf archivos en un solo archivo por solución como parte del proceso de generación.
Habilitando dentro de Maven
Para habilitar estas funciones como parte de maven Para construir, usted necesita hacer lo siguiente.
-
Añada un maven propiedad
-
Actualice un script de construcción si el proyecto utiliza MPS Scripts de construcción (no se requiere ningún cambio si el proyecto utiliza el icono-mps-plugin de runner en lugar de scripts de construcción)
-
Elija diferentes azulejos dentro del mps y módulos de dominio.
Maven propiedad
Agregue la siguiente propiedad al pom raíz del dominio.
<com.ipf.make.postProcessing>true</com.ipf.make.postProcessing>
A continuación se muestra un ejemplo de esta propiedad en el contexto del pom raíz del dominio esperado.
Actualizar BuildScript
Si su MPS El proyecto utiliza BuildScripts, necesitamos agregar un cambio allí para propagar esta propiedad en el proceso de generación subyacente.
Esto son dos cambios
-
Añadiendo com.ipf.make.postProcessing como una var
-
agregando -Dcom.ipf.make.postProcessing=${com.ipf.make.postProcessing} como generador jvm arg
E.j.
Azulejos Alternativos
Ahora que se han añadido estos cambios, necesitamos seleccionar diferentes azulejos en el mps y módulos de dominio para que NO apliquemos los complementos que originalmente manejaban estas características.
MPS Dentro de la mps directorio:
Si usted utiliza:
com.iconsolutions.ipf.core.flow:flo-mps-plugin-tile:@project.version@
Ahora, simplemente utilice:
com.iconsolutions.ipf.core.flow:flo-mps-plugin-base-tile:@project.version@
Si usted utiliza:
com.iconsolutions.ipf.core.flow:flo-mps-tile:@project.version@
Ahora utilice:
com.iconsolutions.ipf.core.flow:flo-mps-base-tile:@project.version@
Migración para Persistent Scheduler
Migrando FailureCommands a SchedulingHelper.lateExecute
| Los siguientes pasos solo se aplican a las especificaciones de trabajo que definen un comando de fallo y un identificador de fallo. Si no existen especificaciones de trabajo en el sistema, se puede omitir la migración. |
Antes de aplicar los pasos de migración, por favor, revise la última persistent scheduler docs sobre este tema.
Dada la siguiente tarea:
var job = JobSpecificationDto.builder()
.jobRequestor("invoice-service")
.singleSchedule(LocalDateTime.now().plusSeconds(30)) // desired execution
.zoneId(ZoneId.of("Europe/Madrid"))
.triggerIdentifier("order-123")
.triggerCommand(new RunInvoiceCommand())
.lateExecutionThreshold(Duration.ofSeconds(10)) // after desired+10s we treat it as late
.failureIdentifier("order-123")
.failureCommand(new RunInvoiceCommandFailed())
.build();
schedulingModule.scheduleJob(job);
y su SchedulingHelpers:
public class BillingHelper implements SchedulingHelper {
@Override
public boolean supports(SchedulingCommand cmd) {
return cmd instanceof RunInvoiceCommand;
}
// timely execution
@Override
public CompletionStage<Void> execute(String id, SchedulingCommand cmd) {
return CompletableFuture.runAsync(() -> doWork(id, cmd));
}
}
// Handles late execution
public class BillingFailedHelper implements SchedulingHelper {
@Override
public boolean supports(SchedulingCommand cmd) {
return cmd instanceof RunInvoiceCommandFailed;
}
// late execution, triggered if execution happens after desired+10s
@Override
public CompletionStage<Void> execute(String id, SchedulingCommand cmd) {
// business logic located in handleLateExecution
return CompletableFuture.runAsync(() -> handleLateExecution(id, cmd));
}
}
La lógica de negocio ubicada dentro de BillingFailedHelper.execute ahora necesita ser trasladado a BillingdHelper.lateExecute, con BillingFailedHelper ahora se dedica a manejar fallos de ejecución reales:
public class BillingHelper implements SchedulingHelper {
@Override
public boolean supports(SchedulingCommand cmd) {
return cmd instanceof RunInvoiceCommand;
}
// timely execution
@Override
public CompletionStage<Void> execute(String id, SchedulingCommand cmd) {
return CompletableFuture.runAsync(() -> doWork(id, cmd));
}
// late execution, triggered if execution happens after desired+10s
@Override
public CompletionStage<Void> lateExecute(String id, SchedulingCommand cmd, Duration overBy) {
log.warn("Job {} is late by {}", id, overBy);
return CompletableFuture.runAsync(() -> handleLateExecution(id, cmd)); }
}
// Can be omitted if no failure handling is required/desired
public class BillingFailedHelper implements SchedulingHelper {
@Override
public boolean supports(SchedulingCommand cmd) {
return cmd instanceof RunInvoiceCommandFailed;
}
// triggers if executions result in failure
// contains brand new business logic
@Override
public CompletionStage<Void> execute(String id, SchedulingCommand cmd) {
return CompletableFuture.runAsync(() -> handleFailure(id, cmd));
}
}
Migración para el Procesador de Entradas de Pago (anteriormente Liberador de Pagos)
HTTP implementación
Esta sección explica cómo actualizar los sistemas que se comunican con el Procesador de Entradas de Pagos a través de HTTP.
Usando SupportingContext en el Cuerpo de la Solicitud
Si usted está actualmente suministrando SupportingContext en su HTTP cuerpo de la solicitud a la POST /api/v1/payment-releaser/instruction/{instructionUnitOfWorkID}/release y/o POST /api/v1/payment-releaser/transaction/{transactionUnitOfWorkId}/release HTTP puntos finales, puede que necesite realizar cambios como se explica a continuación.
Si usted está utilizando el proporcionado HTTP Los conectores de cliente para conectarse al procesador de entradas de pago, usted no necesita realizar ningún cambio.
Si no está utilizando el proporcionado HTTP Conectores de Cliente, deberá actualizar el cuerpo de la solicitud en su solicitud de:
{
"headers": {
"fieldA": "value-for-field-A",
"fieldB": "value-for-field-B"
},
"metaData": {
"fieldC": "value-for-field-C",
"fieldD": "value-for-field-D"
}
}
{
"supportingData": {
"headers": {
"fieldA": "value-for-field-A",
"fieldB": "value-for-field-B"
},
"metaData": {
"fieldC": "value-for-field-C",
"fieldD": "value-for-field-D"
}
}
}
Como el HTTP El contrato contiene un cambio significativo; su actualización del Procesador de Entradas de Pago requerirá tiempo de inactividad, así como tiempo de inactividad de los sistemas que lo llaman. El orden de la actualización sería el siguiente:
-
Desactive el/los sistema(s) de llamadas.
-
Desactive el sistema de Procesador de Entradas de Pago.
-
Actualice el sistema de Procesador de Entradas de Pago
-
Levante el/los sistema(s) de llamadas (el/los sistema(s) de llamadas pueden o no estar actualizados, dependiendo de la HTTP el cliente utilizado, como se mencionó anteriormente en esta sección).
=== Embedded implementación
El punto de entrada del Procesador de Entradas de Pago es el PaymentEntriesProcessor java interfaz.
No hay requisito de actualizar cómo su sistema llama al PaymentEntriesProcessor java métodos de interfaz.
Si usted está utilizando el objeto de retorno de la processInstruction método, entonces deberá actualizar su sistema para utilizar el objeto de retorno actualizado.
El objeto de retorno es (y permanece)CompletionStage<ExecutionInfo>.
Sin embargo, el contenido de la ExectionInfo ha sido refactorizado, lo que ha causado un cambio disruptivo.
Después de que haya extraído el ExecutionInfo from the CompletionStage, entonces deberá realizar cambios para acceder al supportingData y actionType campos.
-
Antes de la actualización:
public void extract(ExecutionInfo executionInfo) {
SupportingContext supportingData = executionInfo.getSupportingData();
ProcessingActionType actionType = executionInfo.getActionType();
}
-
Después de la actualización:
public void extract(ExecutionInfo executionInfo) {
SupportingContext supportingData = executionInfo.getPaymentHandlingInfo().getSupportingData();
ProcessingActionType actionType = executionInfo.getPaymentHandlingInfo().getActionType();
}
== Migraciones para CharacterReplacer
=== Cambio disruptivo por la eliminación del método sobrecargado replaceCharacters Hemos eliminado el siguiente método sobrecargado de la interfaz que permitía el reemplazo de caracteres solo en parte de una cadena.
String replaceCharacters(String text, Optional<String> startFrom, Optional<String> endAfter);
Si lo está utilizando en su código, el siguiente código de migración debería ayudar a mantener una funcionalidad idéntica.
==== Especificando solamente startFrom
var resultingXml = characterReplacer.replaceCharacters(xml, Optional.of("<startTag>"), Optional.empty());
a
var beforeReplacement = xml.substring(0, xml.indexOf("<startTag>"));
var stringToReplace = xml.substring(xml.indexOf("<startTag>"));
var resultingXml = beforeReplacement + characterReplacer.replaceCharacters(stringToReplace);
==== Especificando solo endAfter
var resultingXml = characterReplacer.replaceCharacters(xml, Optional.empty(), Optional.of("</EndTag>"));
a
int endIndex = xml.indexOf("</EndTag>") + "</EndTag>".length();
var stringToReplace = xml.substring(0, endIndex);
var afterReplacement = xml.substring(endIndex);
var resultingXml = characterReplacer.replaceCharacters(stringToReplace) + afterReplacement;
==== Especificando ambos startFrom y endAfter
var resultingXml = characterReplacer.replaceCharacters(xml, Optional.of("<middleTag>"), Optional.of("</middleTag>"));
to
var beforeReplacement = xml.substring(0, xml.indexOf("<middleTag>"));
int endIndex = xml.indexOf("</middleTag>") + "</middleTag>".length();
var stringToReplace = xml.substring(xml.indexOf("<middleTag>"), endIndex);
var afterReplacement = xml.substring(endIndex);
var resultingXml = beforeReplacement + characterReplacer.replaceCharacters(stringToReplace) + afterReplacement;
=== Migración de configuración obsoleta a configuración actual
==== Obsoleto
character-replacements {
char-to-char-replacements = [
{character = À, replaceWith = A},
{character = ï, replaceWith = i, replaceInDomOnly = true},
]
list-to-char-replacements = [
{list = [È, É, Ê, Ë], replaceWith = E}
]
regex-to-char-replacements = [
{regex = "[\\p{InLatin-1Supplement}]", replaceWith =., replaceInDomOnly = true}
]
}
==== Migrado
character-replacements {
custom-replacer { (1)
enabled = true (2)
char-to-char-replacements = [
{character = À, replaceWith = A},
{character = ï, replaceWith = i, replaceInDomOnly = true},
]
list-to-char-replacements = [
{list = [È, É, Ê, Ë], replaceWith = E}
]
regex-to-char-replacements = [
{regex = "[\\p{InLatin-1Supplement}]", replaceWith =., replaceInDomOnly = true}
]
}
}
-
El
*-to-char-replacementslas propiedades ahora están anidadas bajocustom-replacer -
enabledflag debe estar configurado atruepara que la configuración se cargue
== Migración para servicios utilizando el Human Task Manager
Como se mencionó en el HTM notas de la versión, se ha realizado un cambio en los encabezados incluidos en la tarea cerrada notifications enviado por el servicio.
Si bien los consumidores se han mantenido compatibles hacia atrás, el cambio sí tiene un impacto en el orden de implementación de los servicios de orquestación que hacen uso de la Human Task Manager. Cada servicio que se registra HTM tareas y recibe tarea notifications desde HTM tendrá que realizar un despliegue de actualización antes de HTM se actualiza.
El incumplimiento de esto puede resultar en la tarea notifications siendo ignorado por dichos servicios de orquestación.
== Migraciones para TIPS CSM reemplazo de caracteres
Para preservar el comportamiento heredado de reemplazo de caracteres, debe proporcionar la siguiente configuración en su aplicación.
character-replacements {
lookup-table-replacer = null (1)
custom-replacer { (2)
enabled = true
regex-to-char-replacements = [
{regex = "[^a-zA-Z0-9\\/\\-\\?:().,'+\\s]", replaceWith =., replaceInDomOnly = true}
]
}
}
-
Esto elimina el SEPA configuración de la tabla de conversión
-
Esto restablece el comportamiento de la versión de IPF. 2025.2.0 == Migración para implementaciones de clientes del Servicio de Notificación de Pagos Como se mencionó en las notas de la versión de aom, las implementaciones de clientes pueden requerir una actualización para absorber los cambios en las siguientes clases de dominio del servicio de notificación:
-
PdsObjectContainer-
pdsel tipo de campo cambiado deObjecttoJsonNode. -
La estructura de la
pdsel campo puede ser inferido utilizando eltypeNameyversioncampos. EltypeNamese mapea desde el de la original PDS objeto’s Java nombre de la clase.
-
-
CreditTransferInitiationToPaymentStatusReportMapper-
El
cctiel parámetro ha cambiado deCustomerCreditTransferInitiationV09toJsonNode-
Una instancia de
CustomerCreditTransferInitiationV09puede ser convertido a unJsonNodeusandoSerializationHelper.objectMapper().valueToTree(ccti).
-
-
El tipo de retorno cambió de
CustomerPaymentStatusReportV10toJsonNode-
El devuelto
JsonNodela instancia permanece en elpain. 002.001.10estructura del mensaje. Puede ser convertido a una instancia deCustomerPaymentStatusReportV10usandoSerializationHelper.objectMapper().convertValue(pain002JsonNode, CustomerPaymentStatusReportV10.class)
-
-
-