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.

  1. 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 ProcessingContext Las claves de encabezado han sido eliminadas. Debe reemplazar todas las ocurrencias de:

    • com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. UOW_ID_HEADER con com.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. UNIT_OF_WORK_ID_CONTEXT_KEY clave

    • com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. PROCESSING_ENTITY_HEADER with com.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. PROCESSING_ENTITY_CONTEXT_KEY clave

    • com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. ASSOCIATION_ID_HEADER con com.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. ASSOCIATION_ID_CONTEXT_KEY clave

    • com.iconsolutions.ipf.core.shared.domain.context. ProcessingContext. REQUEST_ID_HEADER con com.iconsolutions.ipf.core.shared.domain.context.propagation. ContextPropagationSettings. CLIENT_REQUEST_ID_CONTEXT_KEY clave

  • MessageHeaders.fromProcessingContext() el método ha sido eliminado, usted debe usar ProcessingContextUtils.toMap() en su lugar:

    MessageHeaders headers = new MessageHeaders(ProcessingContextUtils.toMap(processingContext));
  • MessageHeaders.toProcessingContext() el método ha sido eliminado, debe utilizar ProcessingContextUtils.fromMap() en su lugar:

    ProcessingContext processingContext = ProcessingContextUtils.fromMap(messageHeaders.getHeaderMap());
  • ProcessingContextUtils. ProcessingContextHeaderExtractor ha sido trasladado a una clase independiente:`com.iconsolutions.ipf.core.connector.common. ProcessingContextHeaderExtractor`. Reemplace

    return 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.enabled propiedad de configuración para ipf.connector.correlation.create-indexes.

  • Renombre cualquier uso de ipf.connector.correlation-timestamp-field-name propiedad de configuración para ipf.connector.correlation.timestamp-field-name.

  • Renombre cualquier uso de ipf.connector.correlation-expiry propiedad de configuración para ipf.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.direct-debit.collect-and-settle.technical.enabled

csm.direct-debit.technical.enabled

csm.kafka.consumer.topics.direct-debit.collect-and-settle.technical-response

csm.kafka.consumer.topics.direct-debit.technical-response

csm.jms.direct-debit.collect-and-settle.technical-response.queue

csm.jms.direct-debit.technical-response.queue

csm.direct-debit.collect-and-settle.creditor.enabled

csm.direct-debit.creditor.enabled

csm.jms.direct-debit.collect-and-settle.creditor-to-csm.queue

csm.jms.direct-debit.creditor-to-csm.queue

csm.jms.direct-debit.collect-and-settle.csm-to-creditor.queue

csm.jms.direct-debit.csm-to-creditor.queue

csm.kafka.consumer.direct-debit.collect-and-settle.csm-to-creditor

csm.kafka.consumer.direct-debit.csm-to-creditor

csm.kafka.producer.direct-debit.collect-and-settle.creditor-to-csm

csm.kafka.producer.direct-debit.creditor-to-csm

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

csm.direct-debit.collect-and-settle.technical.enabled

csm.direct-debit.technical.enabled

csm.kafka.producer.topics.direct-debit.collect-and-settle.technical-response

csm.kafka.producer.topics.direct-debit.technical-response

csm.jms.direct-debit.collect-and-settle.technical-response.queue

csm.jms.direct-debit.technical-response.queue

csm.direct-debit.collect-and-settle.creditor.enabled

csm.direct-debit.creditor.enabled

csm.jms.direct-debit.collect-and-settle.creditor-to-csm.queue

csm.jms.direct-debit.creditor-to-csm.queue

csm.jms.direct-debit.collect-and-settle.csm-to-creditor.queue

csm.jms.direct-debit.csm-to-creditor.queue

csm.kafka.producer.direct-debit.collect-and-settle.csm-to-creditor

csm.kafka.producer.direct-debit.csm-to-creditor

csm.kafka.consumer.direct-debit.collect-and-settle.creditor-to-csm

csm.kafka.consumer.direct-debit.creditor-to-csm

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
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
<groupId>org.jvnet.jaxb</groupId>
<artifactId>jaxb-maven-plugin</artifactId>

Este es el JAXB Maven Plugin

<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics</artifactId>
<version>${jaxb2-basics.version}</version>
<groupId>org.jvnet.jaxb</groupId>
<artifactId>jaxb-plugins</artifactId>
<version>${jaxb-plugins.version}</version>

Esto suele ser un JAXB Maven Plugin dependencia

<groupId>org.jvnet.jaxb2_commons</groupId>
<artifactId>jaxb2-basics-annotate</artifactId>
<version>${jaxb2-basics-annotate.version}</version>
<groupId>org.jvnet.jaxb</groupId>
<artifactId>jaxb-plugin-annotate</artifactId>
<version>${jaxb-plugin-annotate.version}</version>

Esto es generalmente un JAXB Maven Plugin dependencia

<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>${jaxb.version}</version>
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>${jaxb-api.version}</version>

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

http://java.sun.com/xml/ns/jaxb

https://jakarta.ee/xml/ns/jaxb

http://annox.dev.java.net

urn:jaxb.jvnet.org:annox

http://jaxb2-commons.dev.java.net/basic/inheritance

urn:jaxb.jvnet.org:plugin:inheritance

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.

2025 3 0 migrate ipfstudio

Habilitando dentro de Maven

Para habilitar estas funciones como parte de maven Para construir, usted necesita hacer lo siguiente.

  1. Añada un maven propiedad

  2. 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)

  3. 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.

2025 3 0 migrate pom

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

  1. Añadiendo com.ipf.make.postProcessing como una var

  2. agregando -Dcom.ipf.make.postProcessing=${com.ipf.make.postProcessing} como generador jvm arg

E.j.

2025 3 0 migrate buildscript

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@

Dominio

Dentro del directorio de dominio:

En lugar de:

com.iconsolutions.ipf.core.flow:flo-domain-tile:@project.version@

Ahora use:

com.iconsolutions.ipf.core.flow:flo-domain-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:

  1. Desactive el/los sistema(s) de llamadas.

  2. Desactive el sistema de Procesador de Entradas de Pago.

  3. Actualice el sistema de Procesador de Entradas de Pago

  4. 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}
    ]
  }
}
  1. El *-to-char-replacements las propiedades ahora están anidadas bajo custom-replacer

  2. enabled flag debe estar configurado a true para 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}
    ]
  }
}
  1. Esto elimina el SEPA configuración de la tabla de conversión

  2. 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

      • pds el tipo de campo cambiado de Object to JsonNode.

      • La estructura de la pds el campo puede ser inferido utilizando el typeName y version campos. El typeName se mapea desde el de la original PDS objeto’s Java nombre de la clase.

    • CreditTransferInitiationToPaymentStatusReportMapper

      • El ccti el parámetro ha cambiado de CustomerCreditTransferInitiationV09 to JsonNode

        • Una instancia de CustomerCreditTransferInitiationV09 puede ser convertido a un JsonNode usando SerializationHelper.objectMapper().valueToTree(ccti).

      • El tipo de retorno cambió de CustomerPaymentStatusReportV10 to JsonNode

        • El devuelto JsonNode la instancia permanece en el pain. 002.001.10 estructura del mensaje. Puede ser convertido a una instancia de CustomerPaymentStatusReportV10 usando SerializationHelper.objectMapper().convertValue(pain002JsonNode, CustomerPaymentStatusReportV10.class)