Las compuertas de BPMN

El modelo de ejecución de BPMN es un token que recorre el diagrama. La compuerta es lo único que cambia cuántos tokens hay: una división puede convertir un token en varios, una convergencia puede devolverlos a uno. Todo lo demás se sigue de ahí.

Una nota sobre el nombre. La especificación dice gateway; la mayoría dice compuerta o puerta y busca eso. Es lo mismo, y el rombo es el mismo rombo, pero en el título de un diagrama conviene gateway, porque es la palabra que leerán todas las herramientas BPMN y todos los revisores.

Dos consecuencias que conviene retener. Primera, una compuerta no hace ningún trabajo: evalúa condiciones ya calculadas, y si quieres comprobar algo, eso es una tarea antes de la compuerta. Segunda, una división suele necesitar una convergencia del mismo tipo, porque lo que creó tokens de más tiene que volver a unirlos o correrán por separado hasta el final.

El mismo símbolo hace ambos trabajos, y cuál está haciendo depende solo de si tiene más flujos salientes o entrantes. Una compuerta con una entrada y tres salidas divide; tres dentro y una fuera converge.

Conviene fijar el vocabulario, porque para el caso convergente se usan tres palabras. Una compuerta paralela convergente es una unión: espera a cada rama. Una compuerta exclusiva convergente es una fusión: no espera nada y deja pasar cada token. Ambas se dibujan como el mismo rombo que al dividir, y llamar unión a una fusión es como un diagrama acaba afirmando terminado un trabajo que nunca se ejecutó.

Todo lo anterior es una sola habilidad: pon el dedo en el evento de inicio y cuenta. Aquí está el proceso de siniestro del principio de esta página, recorrido paso a paso, con el número de tokens vivos tras cada uno.

1. Ocurre «Claim received». Un token. Está en el flujo hacia la primera compuerta.
2. La división paralela. Dos tokens. No se evalúa ninguna condición y no se elige nada: una división paralela emite siempre un token por flujo saliente.
3. La comprobación de póliza y la de fraude se ejecutan. Siguen dos. Son realmente concurrentes: el diagrama no afirma nada sobre cuál termina antes, y no lo necesita.
4. La unión paralela. De vuelta a uno. El token que llegue primero espera ahí. Cuando llega el segundo, la unión consume ambos y emite uno.
5. «Covered?» Un token, una rama. Una compuerta exclusiva nunca cambia la cuenta: solo cambia en qué flujo está el token.
6. Indemnizar o rechazar, luego el fin. Cero. La instancia del proceso termina cuando el último token lo consume un evento de fin.

Ahora rómpelo a propósito, porque los dos fallos clásicos se ven solo con la cuenta.

Haz exclusiva la primera compuerta y deja paralela la unión. La división emite ahora un token, así que se ejecuta una comprobación. La unión paralela sigue esperando dos. Por el segundo flujo no llega nada nunca, y el siniestro se queda en la unión durante toda la vida del sistema. Ese es el interbloqueo, y costó una marca cambiada.

Deja paralela la división y haz exclusiva la unión. Llegan dos tokens y una fusión exclusiva no espera nada, así que ambos pasan directos. «Covered?» se evalúa dos veces, la tarea de indemnizar se ejecuta dos veces y al cliente se le paga dos veces. Esto es peor que el interbloqueo, porque un interbloqueo se anuncia solo y un pago doble no.

Esta es la construcción que hace expresable en una sola imagen «esperamos los documentos, pero no eternamente». Cualquier otra forma de dibujarlo -un evento temporizador de borde en una tarea de espera, un bucle con condición- o duplica la lógica del vencimiento o la esconde.

La acompañan dos reglas. Los destinos de una compuerta basada en eventos deben ser eventos intermedios de captura o tareas receive, nunca tareas simples: la compuerta es una carrera entre cosas que llegan, y una tarea no llega. Y las ramas deben ser realmente excluyentes en el tiempo, cosa que son automáticamente: la primera en ocurrir descarta el resto.

Las condiciones viven en los flujos de secuencia salientes, no en la compuerta. Escríbelas como expresiones cortas que un lector pueda evaluar - amount > 10000, policy status = active - y ponlas en la línea cerca de la compuerta y no cerca del destino.

Exactamente una rama de una compuerta divergente debería ser el flujo por defecto, dibujado con una pequeña marca cruzando su base. Se toma cuando ninguna otra condición se cumple, y es lo que evita que un proceso se atasque en una compuerta donde los datos resultaron ser algo que nadie previó.

Quien acaba de aprender compuertas recurre a ellas para cada bifurcación del mundo, y el resultado es un diagrama que es 40 % rombo. Otras cuatro construcciones de BPMN expresan mejor una decisión en los casos siguientes, y conocerlas es la mayor parte de la diferencia entre un modelo de proceso que cabe en una página y otro que no.

La prueba es si la bifurcación es parte del proceso o parte de una decisión. Un siniestro que va a vía rápida o a revisión manual es proceso: los dos caminos se ven distintos y el lector necesita ver ambos. En cuál de nueve bandas de riesgo cae es una decisión: los caminos después son idénticos, y ponerlo en el diagrama cuesta ocho rombos para decir una cosa. Mira cómo dibujar un diagrama BPMN para ver dónde suele caer esa línea en la práctica.

1. División paralela, fusión exclusiva. La división hizo dos tokens; la fusión exclusiva deja pasar ambos, y todo lo que va después ocurre dos veces.
2. División inclusiva, unión paralela. El interbloqueo de arriba. Haz coincidir tus compuertas.
3. Trabajo dentro de la compuerta. Un rombo etiquetado «Validar y enrutar» es una tarea y una compuerta bajo un mismo contorno. Sepáralas.
4. Ramas sin etiquetar. Dos líneas saliendo de un rombo sin nada escrito obligan al lector a adivinar, y la mitad adivinará mal.
5. Sin flujo por defecto. Llega la única entrada en la que nadie pensó y el token no tiene adónde ir.
6. Tareas simples tras una compuerta basada en eventos. No es legal, y normalmente significa que se quería una compuerta exclusiva.

Las compuertas y los eventos son las dos mitades del control de flujo en BPMN: las compuertas deciden, los eventos esperan e interrumpen. Un proceso modelado solo con compuertas tiende a crecer en largas cadenas de sondeo; el que usa eventos de borde donde debe se queda mucho más cerca de lo que de verdad ocurre.