This article is also available in:
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 Flokzu 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, Flokzu 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:

Ejemplo de configuración errónea con evento de terminación entre compuertas inclusivas.

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í:

Paralelismo mal diseñado, y una ejecución que funciona bien.

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

Paralelismo mal diseñado con una ejecución errónea (queda Token esperando para siempre)

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:

Ejemplo de configuración errónea con condiciones no mutuamente excluyentes o incompletas

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:

Compuerta mal diseñada con condiciones no mutuamente excluyentes, que ejecuta bien.

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

Compuerta mal diseñada con condiciones no mutuamente excluyentes, que ejecuta erróneamente.

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:

Ejemplo de configuración errónea con bucle entre compuertas inclusivas.

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:

Loop entre compuertas inclusivas, mal diseñado, con una ejecución exitosa

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:

Loop entre compuertas inclusivas, mal diseñado, con una ejecución errónea

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.
¿Este artículo te resultó útil?
Cancelar
¡Gracias!