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 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 "docs", "dominio", "bibliotecas-externas", " mps ", "sampleapp" y "test" módulos, 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 iconos 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. Esto maven se espera que la compilación 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.

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

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

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 todo aggregate functions y enriquecedores de entrada al nuevo estilo Mapping Functions. La siguiente tabla define los cambios esperados:

Descripción de la Clase

Nombre Antiguo

Nuevo Nombre

Aggregate Function Puerto de 's

Your FlowAggregate FunctionPort

Your FlowMappingPort

Aggregate Function Parámetros

Su Nombre De Función Agregada Para Flujo Sus Parámetros De Función Agregada__

Su Nombre De Función Agregada Para Flujo Sus Parámetros De Mapeo__

Aggregate Function Salida

Su Nombre De Función Agregada Para Flujo Su FlujoSalida De Función Agregada

Su Nombre De Función Agregada Para Flujo Su FlujoSalida De Mapeo

Puerto del Enriquecedor de Entrada

Your FlowInput EnricherPort

Your FlowMappingPort

Parámetros del Enriquecedor de Entrada

Su Entrada Enriquecedora Nombre Para Flujo Su FlujoParámetros De Enriquecedora De Entrada

Su Nombre De Enriquecedor De Entrada Para Flujo Su FlujoParámetros De Mapeo

Entrada Enriquecedora Salida

Your Input Enricher Name For Flow Your FlowInput Enricher Output

Su Entrada Enriquecedora Nombre Para Flujo Su FlujoSalida De Mapeo

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 un aggregate function y un enriquecedor de entrada desde el punto de vista del código generado. Por lo tanto, si su flujo tenía tanto un aggregate function y un enriquecedor de entradas, 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 método withXXX tanto para la agregación como para el enriquecimiento de entrada, 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 su external domains 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.

Aquí lo clave que debe entender es que los elementos en ModelA se generan dentro del ámbito 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.