DSL 9 - Usando Subflows

Para comenzar

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

¿Qué es un Subflujo?

Un "Subflujo" es una sección reutilizable de un flujo. Efectivamente, tiene todas las mismas características que un flujo, pero no se espera que sea independiente, sino que se incluye dentro de otro flujo.

Un subflujo puede, por lo tanto, ser:

Utilizado en muchos flujos diferentes.
Utilizado múltiples veces dentro del mismo flujo.

Un ejemplo frecuentemente observado de un subflujo es una verificación de sanciones. Puede ser que muchos flujos diferentes utilicen una verificación de sanciones o, de hecho, que se necesite una verificación de sanciones en diferentes partes del flujo (por ejemplo, tras una reanudación después de un retraso).

Para esta sección, utilizaremos el ejemplo de sanciones para integrar un subflujo en nuestro flujo.

Nuestro subflujo de sanciones deberá realizar las siguientes acciones:

Cuando comienza el subflujo, hacemos una solicitud a un sistema de sanciones.

Entonces, el sistema de sanciones puede devolver:

Aprobado-todo está bien, el flujo puede continuar.
Espere

Entonces, en la condición de espera, debemos esperar hasta que los sistemas de sanciones nos envíen uno de los tres mensajes adicionales:

Aprobado
Bloqueado
Fallido

Configuración de DSL

Añadiendo el Sanctions Domain

Antes de comenzar a examinar el subflujo en sí, primero necesitamos agregar un dominio externo que sea capaz de soportar nuestro flujo. Así que procedamos a hacerlo.

Primero, crearemos un nuevo dominio externo para nuestro sistema de sanciones. Esto es similar a lo que hicimos en (Nuevo v2Flo Dominio Externo), excepto que la respuesta necesita utilizar una capacidad adicional que no hemos discutido completamente antes. Así que comencemos añadiendo lo básico:

Un nombre de " Sanctions Domain "
Una descripción de "Un sistema de sanciones de muestra"
Agregue una solicitud con detalles:
- Un nombre de "Verificar Sanciones"
- Una descripción de "Llamada de sanciones de muestra"
- Añada el customer transferencia de crédito a datos empresariales

Ahora consideramos las respuestas. Hay varias maneras diferentes en las que podemos modelar las respuestas requeridas utilizando combinaciones de códigos de respuesta y códigos de razón, como hicimos en el sistema de fraude. Aquí, sin embargo, lo haremos modelando múltiples respuestas a nuestra única solicitud de sanciones.

La primera respuesta es el escenario "aprobado", lo llamaremos un escenario de "no coincidencia". Para esto, simplemente añadimos una respuesta sencilla como la que hemos tenido antes:

Un nombre de "Sanctions No Hit"
Una descripción de "La verificación de sanciones ha sido superada"
Dejaremos todos los demás campos como los predeterminados.

La segunda respuesta es aquella en la que la verificación inicial no pasa de inmediato y se nos solicita esperar. Usted llamará a esto un escenario de "hit".

La principal diferencia entre los escenarios de "acierto" y "sin acierto" es que:

en el escenario sin resultados, completa la solicitud-es decir, no estamos esperando ninguna información adicional del sistema de sanciones.
en el escenario de éxito no se completa la solicitud, todavía estamos esperando un resultado final de nuestra llamada de sanciones.

Así que esta vez, para nuestro escenario de éxito, necesitamos establecer nuestra bandera de "Completando" en false para informar al sistema que esperamos mensajes subsiguientes del sistema de sanciones en respuesta a la solicitud inicial.

Establezcamos esta respuesta:

Un nombre de "Sanctions Hit"
Una descripción de "El sistema de sanciones está verificando el resultado"
La bandera de finalización no marcada
Dejaremos todos los demás campos como los predeterminados.

Finalmente, también necesitamos la respuesta del resultado cuando el sistema de sanciones nos envíe eventualmente una respuesta. Usted lo llamará "Respuesta Final de Sanciones". Así que añadamos esto:

Un nombre de "Respuesta Final a Sanciones"
Una descripción de "El resultado final del sistema de sanciones"
Para los códigos de respuesta, necesitaremos crear una nueva biblioteca de códigos de respuesta para nuestras "Sanciones Finales". Response Codes ". Esto es igual que en DSL 4 Usando un Dominio Externo. En nuestro caso, tendremos tres códigos de respuesta: Falso Positivo, Bloquear, Rechazar."
Dejaremos todos los demás campos como los predeterminados.

Una vez que hayamos reunido todo esto, la definición de nuestro sistema de sanciones debería verse así:

Y para referencia, nuestro nuevo "Sanctions Final Response Codes " se verá como:

Tenga en cuenta que podemos simplemente añadir nuestros códigos de respuesta a la biblioteca existente que utilizamos para nuestros códigos de validación de cuentas.

Ese es nuestro sistema de sanciones, completamente configurado y listo para usar.

Añadiendo el Subflujo

Ahora que hemos configurado nuestro dominio de sanciones, proceda a crear nuestro subflujo. Hacemos esto haciendo clic derecho en nuestro modelo y seleccionando Nuevo v2Flo Subflujo.

Esto debería crear una nueva página de subflujo:

Lo primero que debe tener en cuenta es cuán similar es esto a la página de flujo. ¡Eso se debe a que es efectivamente un tipo especializado de flujo! Por lo tanto, utilizar esta página debería resultar muy familiar.

Establezcamos nuestro nuevo subflujo, comenzaremos dándole a nuestro flujo de sanciones un nombre de "Subflujo de Sanciones" y una descripción de "Un subflujo de ejemplo para sanciones".

Lo siguiente a considerar son los estados que vamos a necesitar. A partir de los requisitos, podemos ver que hay tres estados que necesitaremos:

Un estado de "Verificación de Sanciones" para cuando realizamos la solicitud inicial a sanciones y estamos a la espera de una respuesta.
Un estado de "Esperando Resultado Final" para cuando hemos recibido una notificación de espera de sanciones y estamos a la espera de la respuesta final.
Un estado "Completo" para cuando hemos completado con éxito una verificación de sanciones.
Un estado de "Rechazado" para cuando la verificación de sanciones ha fallado.
Un estado "Bloqueado" para cuando la verificación de sanciones ha resultado en una notificación de bloqueo.

Proceda a configurar estos ahora. Considere qué valores necesitará para la bandera del terminal y el estado global en cada uno de estos estados y, cuando haya terminado, la solución se encuentra a continuación:

Es realmente importante dentro de un subflujo obtener correctamente los estados terminales. Esto se debe a que esos son los estados que el subflujo podrá informar de vuelta al flujo principal. Así que aquí tenemos "Completo", "Rechazado" y "Bloqueado" como estados terminales. Esto se debe a que los estados "Verificando Sanciones" y "Esperando Resultado Final" son estados intermedios durante el procesamiento del subflujo. Podemos enfatizar aún más esto mediante la configuración del estado global "PENDIENTE".

Ahora continuemos con nuestro subflujo y lo siguiente a considerar son los eventos. Volviendo a los requisitos, podemos ver que necesitaremos 4 eventos:

"Sancciones Aprobadas" para una verificación de sanciones exitosa
"Sancciones Rechazadas" por un chequeo de sanciones fallido
"Sancciones Bloqueadas" para una verificación de sanciones bloqueada
"Las sanciones afectan" para una notificación de espera.

Tenga en cuenta que hay muchos nombres de eventos diferentes que podríamos utilizar. Hemos decidido usar el mismo evento "Sanciones Aprobadas" tanto para la aprobación directa como para la aprobación indirecta (a través de espera) de la verificación de sanciones. Podríamos haber creado fácilmente dos eventos para identificar cada uno de manera única.

Vamos a añadir estos Event Definiciones ahora y deberíamos ver:

Continuando con nuestro subflujo, nuestra próxima sección a considerar es el Comportamiento de Entrada. Aquí debemos considerar cada una de nuestras tres diferentes respuestas del sistema de sanciones y cómo deseamos manejarlas. Intente hacerlo usted mismo y la solución se encuentra a continuación:

A continuación, al iniciar, necesitamos llamar al sistema de sanciones. Por lo tanto, necesitaremos un nuevo estado "Verificando Sanciones" y un comportamiento de inicio que nos mueva al estado "Verificando Sanciones" y llame a nuestro sistema de sanciones. Intente eso ahora y la solución se encuentra a continuación:

Finalmente, necesitamos manejar nuestro comportamiento de eventos. Vea si puede resolverlo, y luego la solución se encuentra a continuación:

El punto interesante a destacar aquí es cómo hemos manejado la línea 4 en el comportamiento del evento. Habría sido igualmente correcto tener dos líneas aquí, una para el estado actual de "Verificación de Sanciones" y otra para el estado actual de "Esperando Resultado Final". Sin embargo, hemos optado por utilizar la capacidad de tener múltiples estados definidos en el estado actual. Esta es simplemente una forma abreviada de evitar repetir la misma lógica múltiples veces si el resultado no es diferente.

Hemos completado todas nuestras secciones del flujo, pero si observamos, todavía hay un error que se muestra en "Realizar Acción" del comportamiento de iniciación. Investigaremos esto validando el flujo (ALT + ENTER y luego validar flujo). Nos indica:

Nos está indicando que el subflujo no tiene acceso a un customer transferencia de crédito y por lo tanto no puede realizar la llamada al sistema de sanciones. En nuestro caso, nuestro customer La transferencia de crédito pertenece al flujo principal. Por lo tanto, para proporcionarla al subflujo, debemos agregarla a los datos de iniciación. Hagámoslo y ahora deberíamos ver:

Y nuestro error ha sido resuelto. Como es habitual, antes de completar, consultemos nuestro gráfico (Herramientas > Abrir Visor de Flujo) para encontrar:

Ese es nuestro subflujo completamente configurado y listo para usar, así que la siguiente pregunta es cómo aplicamos esto a nuestro flujo principal. Regresemos a él, actualizaremos solo en nuestra última versión V2:

Vamos a añadir nuestro subflujo como un nuevo paso después de la validación de nuestra cuenta. Actualmente, tenemos:

Para incluir el paso adicional, queremos que la cuenta validante llame a nuestro subflujo (no ejecute la decisión de verificación de fraude) y luego realice la verificación de fraude tras pasar satisfactoriamente las sanciones.

Si recuerda de vuelta a DSL 5 - Utilizando una decisión, introdujimos el concepto de un estado pseudo y en ese caso el tipo específico de un " Decision State ". Aquí queremos utilizar un tipo diferente de estado-a "Subflujo State ". Comencemos añadiéndolo después de recibir el resultado de "Validación de Cuenta Aprobada".

Así que en lugar de pasar a la decisión "Ejecutar Verificación de Fraude", creemos nuestro "Subflujo". State.

Para hacer esto, primero necesitamos eliminar el estado de decisión existente y luego seleccionar "Crear Subflujo". State.
Ingresará el nombre como "In Sanctions".
Luego, en el cuadro "Realizar Acción", eliminaremos la llamada existente a Fraude y luego seleccionaremos "Llamar Subflujo" y elegiremos el "Subflujo de Sanciones". Una vez hecho esto, deberíamos ver lo siguiente:

Si usted inspecciona el error ahora, veremos:

Aquí podemos ver que el flujo necesita que definamos cómo manejar el hecho de que el subflujo ha alcanzado esos estados de Completo, Rechazado o Bloqueado. ¿Por qué solo esos 3? Porque esos son los que especificamos como terminales con el subflujo de sanciones.

Establezcamos nuestro manejo del subflujo que termina como " Event "Comportamiento" en el flujo principal V2. Para hacer esto, comenzamos añadiendo un nuevo Event Comportamiento con el estado actual de "En Sanciones". Luego en "Para Event " seleccionamos "Finalización de Subflujo", y luego comenzaremos seleccionando "Completar"."

En nuestro caso, al recibir la información completa del flujo de sanciones, necesitaremos crear nuestra decisión de "Ejecutar Verificación de Fraude" y activar la decisión de verificación de fraude como habíamos indicado anteriormente (nota-hasta que esto se complete "Ejecutar Verificación de Fraude" aparece como una 'Referencia No Resuelta'):

Ahora hagamos lo mismo para manejar el resultado de Rechazado y Bloqueado; por ahora, simplemente enviaremos ambos a rechazado.

Nuevamente, observe aquí cómo hemos utilizado la capacidad de "Cualquiera de" para minimizar la entrada.

Finalmente, analicemos cómo esto ha impactado nuestro diagrama de flujo (Herramientas > Abrir FlowViewer):

Aquí podemos ver que nuestra llamada de subflujo ha sido representada por un cuadro. El cuadro contiene toda la lógica del subflujo para minimizar la complejidad del gráfico. Sin embargo, si observa la parte superior del gráfico, hay una nueva opción "Expandir Subflujo". Haga clic en esto y aplique para ver:

Y en esta vista podemos ver el subflujo siendo expandido para que podamos observar el funcionamiento interno del flujo.

Eso es todo lo relacionado con nuestra configuración de DSL. Ahora pasemos a la parte de implementación.

Java Implementación

Definiendo el Adaptador

Cambiemos a Intellij para trabajar con la parte de java.

Primero, reconstruya nuestro proyecto para que podamos generar nuestro nuevo flujo. Para hacer esto, abra una nueva terminal y ejecute:

mvn clean install

No hay nada especial acerca del subflujo en sí desde el punto de vista de generación, los cambios que debemos considerar son simplemente que hemos definido un nuevo Dominio Externo (Sanctions Domain) que ahora debemos implementar. Nuevamente, aquí elegirá utilizar la implementación de la aplicación de muestra como hicimos en DSL 4 - Uso de un dominio externo, así que intente agregar eso ahora y la solución está abajo cuando esté listo:

@Bean
public IpftutorialmodelDomain init(ActorSystem actorSystem, SchedulerPort schedulerAdapter) {
    // All adapters should be added to the domain model
    return new IpftutorialmodelDomain. Builder(actorSystem)
             .withTutorialDomainFunctionLibraryAdapter(input -> CompletableFuture.completedStage(new DuplicateCheckResponseInput. Builder(input.getId(), AcceptOrRejectCodes. Accepted).build()))
             .withAccountingSystemActionAdapter(new SampleAccountingSystemActionAdapter())
             .withFraudSystemActionAdapter(new FraudSystemActionAdapter())
             .withDecisionLibraryAdapter(input ->
                    input.getCustomerCreditTransfer().getCdtTrfTxInf().get(0).getIntrBkSttlmAmt().getValue().compareTo(BigDecimal. TEN)>0?
                            RunFraudCheckDecisionOutcomes. FRAUDREQUIRED: RunFraudCheckDecisionOutcomes. SKIPFRAUD)
             .withIpftutorialflowV1AggregateFunctionAdapter(input -> new ExtractCreditorAccountForFlowIpftutorialflowV1AggregateFunctionOutput(input.getCustomerCreditTransfer().getCdtTrfTxInf().get(0).getCdtrAcct()))
             .withIpftutorialflowV2AggregateFunctionAdapter(input -> new ExtractCreditorAccountForFlowIpftutorialflowV2AggregateFunctionOutput(input.getCustomerCreditTransfer().getCdtTrfTxInf().get(0).getCdtrAcct()))
             .withSchedulerAdapter(schedulerAdapter)
             .withCSMServiceActionAdapter(new SampleCSMServiceActionAdapter())
             .withSanctionsDomainActionAdapter(new SampleSanctionsDomainActionAdapter())
             .build();
}

Aquí hemos añadido a nuestra configuración la especificación del sistema de sanciones.

Verificando nuestra Solución

Como es habitual, ahora verifiquemos que la solución funcione. Inicie la aplicación como se indicó anteriormente (las instrucciones están disponibles en Revisando la solicitud inicial si necesita un repaso)

Para los pagos, simplemente utilizaremos uno estándar:

curl -X POST localhost:8080/submit | jq

Entonces, como es habitual, si ahora mencionamos el pago en el Developer GUI y muestre el gráfico de flujo (busque por id de unidad de trabajo, haga clic en ver, haga clic en ver gráfico) y deberíamos ver:

Y podemos ver que nuestro subflujo se ha expandido para ser parte del flujo principal en ejecución, el cual se ha completado con éxito. Si examinamos los eventos en su lugar (click domain events):

Debemos señalar que el nombre del evento es la combinación del prefijo que proporcionamos en nuestro estado pseudo junto con el nombre real del evento en el subflujo. Esto es importante darse cuenta, ya que es esta capacidad la que nos permite utilizar nuestro subflujo en múltiples lugares a lo largo de nuestro flujo. Puede intentar esto usted mismo si lo desea, añadiendo una segunda llamada al subflujo de sanciones en el flujo.

Conclusiones

En esta sección hemos aprendido cómo crear un subflujo e invocarlo desde dentro de nuestro flujo.

Habiendo considerado los subflujos y cómo utilizarlos, ahora dirijamos nuestra atención a otros flujos y cómo llamar un flujo desde otro en:xref:calling_other1.adoc[DSL 10 - Llamando a otros flujos]