|
|
Compuerta de Eventos - Ejemplo
Después de informar el monto de la indemnización al cliente, el Proceso espera su respuesta dentro de un plazo de 30 días hábiles. Si, dentro del plazo, el cliente rechaza el monto, se procede a solicitar un arbitraje. Si, dentro del plazo, el cliente acepta el monto, se le paga la indemnización. Si se cumple el plazo, sin que el cliente se haya pronunciado, se asume que ha aceptado el monto y se le paga la indemnización.
El Proceso queda esperando que se gatille uno de los tres Eventos. El primero que se gatilla activa su Flujo de Salida, los otros dos son descartados.
La Compuerta de Eventos Divergente no solo incluye a la Compuerta en sí y sus Flujos de Secuencia de Salida, sino también a los Eventos asociados a esos Flujos.
Los Eventos asociados a la Compuerta deben ser Intermedios en modo Captura y de tipo: Mensaje, Timer, Condicional, Señal o Múltiple.
Compuerta de Eventos Configuración Divergente
La Compuerta de Eventos Divergente tiene la siguiente Configuración:
- Un Flujo de Secuencia de Entrada.
- Dos o más Flujos de Secuencia de Salida Incondicionales.
- Cada Flujo de Secuencia de Salida tiene un Evento Intermedio de Captura.
- Los Eventos deben ser de tipo Mensaje, Timer, Condicional, Señal o Múltiple.
- Si el Evento es de tipo Múltiple, entonces solo debe incluir Eventos de tipo Mensaje, Timer, Condicional o Señal.
- Para recibir Mensajes, en lugar de Eventos Intermedios Mensaje de Captura, se pueden usar Tareas de Recepción, pero no deben mezclarse Eventos y Tareas en una misma Compuerta.
- Los Eventos o Tareas solo pueden tener un Flujo de Secuencia de Entrada, el que proviene de la Compuerta.
- Las Tareas de Recepción no pueden tener Eventos en el Borde.
- Todos los Eventos o Tareas son independentes.
Ni la Compuerta ni los Flujos de Secuencia de Salida tienen Condiciones. Además, no hay Flujo por Defecto.
A diferencia de las otras Compuertas, la Configuración de la Compuerta de Eventos Divergente no solo incluye a la Compuerta en sí y sus Flujos de Secuencia de Salida, sino también a los Eventos asociados a esos Flujos.
Compuerta de Eventos - Configuración Divergente
Los Eventos asociados a la Compuerta deben ser Intermedios en modo Captura y de tipo: Mensaje, Timer, Condicional, Señal o Múltiple.
Compuerta de Eventos - Eventos permitidos
Compuerta de Eventos Funcionamiento Divergente
La Compuerta de Eventos Divergente selecciona el camino a seguir de acuerdo con la ocurrencia de Eventos, y no de Condiciones, como en otras Compuertas.
Cuando llega un Token a una Compuerta de Eventos Divergente:
- Por cada Flujo de Salida pasa una copia del Token hacia el Evento respectivo. Todos los Eventos quedan listos para gatillarse.
- El primer Evento que se gatilla activa su(s) Flujo(s) de Salida. Los demás Eventos son descartados, y sus respectivos Tokens son eliminados.
La Compuerta Exclusiva Divergente implementa la Divergencia Exclusiva por Eventos.
Compuerta de Eventos - Funcionamiento Divergente
Buenas Prácticas
Algunos problemas potenciales de la Compuerta de Eventos Divergente:
- Puesto que los Eventos son independientes, en una misma Compuerta podrían mezclase varios dominios. Por ejemplo, algunos Eventos podrían esperar mensajes de un proveedor, otros esperar que se cumplan condiciones relacionadas con órdenes de compra, etc.
- ¿Pueden dos Eventos ocurrir al mismo tiempo? En un Proceso automatizado una diferencia de una fracción de segundo puede bastar para que un Evento "le gane" a otro, pero en un Proceso a escala humana una diferencia de minutos u horas puede no ser suficiente para dirimir qué evento ocurrió primero. Por ejemplo, si se esperan mensajes de dos proveedores y llegan con una hora de diferencia, pero dentro de plazo, ¿hay que descartar al que llegó más tarde?
Buenas Prácticas para facilitar el modelado y lectura de la Compuerta de Eventos Divergente:
- Todos los Eventos están lógicamente relacionadas entre sí, por ejemplo: Eventos Mensaje con posibles respuestas desde otro Participante (cliente, proveedor); Eventos Condicionales con posibles cambios de estado de un objeto del negocio (factura, orden de compra), etc.
- El conjunto de los Eventos cubre todos los casos posibles: todas las posibles respuestas en la interacción con otro Participante, todos los posibles cambios de estado de un objeto del negocio, etc.
- Junto a la Compuerta se coloca una frase, posiblemente en forma de pregunta, que describe el conjunto de los Eventos.
- Todos los Eventos son mutuamente excluyentes. Es decir, solo uno de ellos se gatilla en cada ejecución de la Compuerta. Si esto no es posible, el modelador debe documentar qué hacer cuando dos Eventos ocurren "al mismo tiempo".
Un escenario típico es cuando el Proceso debe esperar la decisión de otro Participante para poder continuar. Por ejemplo, un Proceso espera la respuesta del Cliente, si éste "acepta" seguirá un camino, si "rechaza", se irá por otro.
Compuerta de Eventos - Buenas Prácticas Divergente
Flujo por Defecto
Incluso si se siguen las Buenas Prácticas arriba descritas, existe la posibilidad de que ninguno de los Eventos se gatille y, por lo tanto, el Proceso quede bloqueado indefinidamente.
Como ya se indicó, la Compuerta de Eventos Divergente no tiene Flujo por Defecto, pero es posible agregar un Evento de tipo Timer para poner un plazo límite de espera. De este modo, una vez cumplido el plazo, el Proceso continúa.
Compuerta de Eventos - Flujo por Defecto
Se puede agregar una lógica más sofisticada, por ejemplo, volver a la Compuerta de Eventos Divergente un determinado número de veces. Si se trata de la interacción con otro Participante, esto implica volver a comunicarse con éste y reanudar la espera en la Compuerta de Eventos.
Compuerta de Eventos - Flujo por Defecto
Compuerta de Eventos Convergente
La Compuerta de Eventos Convergente deja pasar los Tokens que llegan uno tras otro, sin sincronización. Es decir, tiene la misma Configuración y el mismo comportamiento que la Compuerta Exclusiva Convergente.
Para evitar el uso de dos Compuertas que funcionan igual, se recomienda no usar la Compuerta de Eventos Convergente. En su lugar, debería usarse la Compuerta Exclusiva Convergente. (Recuérdese que incluso ésta, en un Flujo no Controlado, puede ser obviada.)
Por ejemplo, en la Especificación de BPMN (p.462) se muestra el Patrón de Decisión Exclusiva Basada en Eventos (Exclusive Event-Based Decision Pattern) que abre con una Compuerta de Eventos Divergente y cierra con una Compuerta Exclusiva Convergente.
Compuerta de Eventos - Convergente
Compuerta de Eventos Patrones de Uso
La Compuerta de Eventos se usa en Bloques Abiertos y Cerrados. (En Compuertas-Bloques encontrará una exposición exhaustiva sobre los distintos tipos de Bloques relacionados con las Compuertas.)
Los dos Bloques con Compuerta de Eventos más utilizados son:
- Bloque de Eventos Abierto: comienza con una Compuerta de Eventos Divergente con varios caminos excluyentes que continúan de manera independiente.
- Bloque de Eventos Cerrado: comienza con una Compuerta de Eventos Divergente con varios caminos excluyentes, y termina con una Compuerta Exclusiva Convergente que los une.
Los demás Bloques que comienzan o terminan con Compuerta de Eventos son inválidos o no prácticos.
En las secciones siguientes se describen los Bloques que comienzan con Compuerta de Eventos Divergente.
Compuerta de Eventos Bloque Abierto
Un Bloque (Exclusivo) de Eventos Abierto comienza con una Compuerta de Eventos Divergente que define varios caminos excluyentes que continúan de manera independiente.
En Token que salió de la Compuerta Divergente llegará a un Evento Final. Si no hay otros Tokens activos en el Proceso, éste termina.
Compuerta de Eventos - Bloque Abierto con Mensajes
Compuerta de Eventos - Bloque Abierto con Condicionales
Compuerta de Eventos Bloque Cerrado
Un Bloque de Eventos Cerrado comienza con una Compuerta de Eventos Divergente con varios caminos excluyentes. El Bloque termina con una Compuerta de Eventos Convergente que los une.
La Compuerta de Eventos en Configuración Convergente funciona igual que la Compuerta Exclusiva Convergente, es decir, los Tokens que arriban van pasando hacia la salida uno tras otro sin sincronización. Por este motivo, el Bloque Cerrado de Eventos funciona exactamente igual que el Bloque de Eventos-Exclusivo.
Por lo tanto, no es práctico usar el Bloque de Eventos Cerrado, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque de Eventos-Exclusivo.
Compuerta de Eventos - Bloque Cerrado
Compuerta de Eventos Bloque de Eventos-Exclusivo
Un Bloque de Eventos-Exclusivo comienza con una Compuerta de Eventos Divergente con varios caminos excluyentes. El Bloque termina con una Compuerta Exclusiva Convergente que los une.
En la Compuerta Exclusiva Convergente se produce una Unión Simple, es decir, el Token pasa directamente hacia el Flujo de Salida.
Compuerta de Eventos - Bloque de Eventos-Exclusivo
Compuerta de Eventos Bloque de Eventos-Paralelo
Un Bloque de Eventos-Paralelo comienza con una Compuerta de Eventos Divergente que define varios caminos excluyentes, y termina con una Compuerta Paralela Convergente que espera un Token en cada Flujo de Entrada para activarse.
Es un Modelo Inválido, pues la Compuerta de Eventos que comienza el Bloque solo deja pasar un Token, pero la Compuerta Paralela que cierra el Bloque espera Tokens por todos sus Flujos de Entrada (2 o más) y queda, de este modo, bloqueada.
Compuerta de Eventos - Bloque de Eventos-Paralelo
Compuerta de Eventos Bloque de Eventos-Inclusivo
Un Bloque de Eventos-Inclusivo comienza con una Compuerta de Eventos Divergente que define varios caminos excluyentes, y termina con una Compuerta Inclusiva Convergente que espera el Token que salió de la Compuerta Exclusiva.
Una Compuerta Inclusiva Convergente sincroniza varios Flujos de Secuencia alcanzables, es decir, aquellos por los cuales debe, en algún momento, llegar un Token.
En el Bloque de Eventos-Inclusivo, en cada ciclo de ejecución, hay solo un Flujo "alcanzable". Es decir, en este Bloque la Compuerta Inclusiva Convergente funciona igual que una Compuerta Exclusiva Convergente: llega un Token y lo deja pasar. Por este motivo, el Bloque de Eventos-Inclusivo funciona exactamente igual que el Bloque de Eventos-Exclusivo.
Por lo tanto, no es práctico usar el Bloque de Eventos-Inclusivo, pues no aporta un nuevo comportamiento. Es mejor usar el Bloque de Eventos-Exclusivo.
Compuerta de Eventos - Bloque de Eventos-Inclusivo
Compuerta de Eventos Bloque de Eventos-Complejo
Un Bloque de Eventos-Complejo comienza con una Compuerta de Eventos Divergente que define varios caminos excluyentes, y termina con una Compuerta Compleja Convergente que espera varios Tokens para evaluar su lógica de activación.
Es un Modelo Inválido, pues la Compuerta de Eventos que comienza el Bloque solo deja pasar un Token, pero la Compuerta Compleja que cierra el Bloque espera varios Tokens para funcionar como un Discriminador N/M (1 ≤ N < M).
A lo más, podría implementar un Discriminador 1/M, pero como la Compuerta de Eventos deja pasar un solo Token que la Compuerta Compleja siempre dejaría pasar, tendría un comportamiento equivalente al Bloque de Eventos-Exclusivo.
Por ejemplo, si la Compuerta Compleja implementa un Discriminador 2/3, entonces nunca se cumplirá la Condición de Activación: que lleguen Tokens por a lo menos dos de los Flujos de Entrada.
Compuerta de Eventos - Bloque de Eventos-Complejo
Compuerta de Eventos Compuertas Iniciales
BPMN 2.0 agregó dos variantes de la Compuerta de Eventos que permiten iniciar un Proceso: una Exclusiva y otra Paralela.
Puesto que son usados para comenzar el Proceso, las Compuertas de Eventos Iniciales no deben tener Flujos de Secuencia de Entrada. Además, por su naturaleza, solo pueden ser Divergentes.
Los Eventos que siguen a estas Compuertas son Intermedios, pero se comportan como Eventos Iniciales.
La Especificación de BPMN no hace referencia al posible uso de las Tareas de Recepción de Mensajes como alternativa a los Eventos de Captura de Mensajes. En la descripción de las Compuertas Iniciales hemos asumido que solo se usan Eventos para la captura de Mensajes.
Las Compuertas Iniciales de Eventos y los Eventos Iniciales se pueden combinar. Aunque es una Buena Práctica que todo Proceso tenga un y solo un punto de inicio.
Compuerta de Eventos Inicial Exclusiva
|
|
La Compuerta de Eventos Inicial Exclusiva Divergente tiene la siguiente configuración:
- Ningún Flujo de Secuencia de Entrada.
- Dos o más Flujos de Secuencia de Salida Incondicionales.
- Cada Flujo de Secuencia de Salida tiene un Evento Intermedio de Captura.
- Los Eventos deben ser de tipo Mensaje, Timer, Condicional, Señal o Múltiple.
- Si el Evento es de tipo Múltiple, entonces solo debe incluir Eventos de tipo Mensaje, Timer, Condicional o Señal.
- Los Eventos solo pueden tener un Flujo de Secuencia de Entrada, el que proviene de la Compuerta.
- Todos los Eventos son independentes.
Compuerta de Eventos Inicial Exclusiva - Configuración
La Compuerta de Eventos Inicial Exclusiva Divergente se activa de forma inmediata.
- Por cada Flujo de Salida pasa un Token hacia el Evento respectivo. Todos los Eventos quedan listos para gatillarse e iniciar el Proceso.
- El primer Evento que se gatilla activa su(s) Flujo(s) de Salida. Los demás Eventos son descartados, y sus respectivos Tokens son eliminados.
Por ejemplo, una visita a una planta industrial puede estar programada de antemano o ser solicitada en el momento. Si está programada ya se cuenta con todos los antecedentes necesarios (cantidad de personas, edades, etc.). Si la visita se solicita en el momento hay que recabar los antecedentes. El resto del Proceso es el mismo en ambos casos.
Compuerta de Eventos Inicial Exclusiva - Funcionamiento
Compuerta de Eventos Inicial Exclusiva Paralela
|
|
La Compuerta de Eventos Inicial Paralela Divergente tiene la siguiente Configuración:
- Ningún Flujo de Secuencia de Entrada.
- Dos o más Flujos de Secuencia de Salida Incondicionales.
- Cada Flujo de Secuencia de Salida tiene un Evento Intermedio de Captura.
- Los Eventos deben ser de tipo Mensaje.
- Los Eventos solo pueden tener un Flujo de Secuencia de Entrada, el que proviene de la Compuerta.
- Todos los Eventos Mensaje deben compartir un mismo propósito, en cuanto a que se refieren a una misma entidad de negocio: un mismo contrato, una misma factura, etc.
Compuerta de Eventos Inicial Paralela - Configuración
La Compuerta de Eventos Inicial Paralela Divergente se activa de forma inmediata.
- Por cada Flujo de Salida pasa un Token hacia el Evento respectivo. Todos los Eventos quedan listos para gatillarse e iniciar el Proceso.
- El primer Evento que se gatilla activa su(s) Flujo(s) de Salida. Los demás Eventos no son descartados, y se deben gatillar durante la ejecución normal de la instancia del Proceso.
Por ejemplo, la primera etapa de una auditoría consiste en dos caminos paralelos: uno involucra a la empresa a auditar y el otro a la entidad que regula la industria. Cada camino es iniciado por un Evento Mensaje: uno desde la empresa a auditar y otro desde la entidad reguladora. Los dos caminos convergen para la segunda etapa del Proceso.
Los dos Mensajes pueden llegar en distinto orden, algunas veces será primero el de la empresa, en otros casos será el de la entidad reguladora.
Compuerta de Eventos Inicial Paralela - Funcioamiento
Nótese que, si se necesitan Eventos Paralelos en el medio del Proceso, se puede usar una Compuerta Paralela normal.
Especificación BPMN
This Decision represents a branching point where Alternatives are based on an Event that occurs at that point in the Process (see page 296) or Choreography (see page 349). The specific Event, usually the receipt of a Message, determines which of the paths will be taken. Other types of Events can be used, such as Timer. Only one of the Alternatives will be chosen.[ok]
There are two options for receiving Messages: (1)Tasks of Type Receive can be used, and (2) Intermediate Events of Type Message can be used.[ok]
The Event-Based Gateway represents a branching point in the Process where the alternative paths that follow the Gateway are based on Events that occur, rather than the evaluation of Expressions using Process data (as with an Exclusive or Inclusive Gateway). A specific Event, usually the receipt of a Message, determines the path that will be taken. Basically, the decision is made by another Participant, based on data that is not visible to Process, thus, requiring the use of the Event-Based Gateway.[ok]
The Event Gateway shares the same basic shape of the Gateways, a diamond, with a marker placed within the diamond to indicate variations of the Gateway.[ok]
An Event Gateway is a diamond that MUST be drawn with a single thin line.[ok]
The marker for the Event Gateway MUST look like a catch Multiple Intermediate Event (see Figure 10.115).[ok]
Unlike other Gateways, the behavior of the Event Gateway is determined by a configuration of elements, rather than the single Gateway.[ok]
An Event Gateway MUST have two or more outgoing Sequence Flows. The outgoing Sequence Flows of the Event Gateway MUST NOT have a conditionExpression.[ok]
The objects that are on the target end of the Gateway’s outgoing Sequence Flows are part of the configuration of the Gateway.[ok]
Event-Based Gateways are configured by having outgoing Sequence Flows target an Intermediate Event or a Receive Task in any combination (see Figure 10.116 and Figure 10.117) except that if Message Intermediate Events are used in the configuration, then Receive Tasks MUST NOT be used in that configuration and vice versa. Receive Tasks used in an Event Gateway configuration MUST NOT have any attached Intermediate Events.[ok]
Only the following Intermediate Event triggers are valid: Message, Signal, Timer, Conditional, and Multiple (which can only include the previous triggers). Thus, the following Intermediate Event triggers are not valid: Error, Cancel, Compensation, and Link.[ok]
Target elements in an Event Gateway configuration MUST NOT have any additional incoming Sequence Flows (other than that from the Event Gateway).[ok]
When the first Event in the Event Gateway configuration is triggered, then the path that follows that Event will be used (a token will be sent down the Event’s outgoing Sequence Flows). All the remaining paths of the Event Gateway configuration will no longer be valid. Basically, the Event Gateway configuration is a race condition where the first Event that is triggered wins.[ok]
The Event-Based Gateway has pass-through semantics for a set of incoming branches (merging behavior). Exactly one of the outgoing branches is activated afterwards (branching behavior), depending on which of Events of the Gateway configuration is first triggered. The choice of the branch to be taken is deferred until one of the subsequent Tasks or Events completes. The first to complete causes all other branches to be withdrawn.[ok]
There are variations of the Event Gateway that can be used at the start of the Process. The behavior and marker of the Gateway will change.[ok]
Event Gateways can be used to instantiate a Process. By default the Gateway’s instantiate attribute is false, but if set to true, then the Process is instantiated when the first Event of the Gateway’s configuration is triggered.[técnico]
If the Event Gateway’s instantiate attribute is set to true, then the marker for the Event Gateway looks like a Multiple Start Event (see Figure 10.118).[técnico]
In order for an Event Gateway to instantiate a Process, it MUST not have any incoming Sequence Flows.[ok]
In some situations a modeler might want the Process to be instantiated by one of a set of Messages while still requiring all of the Messages for the working of the same Process instance. To handle this, there is another variation of the Event Gateway.[ok]
The Parallel Event Gateway is also a type of race condition. In this case, however, when the first Event is triggered and the Process is instantiated, the other Events of the Gateway configuration are not disabled. The other Events are still waiting and are expected to be triggered before the Process can (normally) complete. In this case, the Messages that trigger the Events of the Gateway configuration MUST share the same correlation information.[ok]
Attribute instantiate. When true, receipt of one of the Events will instantiate the Process instance.[técnico]
Attribute eventGatewayType. The eventGatewayType determines the behavior of the Gateway when used to instantiate a Process (as described above). The attribute can only be set to parallel when the instantiate attribute is set to true.[técnico]
Event-Based Gateways can be used at the start of a Process, without having to be a target of Sequence Flows. There can be multiple such Event-Based Gateways at the start of a Process. Ordinary Start Events and Event-Based Gateways can be used together.[ok]
Exception Issues: The event-based gateway cannot throw any exception.[técnico]
Workflow Patterns Support: Deferred Choice (WCP-16).
See Exclusive (Event-based) Decision Pattern on page 462.
