Pasos de migración para IPF-2023.4.0

Actualizaciones de versión

Migración de DSL

Deberá migrar a la nueva versión del DSL antes de poder utilizar la nueva versión en su aplicación.

Para migrar de 2023.3.0, por favor realice los siguientes pasos:

  • Actualice su versión de la lista de materiales (BOM) a la nueva versión de lanzamiento.2023.4.0:

<parent>
    <groupId>com.iconsolutions.ipf</groupId>
    <artifactId>ipf-release-core-bom</artifactId>
    <version>2023.4.0</version>
</parent>

  • Actualice todas las versiones de flo dentro de las carpetas de dominio a 2.2.23. Específicamente, en los módulos "docs", "domain", "external-libraries", "mps", "sampleapp" y "test", actualice para que se vea como:

<parent>
    <groupId>com.iconsolutions.ipf.core.flow</groupId>
    <artifactId>flo-starter-<modulename></artifactId>
    <version>2.2.23</version>
    <relativePath></relativePath>
</parent>

Si utiliza alguno de los íconos AOM’s (ver Detalles de AOM), entonces debe agregar el nuevo aom bom como una dependencia:

<dependency>
    <groupId>com.iconsolutions.ipf</groupId>
    <artifactId>ipf-release-aom-bom</artifactId>
    <version>2023.4.0</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

  • Ejecute un Maven construya para recuperar todas las últimas dependencias. Se espera que esta construcción de maven falle porque el dominio del modelo de prueba no existirá. Debe recibir un error similar a:

package your.package.structure.testfw does not exist

  • Abra su proyecto en MPS y se le debe solicitar que migre su solución, haga clic Migrate.

2023 4 migrate

  • A continuación, si usted abre su solución de compilación en el YourApplication.build proyecto que debe ver el de.itemis.mps.extensions entrada en rojo. Simplemente elimine esta línea.

2023 4 itemis build

  • Ahora en el panel del navegador debe ver que se requiere la regeneración del script de construcción:

2023 4 regeneration

  • Haga clic derecho y seleccione Rebuild Model 'Your Model Name'

  • Ahora reconstruya utilizando maven y su proyecto debería compilar correctamente.

Migración de Código Generado

Puerto de Iniciación de Entrada

El DSL ahora hace referencia al modelo en el que existe el puerto de iniciación de entrada generado.

Por lo tanto, la utilidad de migración ejecutada en la sección DSL habrá convertido el InputInitiationPort to YourModelNameInitiationPort.

Aggregate Functions& Enriquecedores de Entrada

Las capacidades mejoradas, tal como se describen en la sección de resumen para mapping las capacidades han llevado a algunos cambios en la nomenclatura del código generado.

La utilidad de migración ejecutada en la sección DSL habrá convertido todas las funciones de agregación y los enriquecedores de entrada al nuevo estilo.Mapping Functions. La siguiente tabla define los cambios esperados:

Descripción de la Clase

Nombre Antiguo

Nuevo Nombre

Puerto de la Función Agregada

Your FlowAggregate FunctionPort

Your FlowMappingPort

Parámetros de Función Agregada

Your Aggregate Function Name For Flow Your FlowAggregate Function Parameters

Your Aggregate Function Name For Flow Your FlowMapping Parameters

Salida de Función Agregada

Your Aggregate Function Name For Flow Your FlowAggregate Function Output

Your Aggregate Function Name For Flow Your FlowMapping Output

Puerto del Enriquecedor de Entrada

Your FlowInput EnricherPort

Your FlowMappingPort

Parámetros del Enriquecedor de Entrada

Your Input Enricher Name For Flow Your FlowInput Enricher Parameters

Your Input Enricher Name For Flow Your FlowMapping Parameters

Entrada Enriquecedora Salida

Your Input Enricher Name For Flow Your FlowInput Enricher Output

Your Input Enricher Name For Flow Your FlowMapping Output

Además, la migración al nuevo estilo Mapping Functions también cambiará los nombres de los paquetes en los que ahora residen las clases mencionadas anteriormente. Por ejemplo:

  • com.your.project.model_name.flow_name.aggregatefunction. YourAggregateFunctionNameForFlowYourFlowAggregateFunctionOutput;

se convierte

  • com.your.project.model_name.mapping. YourAggregateFunctionNameForFlowYourFlowMappingOutput;

No hay distinción ahora entre una función de agregado y un enriquecedor de entrada desde el punto de vista del código generado. Por lo tanto, si su flujo tenía tanto una función de agregado como un enriquecedor de entrada, anteriormente usted habría definido un puerto para ambos, mientras que ahora se generará un único puerto que contendrá todos sus métodos.

El YourFlowDomain La clase, por lo tanto, necesitará ser actualizada. Mientras que anteriormente tendría un withXXX método para el enriquecimiento tanto de agregados como de entradas, ahora tendrá un único método para el nuevo mapping puerto.

Modelos Remotos

Un cambio importante está ahora presente al utilizar modelos remotos en MPS, así que, por ejemplo, si define sus flujos en un modelo y sus dominios externos en un modelo separado.

Anteriormente, todo el código generado se generaba desde el punto de vista del modelo basado en flujos. Esto significaba que la implementación de la lógica del dominio externo debía realizarse en la implementación del flujo.

Ahora, sin embargo, el código se genera de acuerdo con el modelo que se ha definido. Imagine que tiene dos modelos, Modelo A que contiene un dominio externo llamado 'EXTERNAL_DOMAIN' y Modelo B que contiene un flujo que utiliza el dominio externo.

2023 4 modelreuse

Aquí lo clave que debe entender es que los elementos en ModelA se generan dentro del alcance del modelo A y de manera similar para ModelB. Esto significa que ahora habrá dos clases de dominio de modelo separadas y AMBAS deben ser implementadas para que el flujo funcione.

El principal beneficio de este cambio es que ahora podemos empaquetar y reutilizar modelos remotos junto con sus implementaciones.