Documentation for a newer release is available. View Latest

DSL 10 - Llamar a otros flujos

Comenzando

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

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

Escenario

Hasta ahora solo hemos considerado un único flujo, que recibe un pacs.008 y realiza algunas acciones sobre él. Podríamos considerarlo un flujo de "ejecución". Ahora veamos cómo podríamos hacer la "iniciación" y crear un segundo flujo que:

  1. Reciba un pain.001

  2. Convierta el pain.001 en un pacs.008

  3. Reenvíe el pacs.008 al flujo de ejecución

  4. Determine el resultado del flujo de ejecución y termine de forma apropiada

Diagram

Lo clave a considerar aquí es cómo nos comunicamos de flujo a flujo. En este paso solo veremos flujos que se despliegan juntos; es decir, cuando ambos flujos están definidos en el mismo modelo.

Aunque esta sección trata de cómo usar el propio DSL para configurar la comunicación flujo-a-flujo, es importante darse cuenta de que, en esencia, flujo-a-flujo es efectivamente un dominio llamando a otro y, como tal, sería igual de válido (y posible) modelar la interacción entre flujos usando dominios externos.

Configuración del DSL

Añadir el flujo de iniciación

Añadamos un flujo nuevo haciendo clic derecho en el modelo y seleccionando New  v2Flo  Flow. Luego, en el editor del flujo, configuraremos:

  • Un nombre: "Initiation Flow"

  • Una descripción: "Initiates payment processing"

  • Un estado nuevo para representar el rechazo del flujo llamado "Rejected". Debe tener el código global REJECTED

Cuando esté listo, debería verse como:

calling1 create flow

Ahora bajemos a "Initiation Behaviour". Según lo requerido, necesitamos recibir un pain001. Lo primero que haremos aquí es usar los tipos de iniciación preempaquetados importándolos en nuestra solución.

Para hacerlo, pulsa Ctrl+R, escribe 'ISO Initiation Types' en la búsqueda y selecciona la entrada resultante.

Al importar modelos a tu solución usando este método, podrías importar sin querer algún modelo que no pretendías, lo que puede provocar que tu aplicación no arranque con errores como:

An action processor has not been provided for external domain INITIATION_DOMAIN in model INITIATION

Para eliminar esto (y cualquier otro modelo no usado), haz clic en ipftutorialmodel en la ventana de proyecto de la izquierda, pulsa Alt+Enter y elimina cualquier elemento en gris claro (indicando que no se usa) de la lista de modelos importados, seleccionándolo y pulsando el icono de 'menos' (o el atajo Alt+Delete). Alternativamente, puedes eliminar todos los imports no usados de una vez pulsando el botón "Remove unused model imports" remove unused model imports icon.

Si vamos al Initiation Behaviour del nuevo flujo, deberíamos poder seleccionar "Payment Initiation"; hagámoslo.

calling1 init behaviour 1

Integrar los flujos

Ahora integremos los dos flujos. Para ello necesitamos usar otro pseudoestado, igual que en DSL 5 - Uso de una decisión. En este caso es un "Flow State". Así que, en "Move To State", selecciona "Create Flow State".

Llamaremos a nuestro Flow State "Call Execution".

Luego, en perform action, seleccionaremos "Call Flow" y escogeremos nuestro flujo ipftutorial. Cuando lo hayas hecho, debería verse así:

calling1 init behaviour 2

Ahora vemos que la llamada al flujo aparece subrayada como error. Si validas el flujo (ALT+ENTER y luego Validate Flow) veremos:

calling1 validation errors

Trabajemos cada uno. Primero vemos "Called Flow requires missing data: [Customer Credit Transfer]". Esto es porque nuestro flujo de ejecución necesita que se le proporcione un objeto de transferencia de crédito, pero en este momento el Initiation Flow no lo tiene. Para solucionarlo, crearemos una nueva función de mapeo para pasar de pain.001 a pacs.008. Si necesitas un recordatorio sobre funciones de mapeo, revisa DSL 6 - Funciones de mapeo. Intenta añadir esta función de mapeo ahora. Cuando estés listo, compara con la solución de abajo:

calling1 mapping function

Luego necesitaremos añadir la función de mapeo a nuestro Initiation Behaviour. En este caso la usaremos como un input enricher:

calling1 init behaviour 3

Si ahora revalidamos el flujo, ya no deberíamos ver el error de datos faltantes.

Los problemas de estados se deben a que aún no hemos referenciado las definiciones de estado Complete y Rejected en el Initiation Flow. Para arreglarlo, comenzaremos añadiendo un Event Behaviour cuando estamos en el estado "Call Execution" que definimos en el Initiation Behaviour. Primero añadimos el estado Complete en la sección "Move To State" del Event Behaviour y luego, en "For Event", seleccionamos el tipo especial "On Flow State", que nos da una forma de manejar los estados publicados por el flujo de ejecución (similar a cómo manejamos los estados de finalización de Subflow en DSL 9 - Uso de subflujos). Tras implementar este tipo de evento, seleccionamos Ipftutorialflow (V2) en el "When". Notarás que al intentar elegir una opción para "reaches" no hay opciones disponibles.

calling1 event behaviour 1

Esto es porque, a diferencia de los subflujos, debemos seleccionar explícitamente qué estados del flujo llamado (el flujo de ejecución) queremos publicar y hacer disponibles para cualquier flujo llamante (el Initiation Flow).

En este caso solo queremos poner a disposición del Initiation Flow los estados terminales del flujo de ejecución, así que marcamos la opción "Is Publishing?" para los estados Complete, Rejected y Timed Out en el flujo de ejecución:

calling1 exec state definitions

Orquestación y continuación

Una vez publicados los estados, completamos los Event Behaviours en el Initiation Flow para reaccionar a esos estados:

  • Si el flujo de ejecución alcanza Complete, movemos el Initiation Flow a Complete

  • Si el flujo de ejecución alcanza Rejected o Timed Out, movemos el Initiation Flow a Rejected

Esto permite que el flujo de iniciación actúe como orquestador del proceso end-to-end.

Implementación en Java

Como de costumbre, empezaremos regenerando la base de código:

mvn clean install

A nivel de implementación, la llamada de un flujo a otro se traduce en puertos/operaciones generados para el flujo llamado. Asegúrate de declarar los adaptadores necesarios y, si usas implementaciones de ejemplo (sample adapters), inclúyelos para permitir pruebas rápidas mientras desarrollas la integración real.

Comprobación de nuestra solución

Inicia la aplicación como antes (si necesitas un recordatorio, consulta Revisión de la aplicación inicial).

  • Envía un pain.001 por el canal de iniciación.

  • Verifica en la GUI del desarrollador que se convierte a pacs.008 y se inicia el flujo de ejecución.

  • Confirma que, cuando el flujo de ejecución alcanza un estado terminal, el Initiation Flow reacciona moviéndose al estado apropiado (Complete o Rejected).

Conclusiones

En esta sección:

  • Creamos un flujo de iniciación que llama a un flujo de ejecución.

  • Configuramos una función de mapeo para convertir pain.001 a pacs.008 y la usamos como input enrichment.

  • Publicamos estados terminales en el flujo de ejecución y reaccionamos a ellos en el flujo de iniciación.

  • Revisamos consideraciones de implementación para la comunicación flujo-a-flujo.