DSL 14 - Uso de conceptos compartidos (Parte Dos - A través de Soluciones)
|
Iniciando
El paso del tutorial utiliza la solución "shared_models_one" del proyecto como su punto de partida. Si en algún momento desea ver la solución a este paso, ¡esta se puede encontrar en la solución "shared_models_two"! |
Un resumen rápido
En DSL 13 - Uso de conceptos compartidos (Parte Uno - Dentro de una Solución), hemos extraído nuestra lógica de sanciones en un modelo separado. En la práctica, sin embargo, la mayoría de los proyectos se configurarán como un servicio que proporciona una solución única. Por lo tanto, ahora debemos considerar la posibilidad de importar modelos que se encuentren en soluciones reutilizables separadas.
La Solución de Sanciones
Para este tutorial, utilizaremos un módulo de sanciones preexistente. Este módulo de sanciones contiene exactamente la misma lógica que construimos en las secciones anteriores de este tutorial, simplemente está empaquetado como una solución reutilizable independiente.
El módulo de sanciones fue construido de la misma manera que el tutorial en sí puede ser a través del uso de la scaffolder.
Importando el Módulo
La importación del módulo se realiza dentro de las secciones de plugin del pom en nuestra aplicación.
Abramos nuestro proyecto principal de tutorial en Intellij y luego, si usted abre el pom de la mps carpeta (domain-root/mps/pom.xml) veremos que ya existe una entrada para el maven-plugin de dependencia como sigue:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3. 1. 2</version>
<executions>
<execution>
<id>copy</id>
....Ahora, todo lo que necesitamos hacer es añadir una sección para desglosar las sanciones.mps módulo en nuestra aplicación. Para hacer esto, añadimos una nueva ejecución de la siguiente manera:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>3. 1. 2</version>
<executions>
<execution>
<id>unpack-sanctions-plugin</id>
<phase>initialize</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>com.iconsolutions.ipf.tutorial.sanctions.domain</groupId>
<artifactId>mps</artifactId>
<version>${sample-sanctions.version}</version>
<type>zip</type>
<overWrite>true</overWrite>
<outputDirectory>${plugin_home}</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
<execution>
<id>copy</id>Los elementos clave a notar aquí son el groupId, artifactId y version.- es igual que cualquier otro Maven dependency(tenga en cuenta que el artifactId aquí es el nombre de la solución).
Eso es todo lo que necesitamos agregar; si quisiéramos añadir más soluciones, simplemente agregaríamos más bloques de ejecución, asegurándonos de que para cada uno hayamos ingresado el groupId, artifactId y versión correctos, tal como lo haríamos para un normal. Maven dependency.
Uso del Modelo Remoto
Ahora que hemos configurado nuestra aplicación para importar el modelo, utilicémoslo. Primero, reconstruya la aplicación para asegurarse de que el módulo se haya integrado correctamente.
mvn clean installUna vez completado, abra MPS. Lo primero que haremos es eliminar el modelo de sanciones existente. Para ello, simplemente haga clic en él en el explorador y presione eliminar. Debería aparecer un cuadro de confirmación de eliminación:
Haga clic en el botón de eliminar archivos, ya que no necesitaremos los archivos subyacentes y luego presione "Eliminar".
Si ahora observa el flujo, verá que tenemos errores donde llamamos al subflujo de sanciones porque ya no tiene uno con el que trabajar.
Para resolver esto, simplemente presione Ctrl+R dos veces (o asegúrese de que la casilla esté marcada) y luego busque y seleccione el Subflujo de Sanciones. Debería ver aquí que esta vez proviene del modelo de reutilización:
Ahora debería ver el error resolverse a medida que comienza a extraer el nuevo modelo importado. Si los errores no se resuelven automáticamente, reemplace las referencias al antiguo modelo con las del nuevo modelo importado.
Java Implementación
El arduo trabajo en esta parte de nuestra serie de tutoriales se realizó todo arriba en el MPS dependencias y configuración de compilación. Desde un java punto de vista de implementación, la única diferencia en esta etapa es que el código de dominio para sanciones ha sido generado en las funciones preexistentes. Por lo tanto, aquí podemos simplemente agregar las dependencias a la ipf-tutorial-app pom.xml para aquellos, tal como lo hicimos antes:
<dependency>
<groupId>com.iconsolutions.ipf.tutorial.sanctions.domain</groupId>
<artifactId>domain</artifactId>
<version>${sample-sanctions.version}</version>
</dependency>
<dependency>
<groupId>com.iconsolutions.ipf.tutorial.sanctions.domain</groupId>
<artifactId>sampleapp</artifactId>
<version>${sample-sanctions.version}</version>
</dependency>
La nueva importación de la utilidad común tiene una estructura de paquete ligeramente diferente, por lo que deberá reorganizar las importaciones para las clases SanctionsDomain en su clase de configuración del tutorial. |
Aquí hemos añadido las dependencias para el dominio y los proyectos de la aplicación de muestra directamente. Sin embargo, también podríamos tener un módulo separado que incluya estas Y proporcione una implementación para ellas. De hecho, el módulo de tutorial de sanciones hace esto con su paquete ipf-tutorial-sanctions-adapters. Si importáramos esto, podríamos eliminar nuestra declaración del SanctionsDomain.bean y simplemente utilice una solución completamente preempaquetada (tenga en cuenta que hacerlo aquí también requeriría ejecutar el Simulador de Sanciones del cual depende, por lo que se excluye por ahora). |
Verificando nuestra Solución
Como es habitual, ahora verifiquemos que la solución funcione. Inicie la aplicación como se indicó anteriormente (instructions están disponibles en Revisando la solicitud inicial si necesita un repaso!)
Y luego podríamos enviar un pago:
curl -X POST localhost:8080/submit | jqY si mencionamos el pago en el Developer GUI y consulte el gráfico de nuestro flujo de tutorial (search by unit of work id, haga clic en ver, haga clic en el flujo del tutorial de ipf, haga clic en ver gráfico) entonces vemos:
Si comparamos esto con el gráfico de DSL 9 - Uso de Subflujos, podemos ver que todo es igual que antes, y hemos extraído con éxito nuestro subflujo de Sanciones a un modelo diferente que es completamente independiente del modelo Ipftutorial.