Pasos de Migración para IPF-2024.3.0

Pasos de Migración para la Generación de Flujos

Respuesta y Reason codes

Los enumerados de códigos de razón y respuesta ahora se generan SOLAMENTE en el modelo en el que se utilizan. Esto conducirá a dos cambios potenciales:

El existente core definiciones de 'AcceptOrReject’response codes y 'ISOReason Codes’reason codes ahora se proporcionan como implementaciones estándar. Esto significa que el empaquetado de estas clases ahora es fijo y no depende del modelo. Por lo tanto, cualquier uso de estas clases requerirá que la declaración de importación cambie a:
- com.iconsolutions.ipf.core flow.domain.input. Aceptar ORechazar Códigos
- com.iconsolutions.ipf.core flow.domain.input. Códigos De Razón ISO
Si utiliza soluciones de múltiples modelos, asegúrese de que solo se haga referencia a la copia generada en el modelo original dentro del código. Similar a lo anterior, esto puede requerir cambiar el empaquetado de importación.

Importando Otros Modelos

Anteriormente, al importar otros modelos en una solución basada en DSL, esto se lograba añadiendo un bloque en el 'mps’módulo como:'

 <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>3.1.2</version>
    <executions>
        <execution>
            <id>unpack-ipf-business-functions-plugin</id>
            <phase>initialize</phase>
            <goals>
                <goal>unpack</goal>
            </goals>
            <configuration>
                <artifactItems>
                    <artifactItem>
                        <groupId>__groupid of target mps model goes here__</groupId>
                        <artifactId>__solution name of mps model goes here__</artifactId>
                        <version>${icon-business-functions-aggregator.version}</version>
                        <type>zip</type>
                        <overWrite>true</overWrite>
                        <outputDirectory>${plugin_home}</outputDirectory>
                    </artifactItem>
                </artifactItems>
            </configuration>
        </execution>

Ahora el cambio clave es que el campo artifactId ahora está poblado con la constante 'mps' (el nombre del módulo en sí) en lugar de ser el nombre de la solución del proyecto.

Tenga en cuenta que este cambio es APLICABLE únicamente una vez que la solución posterior a la que se hace referencia haya sido actualizada a 2024.3.0 y no depende de la versión del proyecto consumidor.

Migración de Flujo

Una vez actualizado a 2024.3.0, por favor, ejecute cualquier migración que se le solicite realizar al abrir el proyecto.

Pasos de Migración para Conectores

Configuraciones de resiliencia

withResiliencySettings(ResiliencySettings resiliencySettings) ha sido desaprobado y ha sido reemplazado por Function<ResiliencySettings, ResiliencySettings> resiliencySettingsCustomiser el propósito de esto es hacer que la configuración de resiliencia esté disponible para connector operations api.
Antes

 . withResiliencySettings(ResiliencySettings.builder()
 . withMinimumNumberOfCalls(1)
 . withMaxAttempts(3)
 . withRetryOnSendResultWhen(s -> {
 . withRetryOnSendResultWhen(outcome -> {
                            // will retry only in state 1
 var response = ((DeliveryOutcome) s).getResponse();
 var response = ((DeliveryOutcome) outcome).getResponse();
 return FAILURE_REPLY_STRING.equals(response.getReceivedMessage().getMessage().getPayload());
 }
 . build())

Ahora la configuración de resiliencia debe ser devuelta a la customiser. Por ejemplo:

 . withResiliencySettingsCustomiser(settings -> settings.toBuilder()
 . withMinimumNumberOfCalls(1)
 . withMaxAttempts(3)
 . withRetryOnSendResultWhen(s -> {
 . withResiliencyConfig(settings.getResiliencyConfig())
 . withRetryOnSendResultWhen(outcome -> {
                            // will retry only in state 1
 var response = ((DeliveryOutcome) s).getResponse();
 var response = ((DeliveryOutcome) outcome).getResponse();
 return FAILURE_REPLY_STRING.equals(response.getReceivedMessage().getMessage().getPayload());
 }
 . build())

La configuración de resiliencia se creará automáticamente y se pasará como el argumento de configuración para su uso en otros lugares.

Conectores de Directorio Local y transporte

FileHealthCheckConfig la configuración que ahora puede ser especificada por archivo de transporte individual. Esto puede lograrse utilizando LocalDirectoryConnectorTransport.builder() y cualquiera de:
- incluyendo fileCheckConfig bloque de configuración en el archivo principal de configuración de transporte, o-proporcionando directamente custom ruta raíz a FileHealthCheckSettings create(ClassicActorSystemProvider actorSystem, String configRootPath) y incluyéndolo en el constructor al llamar .withFileHealthCheckSettings(FileHealthCheckSettings settings) método en el constructor
LocalDirectoryConnectorTransport(ActorSystem actorSystem, Nombre de la cadena, FileIngestionConfiguration fileIngestionConfiguration) is deprecated, and it will be removed in the next release. Please use ` Utilice LocalDirectoryConnectorTransport.builder() en su lugar.
LocalDirectoryTransportConfiguration(String configRootPath, Config config) está obsoleto y se eliminará en la próxima versión. Por favor, utilice LocalDirectoryTransportConfiguration(ClassicActorSystemProvider actorSystem, String configRootPath) en su lugar
static FileHealthCheckSettings createDefault(Config config) está obsoleto y se eliminará en la próxima versión. Por favor, utilice static FileHealthCheckSettings create(ClassicActorSystemProvider actorSystem, String configRootPath) en su lugar
withTransportConfiguration método en LocalDirectoryConnectorTransport. Builder está marcado como obsoleto y scheduled para la eliminación
LocalDirectoryConnectorTransport ahora filtrará los archivos que están siendo procesados de sus encuestas, lo que permitirá interval debe establecerse de manera segura a duraciones más cortas que los tiempos de procesamiento esperados — segundos en lugar de horas. === Desaprobación de directorio mapping desde MongoDB directory-mapping colección

Directorio mapping from MongoDB directory-mapping la colección será desaprobada y trasladada a la ipf.file-ingestion.directory-mapping HOCON configuración que se utilizará para el directorio mappings. A partir de ahora, no se permite tener un ingestor de archivos sin un apropiado directoryId in directory-mappings.

Pasos de migración

Realice una copia de seguridad de todos los datos de Mongo.directory-mapping colección.
Para cada custom ingester asegúrese de agregar datos de documentos de Mongo relacionados desde directory-mappings colección al archivo.conf de los ingesters.
Reinicie la aplicación y verifique si no hay advertencias en el registro con el mensaje Missing required HOCON configuration: ipf.file-ingestion.directory-mappings.
Asegúrese de que el registro no contenga advertencias como: .Mongo directory-mappings documents value doesn’t exist in Hocon configuration. .Mismatch found for Mongo directory-mappings documents value and Hocon configuration.
Eliminar Mongo directory-mapping colección si se cumplen los pasos anteriores.

Http Conectores y transportes

HttpConnectorTransport<T>. Builder debe utilizar únicamente el nombre, el sistema de actores y la ruta raíz de configuración al construir transportes.
- Utilice <T> Builder<T> builder(String name, ClassicActorSystemProvider actorSystem, String configRootPath).
HttpReceiveConnectorTransportFactory está obsoleto y será eliminado, así que utilice HttpReceiveConnectorTransport. Builder en su lugar.
withTransportConfiguration método en HttpConnectorTransport<T>. Builder y HttpReceiveConnectorTransport. Builder está marcado como obsoleto y scheduled para la eliminación
Utilice status-codes-treated-as-errors para definir códigos de estado que son errores y no pueden ser ignorados. Estos códigos de estado se utilizarán al construir las predicados treatErrorResponseAsFailureWhen.
Utilice <REQ_D, REQ_T, REP_D, REP_T> Builder<REQ_D, REQ_T, REP_D, REP_T> builder(String name, String configRootPath, ClassicActorSystemProvider actorSystem) al construir Solicitud-Respuesta Send connector s.

JMS Conectores y transportes

JMS Connector Transport el constructor debe utilizar solo el nombre, el sistema de actores, la ruta raíz de configuración y connection factory.
JmsConnectorTransportFactory está obsoleto y será eliminado, así que utilice JmsConnectorTransport. Builder en su lugar.
JmsReceiveConnectorTransportFactory está obsoleto y será eliminado, así que utilice JmsReceiveConnectorTransport. Builder en su lugar.
withTransportConfiguration método en JmsAckReceiveConnectorTransport. Builder,JmsConnectorTransport. Builder y JmsReceiveConnectorTransport. Builder está marcado como obsoleto y scheduled para la eliminación

Kafka Conectores y transportes

Al construir String-String Kafka transporte,KafkaConnectorTransport,KafkaReceiveConnectorTransport y KafkaAckReceiveConnectorTransport, utilice stringBuilder y proporcione solo el nombre, el sistema de actores y la ruta raíz de configuración.

Pasos de Migración para Icon Akka Complementos

Akka Descubrimiento MongoDB

akka.discovery.akka-mongodb.uri,akka.discovery.akka-mongodb.set-ssl-context y akka.discovery.akka-mongodb.ssl-context ahora se establecerá como su ipf.mongodb contrapartes (ipf.mongodb.url,ipf.mongodb.set-ssl-context y ipf.mongodb.ssl-context, respectivamente) y ya no es necesario configurarlos manualmente si se proporcionan los contrapartes.

Akka Arrendamiento MongoDB

akka.coordination.lease.mongodb.url,akka.coordination.lease.mongodb.set-ssl-context y akka.coordination.lease.mongodb.ssl-context ahora se establecerá como su ipf.mongodb contrapartes (ipf.mongodb.url,ipf.mongodb.set-ssl-context y ipf.mongodb.ssl-context, respectivamente) y ya no es necesario configurarlos manualmente si se proporcionan los contrapartes.

Akka Persistence MongoDB

iconsolutions.akka.persistence.mongodb.read-concern`ha sido eliminado, utilice `readConcernLevel opción en la cadena de conexión para establecer la preocupación de lectura.

iconsolutions.akka.persistence.mongodb.url,iconsolutions.akka.persistence.mongodb.set-ssl-context y iconsolutions.akka.persistence.mongodb.ssl-context ahora se establecerá como su ipf.mongodb contrapartes (ipf.mongodb.url,ipf.mongodb.set-ssl-context y ipf.mongodb.ssl-context, respectivamente) y ya no es necesario configurarlos manualmente si se proporcionan los contrapartes.

Pasos de Migración para IPF Processing Data Versión 2

Todo core IPF applications son capaces de consumir datos tanto de la V2 como de la V1 IPF Processing Data modelo. Por defecto, todos IPF Processing Data Los complementos de salida exportarán datos utilizando el modelo de datos V2. Si usted tiene alguna custom aplicaciones que consumen de IPF Processing Data, se deben seguir los siguientes pasos.

Configure las aplicaciones de salida para utilizar V1.

Sus aplicaciones de consumo no pueden manejar el modelo de datos V2, por lo tanto, por ahora debe continuar exportando utilizando el modelo de datos V1. Para todas las aplicaciones que utilicen el IPF Processing Data Plugins de salida, configure ipf.processing-data.egress.schema-version = 1 para continuar produciendo datos utilizando el modelo de datos V1.

Actualizar aplicaciones consumidoras

Actualice cada aplicación que consuma de IPF Processing Data para que puedan manejar tanto el modelo de datos V2 como el V1. Para más información, consulte el consume IPF Processing Data guía.

Configure las aplicaciones de salida para utilizar V2.

Una vez que todas sus aplicaciones consumidoras sean capaces de manejar tanto el modelo de datos V2 como el V1, puede actualizar de manera segura sus productores para exportar mensajes utilizando el modelo de datos V2. Esto se puede hacer configurando ipf.processing-data.egress.schema-version = 2

Event Corrección de resolución de ID de procesador en Egress Journal Processor

Descripción del Problema

En versiones anteriores a 2024.3, el ipf-processing-data-egress-journal-processor el módulo tenía una resolución inconsistente de la event-processor.id propiedad de configuración. Dependiendo de Java resolución del classpath en tiempo de ejecución, el event el ID del procesador se resolvería a uno de los siguientes EventProcessor(valor incorrecto) o IpfProcessingDataEventProcessor(valor previsto).

Resolución

Versión 2024.3 corrige esta inconsistencia. La event El ID del procesador ahora se resolverá correctamente a IpfProcessingDataEventProcessor en todos los casos.

Impacto de la Migración

Servicios que anteriormente resolvían a EventProcessor requiere cambios de configuración durante el 2024.3 actualice para prevenir su Egress Journal Processor s de reprocesar todo el event diario.

Determinando Si Se Requiere Acción

Debe realizar esta verificación para cada aplicación de orquestación, de lo contrario, corre el riesgo de tener problemas en producción.

Puede verificar si su aplicación necesita cambios de configuración utilizando cualquiera de estos métodos.

Para usuarios con acceso a la red a las instancias de servicio, ejecute:

curl -s localhost:8080/actuator/info \
   | grep -o -P '"event.processor.id":"EventProcessor"'

Para usuarios con MongoDB acceso:

mongo <connection_params_omitted> --eval\
  'db.mongoOffset.find({"_id.eventProcessorId":"EventProcessor"})'

Cambio de configuración requerido

Si cualquiera de los métodos de verificación devuelve resultados, añada la siguiente línea a su servicio de application.conf archivo:

event-processor.id = EventProcessor