DSL 13 - Uso de conceptos compartidos (Parte Uno - Dentro de una Solución)

Iniciando

El paso del tutorial utiliza la solución "add_custom_types" 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_one"!

¿Qué es un concepto compartido?

En DSL 9 - Uso de Subflujos Examinamos la configuración de un subflujo como una forma de compartir lógica. Al crear el subflujo, nos permitimos utilizarlo en varios lugares dentro de nuestro flujo. Sin embargo, ¿qué sucede si queremos ir un paso más allá y reutilizar un subflujo no solo dentro de los flujos de nuestro modelo, sino también dentro de otros modelos? Aquí es donde entran en juego los conceptos compartidos. Esto nos permite crear módulos que son componentes reutilizables que pueden ser incorporados en diferentes proyectos.

Usted hará esto extrayendo el subflujo de nuestro modelo existente y trasladándolo a su propio modelo de sanciones y luego reutilizándolo dentro del modelo de tutorial de origen.

Configuración de DSL

Extrayendo la lógica del subflujo

Primero que nada, necesitaremos un modelo completamente nuevo en el que alojar nuestra lógica de sanciones. Para hacer esto, seleccionamos la solución en el navegador del proyecto, luego hacemos clic derecho y seleccionamos Nuevo > Modelo. Llamaremos a nuestro modelo 'com.iconsolutions.ipf.tutorial.sanciones'.

Presione ok para crear nuestro modelo.

A continuación, se nos debe solicitar que seleccionemos nuestras dependencias:

Por ahora, todo lo que queremos agregar es nuestro lenguaje flo-lang actual. Así que haga clic en la pestaña "Lenguajes Usados", luego seleccione el símbolo "+" y agregue nuestro lenguaje v2Flo:

Después de seleccionarlo, deberíamos ver:

Ese es nuestro modelo completamente configurado, así que presione "OK" para crear y ahora debería ver aparecer un segundo modelo en el navegador:

Ahora pensemos en lo que compone nuestra lógica de Sanciones, tenemos:

Subflujo de Sanciones
Sistema de Sanciones
Sanciones Response Codes

Podemos mover estos a nuestro nuevo modelo simplemente seleccionándolos en el navegador y luego presionando F6 para mover los nodos. Luego, simplemente navegue hasta nuestro nuevo modelo de sanciones y presione refactorizar.

Cuando se le solicite, confirme la refactorización presionando 'Hacer Refactorización'

Y hemos refactorizado con éxito todos nuestros componentes de sanciones en el nuevo modelo.

Lo clave que debe entender aquí es que la lógica de sanciones ahora existe en un modelo diferente, pero ese modelo ha sido compartido con el modelo actual como una dependencia. MPS hizo esto por nosotros cuando realizamos la refactorización, pero también es perfectamente posible hacerlo manualmente. Si hacemos clic en el ipftutorialmodel en el navegador y presionamos ALT+ENTER (o hacemos clic derecho y luego "Propiedades del Modelo", encontraremos:

Si usted observa aquí, la entrada inferior muestra nuestro modelo de sanciones. Si quisiéramos, podríamos eliminarlo (utilizando el -(Señal) y luego volver a agregarlo (usando el +) y buscando el nombre de nuestro modelo. Es esta capacidad de compartir un modelo con un modelo diferente la que nos permite proporcionar componentes reutilizables en muchos flujos y soluciones.

Consejo Principal

Si tiene un modelo que sabe que solo va a proporcionar modelos de soporte (es decir, no contiene ningún flujo), entonces puede acelerar ligeramente la generación de su solución haciendo clic en el modelo, presionando ALT+ENTER y luego yendo a la pestaña "Avanzado" antes de marcar la casilla "No generar". Sin embargo, no causará problemas si no lo hace.

Eso es todo desde la perspectiva de DSL.

Java Implementación

La buena noticia aquí es que no hay mucho que debamos hacer desde el punto de vista de la implementación para adaptarnos a nuestro modelo recién refactorizado.

Cuando consideramos nuestro archivo IpfTutorialConfig, creamos una entrada para la creación de nuestro IpfTutorialmodelDomain.bean. Aquí tenemos:

 .withSanctionsSystemActionAdapter(new SampleSanctionsSystemActionAdapter())

Ahora la implementación del sistema de sanciones se ha trasladado a nuestro nuevo modelo. Por lo tanto, debe eliminar esta línea y construir en su lugar el nuevo dominio del modelo para el sanctions domain:

@Bean
public SanctionsDomain sanctionsCheckDomain(ActorSystem actorSystem) {
    // All adapters should be added to the domain model
    return new SanctionsDomain. Builder(actorSystem)
            .withSanctionsSystemActionAdapter(new SampleSanctionsSystemActionAdapter())
            .build();
}

Aquí hemos implementado nuestro sanctions domain dentro de nuestra aplicación principal del proyecto. En la práctica, sin embargo, podría ser que la implementación del sanctions domain se almacena junto a las definiciones de DSL para que podamos simplemente importar una dependencia aquí para obtener la implementación funcional.

Eso es todo, y ahora podríamos simplemente verificar el flujo tal como lo hemos hecho en los pasos anteriores.

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 | jq

Y si mencionamos el pago en el Developer GUI y observe 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 a un modelo diferente.

A veces puede importar accidentalmente el core modelo de tutorial en el de sanciones. Si hace esto, cuando intente ejecutar, se le pedirá que añada el flujo.mapping¡puertos en ese dominio también! Para resolver, simplemente asegúrese de que el sanctions domain no tiene la importación en las propiedades del modelo.

A continuación, daremos un paso más y analizaremos la posibilidad de trasladar nuestro subflujo a una solución diferente en:xref:shared_2.adoc[DSL 14 - Uso de conceptos compartidos (Parte Dos - A través de Soluciones)]