Errores y recomendaciones al usar una compuerta inclusiva y paralelismo (Inclusive Gateway)
Las compuertas inclusivas (inclusive gateway en inglés) permiten configurar paralelismos, muy útiles en los procesos de negocios. Esa flexibilidad y potencia, como contrapartida, son propensas a configuraciones erróneas de los procesos.
Una configuración errónea de un proceso, puede dejar instancias de proceso trancadas en una compuerta, y requerir intervención manual del equipo de INTEGRADOC para reactivarla.
Todo proceso modelado en BPMN es propenso a errores de diseño. Algunos de ellos pueden ser detectados en tiempo de diseño. Por ejemplo, si luego de una compuerta exclusiva (exclusive gateway), no hay condiciones para las "flechas" salientes, INTEGRADOC desplegará un error apropiado y no permitirá que ese proceso sea desplegado. Así lo podremos corregir en tiempo de diseño. Sin embargo, no todos los errores pueden ser detectados al diseñar el diagrama BPMN.
Algunas configuraciones erróneas del proceso, y en particular cuando hay compuertas inclusivas y paralelismos, no pueden ser detectadas en tiempo de diseño. El error surgirá en tiempo de ejecución, con una instancia de proceso real. Por ello se debe extremar el cuidado previo y siempre realizar pruebas en el Sandbox antes de desplegar en producción.
Considérese el siguiente diagrama en BPMN:
Este diagrama a primera vista podría parecer modelado de manera correcta. Y de hecho, podría ejecutar correctamente en algunos escenarios, sin producir ningún error. Analicemos una posible ejecución.
Al crear una instancia del proceso, la primer compuerta inclusiva divide el flujo, creando dos tokens. Supongamos que la tarea T2 se completa antes que la tarea T1, por lo que el token de la rama inferior queda esperando en la segunda compuerta inclusiva. Luego se completa la T1. Si la condición del gateway exclusivo evalúa B, entonces el flujo funciona perfectamente. Notar que los tokens esperan en la segunda compuerta inclusiva de forma satisfactoria. Y cuando ambos token llegan allí, el proceso sigue, creando la tarea T3 y terminando satisfactoriamente. Esta ejecución se vería así:
Sin embargo, el mismo diagrama produce ejecuciones erróneas, simplemente si una de las variables del proceso hace que la compuerta exclusiva evalúe A (en lugar de B). Nótese que al completar T2 el token que venía por la rama de abajo, queda esperando en la segunda compuerta inclusiva. Pero el token que estaba en la rama de arriba, evalúa A en la compuerta exclusiva y termina. Entonces, el token de la rama inferior, queda esperando por siempre en la compuerta inclusiva. Dado que no hay otro token en esta instancia de proceso, el token inferior nunca saldrá de allí, y la instancia de proceso nunca terminará.
En este caso, el principal problema deriva de que ante algunas condiciones en el flujo, un token puede ser terminado, y nunca llegar a la compuerta inclusiva que espera por él. Cuando usamos una compuerta inclusiva para dividir en dos o más caminos el proceso y así generar dos o más tokens, y si luego tenemos una compuerta inclusiva que une esos caminos, debemos asegurarnos no terminar tokens entre ellas.
Se recomienda que entre dos compuertas inclusivas, no se utilicen eventos de terminación (End-Events). Si son imprescindibles, utilizarlos con mucho cuidado. Su mala configuración puede llevar a que un token termine, y otro quede esperando por él en una compuerta inclusiva posterior.
Considérese este otro diagrama en BPMN:
A simple vista, no es trivial darse cuenta que las condiciones de la compuerta exclusiva no son mutuamente excluyentes y tampoco son completas. Es decir, hay valores para las variables A y B que harían que se cumplan ambas condiciones, sólo una, o ninguna. Podemos tener suerte, y con los valores de varA = 8 y varB = 15, sólo se tomaría el camino de abajo y la ejecución terminaría satisfactoriamente:
Por otro lado, si los valores de las variables fueran varA = 12 y varB = 15 el token de la rama inferior, quedará esperando en la segunda compuerta inclusiva por siempre, dado que el token que fue por la rama superior no puede salir de la T1 hasta que alguna de las condiciones sea modificada para que exista condición de salida (la configuración de las condiciones no cubre toda la casuística posible):
También se podría dar, por ejemplo si varA = 8 y varB = 25 que se cumplan ambas condiciones de la compuerta exclusiva, en cuyo caso no podemos tener certeza que camino seguirá el token, produciendo resultados inesperados.
Es muy importante cuando se utilizan condiciones en las compuertas, que sean mutuamente excluyentes y completas. En especial, cuando luego de esas compuertas hay otras compuertas inclusivas donde los tokens pueden quedar esperando eternamente.
Considérese este proceso:
Al igual que en el caso anterior, no es fácil determinar que las condiciones de salida de la compuerta inclusiva son mutuamente excluyentes y completas. Podemos tener suerte y tener ejecuciones exitosas del proceso, por ejemplo si varA = 8 y varB = 15 la ejecución sería:
El riesgo es que con otros valores de las variables, por ejemplo varA = 8 y varB = 30 se cumplen ambas condiciones de la compuerta exclusiva, por lo que se generan dos tokens. Uno de ellos se reúne con el que estaba esperando en la última compuerta exclusiva, y se crea la tarea T3. Sin embargo, el otro token va a la tarea T1, y en realidad la instancia de proceso no termina dado que está ese token vivo en una tarea válida. Seguramente este no sea el comportamiento deseado:
Es recomendable que si se utilizan bucles (loops) entre dos compuertas inclusivas, no se creen nuevos tokens en ellos. Se debe asegurar que en toda la casuística, no se puedan producir situaciones en que queden tokens en el loop, mientras la instancia de proceso se mueve fuera de la compuerta inclusiva que une las ramas de ejecución previamente separadas.
Las compuertas inclusivas son muy poderosas, y permiten algo vital en los procesos de negocios como es el trabajo en paralelo. Sin embargo, se deben configurar con cuidado para evitar situaciones indeseadas, o tokens que quedan esperando algo que nunca sucederá.
Los ejemplos propuestos en este artículo fueron especialmente diseñados con fines didácticos para ejemplificar los problemas potenciales. En la vida real, los procesos son mucho más complejos, con decenas o cientos de tareas y compuertas. En esos casos, es bien difícil identificar los errores o malas configuraciones. Por ello es muy importante aplicar las recomendaciones al momento de diseñar el proceso, evitando las malas prácticas aquí identificadas.
Una configuración errónea de un proceso, puede dejar instancias de proceso trancadas en una compuerta, y requerir intervención manual del equipo de INTEGRADOC para reactivarla.
Todo proceso modelado en BPMN es propenso a errores de diseño. Algunos de ellos pueden ser detectados en tiempo de diseño. Por ejemplo, si luego de una compuerta exclusiva (exclusive gateway), no hay condiciones para las "flechas" salientes, INTEGRADOC desplegará un error apropiado y no permitirá que ese proceso sea desplegado. Así lo podremos corregir en tiempo de diseño. Sin embargo, no todos los errores pueden ser detectados al diseñar el diagrama BPMN.
Algunas configuraciones erróneas del proceso, y en particular cuando hay compuertas inclusivas y paralelismos, no pueden ser detectadas en tiempo de diseño. El error surgirá en tiempo de ejecución, con una instancia de proceso real. Por ello se debe extremar el cuidado previo y siempre realizar pruebas en el Sandbox antes de desplegar en producción.
Eventos de finalización entre compuertas inclusivas.
Considérese el siguiente diagrama en BPMN:
Este diagrama a primera vista podría parecer modelado de manera correcta. Y de hecho, podría ejecutar correctamente en algunos escenarios, sin producir ningún error. Analicemos una posible ejecución.
Al crear una instancia del proceso, la primer compuerta inclusiva divide el flujo, creando dos tokens. Supongamos que la tarea T2 se completa antes que la tarea T1, por lo que el token de la rama inferior queda esperando en la segunda compuerta inclusiva. Luego se completa la T1. Si la condición del gateway exclusivo evalúa B, entonces el flujo funciona perfectamente. Notar que los tokens esperan en la segunda compuerta inclusiva de forma satisfactoria. Y cuando ambos token llegan allí, el proceso sigue, creando la tarea T3 y terminando satisfactoriamente. Esta ejecución se vería así:
Sin embargo, el mismo diagrama produce ejecuciones erróneas, simplemente si una de las variables del proceso hace que la compuerta exclusiva evalúe A (en lugar de B). Nótese que al completar T2 el token que venía por la rama de abajo, queda esperando en la segunda compuerta inclusiva. Pero el token que estaba en la rama de arriba, evalúa A en la compuerta exclusiva y termina. Entonces, el token de la rama inferior, queda esperando por siempre en la compuerta inclusiva. Dado que no hay otro token en esta instancia de proceso, el token inferior nunca saldrá de allí, y la instancia de proceso nunca terminará.
En este caso, el principal problema deriva de que ante algunas condiciones en el flujo, un token puede ser terminado, y nunca llegar a la compuerta inclusiva que espera por él. Cuando usamos una compuerta inclusiva para dividir en dos o más caminos el proceso y así generar dos o más tokens, y si luego tenemos una compuerta inclusiva que une esos caminos, debemos asegurarnos no terminar tokens entre ellas.
Se recomienda que entre dos compuertas inclusivas, no se utilicen eventos de terminación (End-Events). Si son imprescindibles, utilizarlos con mucho cuidado. Su mala configuración puede llevar a que un token termine, y otro quede esperando por él en una compuerta inclusiva posterior.
Condiciones de compuerta no mutuamente excluyentes o incompletas
Considérese este otro diagrama en BPMN:
A simple vista, no es trivial darse cuenta que las condiciones de la compuerta exclusiva no son mutuamente excluyentes y tampoco son completas. Es decir, hay valores para las variables A y B que harían que se cumplan ambas condiciones, sólo una, o ninguna. Podemos tener suerte, y con los valores de varA = 8 y varB = 15, sólo se tomaría el camino de abajo y la ejecución terminaría satisfactoriamente:
Por otro lado, si los valores de las variables fueran varA = 12 y varB = 15 el token de la rama inferior, quedará esperando en la segunda compuerta inclusiva por siempre, dado que el token que fue por la rama superior no puede salir de la T1 hasta que alguna de las condiciones sea modificada para que exista condición de salida (la configuración de las condiciones no cubre toda la casuística posible):
También se podría dar, por ejemplo si varA = 8 y varB = 25 que se cumplan ambas condiciones de la compuerta exclusiva, en cuyo caso no podemos tener certeza que camino seguirá el token, produciendo resultados inesperados.
Es muy importante cuando se utilizan condiciones en las compuertas, que sean mutuamente excluyentes y completas. En especial, cuando luego de esas compuertas hay otras compuertas inclusivas donde los tokens pueden quedar esperando eternamente.
Loops o bucles entre compuertas inclusivas
Considérese este proceso:
Al igual que en el caso anterior, no es fácil determinar que las condiciones de salida de la compuerta inclusiva son mutuamente excluyentes y completas. Podemos tener suerte y tener ejecuciones exitosas del proceso, por ejemplo si varA = 8 y varB = 15 la ejecución sería:
El riesgo es que con otros valores de las variables, por ejemplo varA = 8 y varB = 30 se cumplen ambas condiciones de la compuerta exclusiva, por lo que se generan dos tokens. Uno de ellos se reúne con el que estaba esperando en la última compuerta exclusiva, y se crea la tarea T3. Sin embargo, el otro token va a la tarea T1, y en realidad la instancia de proceso no termina dado que está ese token vivo en una tarea válida. Seguramente este no sea el comportamiento deseado:
Es recomendable que si se utilizan bucles (loops) entre dos compuertas inclusivas, no se creen nuevos tokens en ellos. Se debe asegurar que en toda la casuística, no se puedan producir situaciones en que queden tokens en el loop, mientras la instancia de proceso se mueve fuera de la compuerta inclusiva que une las ramas de ejecución previamente separadas.
Conclusión
Las compuertas inclusivas son muy poderosas, y permiten algo vital en los procesos de negocios como es el trabajo en paralelo. Sin embargo, se deben configurar con cuidado para evitar situaciones indeseadas, o tokens que quedan esperando algo que nunca sucederá.
Los ejemplos propuestos en este artículo fueron especialmente diseñados con fines didácticos para ejemplificar los problemas potenciales. En la vida real, los procesos son mucho más complejos, con decenas o cientos de tareas y compuertas. En esos casos, es bien difícil identificar los errores o malas configuraciones. Por ello es muy importante aplicar las recomendaciones al momento de diseñar el proceso, evitando las malas prácticas aquí identificadas.
Actualizado el: 02/06/2020
¡Gracias!