Documentation for a newer release is available. View Latest

DSL 11 - Uso de eventos adicionales

Comenzando

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

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

¿Qué es un evento adicional?

Un Additional Event es, simplemente, la capacidad de generar un evento desde dentro del procesamiento de IPF. Normalmente se usa como método para añadir información descriptiva al historial de eventos, pero también puede usarse para ejecutar lógica de procesamiento condicional. De hecho, toda la configuración que hemos establecido en pasos anteriores podría haberse realizado usando eventos adicionales.

En nuestro escenario, cuando miras el historial de eventos de un flujo de ejecución puedes ver:

[
  "Flow Initiated",
  "Duplicate Check Passed",
  "Account Validation Passed",
  "In Sanctions Sanctions Passed",
  "Run Fraud Check SKIP_FRAUD",
  "Clear and Settle Passed"
]

Aquí no es inmediatamente obvio que nuestro flujo haya completado; parece que solo hemos llegado a la etapa de clear and settle passed.

Para resolver esto, haremos que la aplicación lance un evento adicional para mostrar claramente en el historial de eventos que hemos completado.

Configuración del DSL

Añadir el evento adicional

Primero, recordemos la lógica DSL que tenemos actualmente para nuestro evento Clear and Settle Passed; la vemos en el Event Behaviour:

additional 1

Aquí, en lugar de completar inmediatamente, queremos lanzar nuestro evento adicional. Sin embargo, una vez que alcanzamos un estado terminal el flujo ha terminado y no se permiten más acciones. Por esa razón, necesitaremos un nuevo State y una nueva transición de estado.

Añadamos un estado Completing así:

additional 2

También necesitaremos definir nuestra Event Definition adicional; llámala Flow Complete y añádela a las definiciones de eventos de nuestro flujo como cualquier otra:

additional 3

Observa que aquí no hemos suministrado business data en el evento, pero podríamos hacerlo. Esos datos se poblarían a partir de datos contenidos en otros eventos de nuestro flujo.

Para lanzar realmente nuestro evento adicional necesitamos cambiar nuestro Event Behaviour (para "Cleared And Settling") para movernos al nuevo estado Completing (en lugar de Complete) y luego lanzar un evento adicional. Así que, en la caja de perform action, debemos elegir "raise an additional event":

additional 4

Luego seleccionamos el evento que queremos lanzar; en nuestro caso, nuestro nuevo evento Flow Complete.

Cuando terminemos, el Event Behaviour debería verse así:

additional 5

Por último, necesitamos transicionar de nuevo a Complete. Esto es simplemente una transición desde Completing a Complete al recibir nuestro nuevo evento Flow Complete. Así que añadamos un nuevo event behaviour para hacerlo:

additional 6

Con esto, el trabajo en el DSL está completo. Veamos también el gráfico:

additional 7

Implementación en Java

La buena noticia aquí es que no se requiere implementación cuando añadimos eventos adicionales; todo lo gestiona la generación.

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).

Luego podemos enviar un pago:

curl -X POST localhost:8080/submit | jq

Ahora, si abrimos el pago en la GUI para desarrolladores y abrimos la vista de eventos de dominio (buscar por unit of work id, clic en view, clic en domain events), deberíamos ver:

additional 8

Aquí vemos que está presente el nuevo evento Flow Complete para el proceso ipftutorialflowv2 y, por tanto, hemos demostrado que nuestro evento adicional se lanza correctamente.

Si miras el gráfico del flujo ipftutorialv2, puedes ver el evento y la transición extra:

additional 9

Conclusiones

En esta sección hemos aprendido a usar eventos adicionales.