Documentation for a newer release is available. View Latest

DSL 13 - Uso de conceptos compartidos (Parte uno - Dentro de una solución)

Comenzando

Este paso del tutorial utiliza como punto de partida la solución "add_custom_types" del proyecto.

Si en cualquier momento quieres ver la solución de este paso, la encontrarás en la solución "shared_models_one".

¿Qué es un concepto compartido?

En DSL 9 - Uso de subflujos vimos cómo configurar un subflujo como forma de compartir lógica. Al crear el subflujo, nos permitimos usarlo en varios lugares dentro de nuestro flujo. Sin embargo, ¿y si queremos ir un paso más allá y reutilizar un subflujo no solo dentro de los flujos de nuestro modelo, sino también en otros modelos? Aquí es donde entran los conceptos compartidos. Nos permiten crear módulos que son en sí mismos componentes reutilizables que pueden incorporarse en diferentes proyectos.

Haremos esto extrayendo el subflujo de nuestro modelo existente y moviéndolo a su propio modelo de sanciones, para luego reutilizarlo dentro del modelo del tutorial original.

Configuración del DSL

Extraer la lógica del subflujo

Primero necesitaremos un modelo completamente nuevo donde alojar nuestra lógica de sanciones. Para ello, seleccionamos la solución en el navegador del proyecto y hacemos clic derecho > New > Model. Llamaremos a nuestro modelo 'com.iconsolutions.ipf.tutorial.sanctions'.

Pulsa OK para crear el modelo.

A continuación se nos pedirá seleccionar las dependencias:

Por ahora lo único que queremos añadir es el propio lenguaje flo-lang. Haz clic en la pestaña "Used Languages", luego en el símbolo "+" y añade el lenguaje v2Flo:

Tras seleccionarlo, deberíamos ver:

Con esto, nuestro modelo queda configurado; pulsa "OK" para crearlo y deberías ver un segundo modelo en el navegador:

Pensemos ahora qué compone nuestra lógica de Sanciones. Tenemos:

Sanctions Subflow
Sanctions System
Sanctions Response Codes

Podemos moverlos a nuestro nuevo modelo simplemente seleccionándolos en el navegador y pulsando F6 para mover los nodos. Luego navega y selecciona nuestro nuevo modelo de sanciones y pulsa Refactor.

Cuando se te pida confirmación, pulsa 'Do Refactor'.

Y habremos refactorizado correctamente todos nuestros componentes de sanciones al nuevo modelo.

Lo clave aquí es que la lógica de sanciones ahora existe en un modelo diferente, pero ese modelo se ha compartido con el modelo actual como una dependencia. MPS hizo esto por nosotros al realizar el refactor, pero también es perfectamente posible hacerlo manualmente. Si hacemos clic en ipftutorialmodel en el navegador y pulsamos ALT+ENTER (o clic derecho > "Model Properties") veremos:

Observa que la entrada inferior muestra nuestro modelo de sanciones. Si quisiéramos, podríamos eliminarlo (usando el signo -) y volver a añadirlo (usando el +) buscando por el nombre del modelo. Esta capacidad de compartir un modelo con otro modelo es lo que nos permite proporcionar componentes reutilizables a través de muchos flujos y soluciones.

Top Tip

Si tienes un modelo que sabes que solo va a proporcionar elementos de apoyo (es decir, que no contiene flujos), puedes acelerar ligeramente la generación de tu solución haciendo clic en el modelo, pulsando ALT+ENTER y luego yendo a la pestaña "Advanced" para marcar la casilla "Do Not Generate". ¡No habrá problema si no lo haces!

Con esto termina la parte de DSL.

Implementación en Java

La buena noticia es que no tenemos que hacer gran cosa desde el punto de vista de implementación para adaptarnos a nuestro modelo refactorizado.

Si miramos nuestro archivo IpfTutorialConfig, creamos una entrada para la creación del bean IpfTutorialmodelDomain. Aquí teníamos, por ejemplo:

 .withSanctionsSystemActionAdapter(new SampleSanctionsSystemActionAdapter())

Ahora la implementación del sistema de sanciones se ha movido a nuestro nuevo modelo. Por lo tanto, eliminamos esta línea y en su lugar construimos el nuevo dominio de modelo para el dominio de sanciones:

@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 dominio de sanciones dentro de la aplicación principal del proyecto. En la práctica, sin embargo, podría ocurrir que la implementación del dominio de sanciones se almacene junto a las definiciones del DSL, de modo que aquí bastaría con importar una dependencia para obtener la implementación funcional.

Eso es todo; ahora podemos comprobar el flujo como en pasos anteriores.

Comprobación de nuestra solución

Como siempre, comprobemos ahora que nuestra solución funciona. Arranca la aplicación como antes (las instrucciones están disponibles en Revisión de la aplicación inicial si necesitas recordatorio).

Y luego podemos enviar un pago:

curl -X POST localhost:8080/submit | jq

Si abrimos el pago en la GUI para desarrolladores y miramos el gráfico de nuestro flujo del tutorial (buscar por unit of work id, clic en view, clic en ipf tutorial flow, clic en view graph), veremos:

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 puedes importar accidentalmente el modelo principal del tutorial en el de sanciones. Si haces esto, al intentar ejecutar se te pedirá que añadas los flow mapping ports a ese dominio también. Para solucionarlo, asegúrate de que el dominio de sanciones no tenga esa importación en las propiedades del modelo.

A continuación, iremos un paso más allá y veremos cómo mover nuestro subflujo a una solución diferente en: DSL 14 - Uso de conceptos compartidos (Parte dos - Entre soluciones)