Un Evento es algo que "ocurre" durante el curso de un Proceso.
Los Eventos se dibujan con círculos, con diferentes características que representan:
- Posición - Dónde ocurre el Evento
- Al comienzo, durante o al final del Proceso.
- La línea del cículo: simple, doble o gruesa, representa la Posición del Evento.
- Modo - Cómo se materializa el Evento
- Llega un Mensaje, se envía un Mensaje, etc.
- El tono del marcador interno: claro u oscuro, indica si el Evento aguarda algo (espera un Mensaje), o produce un resultado (envía un Mensaje).
- La línea del círculo: continua o segmentada, indica si el Evento interrumpe o no una Actividad.
- Tipo - Qué causa el Evento
- Un Mensaje, una Condición, un Error, etc.
- Un marcador dentro del círculo representa el tipo del Evento.
Introducción
Un Evento espera que ocurra algo, o produce algo. En el primer caso, tiene una causa o Disparador que lo gatilla. En el segundo caso, tiene un impacto o Resultado.
Texto. texto. texto. texto. texto. texto.
Tipo
El término evento es lo suficientemente general para cubrir muchas cosas en un Proceso. El inicio de una Actividad, el final de una Actividad, el cambio de estado de un documento, un Mensaje que llega, etc., todos pueden ser considerados Eventos. Sin embargo, BPMN ha restringido el uso de Eventos para incluir solo aquellos tipos de Eventos que afectarán la secuencia o el tiempo de las Actividades de un Proceso.
Los Tipos de los Eventos se refieren a la causa de los Eventos de Captura (esperan la ocurrencia de "algo"), o el resultado de los Eventos de Lanzamiento (producen "algo"). Por ejemplo, esperar que se cumpla una fecha límite (Evento de tipo Timer), o lanzar una señal (Evento de tipo Señal).
Hay trece (13) Tipos de Eventos: Vacío, Mensaje, Timer, Error, Escalada, Cancelar, Compensación, Condicional, Enlace, Señal, Terminar, Múltiple y Múltiple Paralelo.
| Tipo | Inicial | Intermedio | Final | Descripción | |||
|---|---|---|---|---|---|---|---|
| Flujo Capt. | Flujo Lanz. | Borde Int. | Borde no Int. | ||||
| Vacío | No establece una causa o resultado. Usado para iniciar Subprocesos y para indicar el fin de flujos simples. | ||||||
| Mensaje | Envía o recibe un Mensaje. Usado para comunicar dos Procesos, cada uno en su propia Piscina. | ||||||
| Timer | Captura una condición temporal como un plazo, una fecha u hora específica, o un rango de los anteriores. | ||||||
| Error | Suspende la ejecución de un Subproceso. El Error es propagado al Proceso que contiene el Subproceso. | ||||||
| Escalada | Es semejane al Evento Error, pero no es una situación crítica. | ||||||
| Cancelar | Usado sólo en Subprocesos Transacción. Finaliza las Actividades en ejecución, y activa las Compensaciones. | ||||||
| Compensar | Comunica que una Actividad ya completada debe ser Compensada (reversada). | ||||||
| Condicional | Captura una condición de los datos que maneja el Proceso, por ejemplo, "el dólar bajó un 10%". | ||||||
| Enlace | Usado para evitar largos Flujos de Secuencia y/o evitar que éstos se crucen. | ||||||
| Señal | Envía o recibe una Señal. La Señal no tiene un destinatario específico, y actúa dentro y entre Procesos. | ||||||
| Terminar | Indica que todas las Actividades en ejecución en el Proceso deben terminar inmediatamente. | ||||||
| Múltiple | Define varios Eventos. Captura: solo se espera que ocurra uno para proseguir. Lanzamiento: todos se activan a la vez. | ||||||
| Múltiple Paralelo | Define varios Eventos de Captura. Todos deben ocurrir para proseguir. | ||||||
Como puede verse en la tabla anterior, no todos los tipos de Evento puede ser usados en todas las Posiciones (Inicio, Intermedio y Final). Por ejemplo, un Evento Terminador sólo puede ser Final, en cambio, un Evento Mensaje puede estar en cualquier posición.
Para distinguir la Posición y el Modo de un mismo Tipo de Evento se utilizan variaciones en las líneas y tonos de la figura:
- Los Eventos Iniciales se dibujan con línea delgada.
- Los Eventos Intermedios se dibujan con línea doble.
- Los Eventos Finales se dibujan con línea gruesa.
- Los Eventos de Captura tienen su Marcador interno en tono claro.
- Los Eventos de Lanzamiento tienen su Marcador interno en tono oscuro.
- Los Eventos que No Interrumpen se dibujan con línea segmentada.
Los distintos Modos de un Evento (Captura / Lanzamiento, Interrupción / No Interrupción) no son posibles en todas las Posiciones.
- Si el Tipo de Evento está en Posición Inicial, entonces siempre está en Modo Captura.
- Si el Tipo de Evento está en Posición Final, entonces siempre está en Modo Lanzamiento.
- Si el Tipo de Evento está en Posición Intermedia sobre un Flujo de Secuencia, entonces puede estar en Modo Captura o Lanzamiento.
- Si el Tipo de Evento está en Posición Intermedia sobre el Borde de una Actividad, entonces siempre está en Modo Captura, y puede Interrupir o No Interrumpir.
Cada vez que se ocurre un Evento de Captura llegan datos al Proceso, los que pueden ser colocados en Objetos de Datos.
Posición
Hay tres tipos de controladores de eventos: los que inician un proceso, los que forman parte del flujo de secuencia normal y los que se adjuntan a las actividades, ya sea a través de eventos de límite o mediante controladores en línea independientes en el caso de un subproceso de evento.
Las diferentes posiciones de los eventos (inicio, fin e intermedio) utilizan un subconjunto de los tipos disponibles de definiciones de eventos.
Comienzo. Como su nombre lo indica, el evento de inicio indica dónde comenzará un proceso (consulte la página 235) o una coreografía (consulte la página 339) en particular.
Intermedio: los eventos intermedios ocurren entre un evento de inicio y un evento de finalización. Afectarán el flujo del Proceso (consulte la página 237) o la Coreografía (consulte la página 340), pero no iniciarán ni terminarán (directamente) el Proceso.
Final. Como su nombre lo indica, el Evento de Fin indica dónde terminará un Proceso (ver página 245) o una Coreografía (ver página 343).
Texto. texto. texto. texto. texto. texto.
Inicial
Texto. texto. texto. texto. texto. texto.
Un Evento Inicial indica dónde comenienza un Proceso. Es decir, inicia el Flujo del Proceso y, por lo tanto, no no tiene Flujos de Secuencia entrantes.
El Evento Inicial se representa con un círculo de línea delgada con un centro abierto para colocar Marcadores que indican el Tipo del Evento.
El Evento Inicial es opcional. Sin embargo, es una buena práctica que todo Proceso (Principal o Subproceso) tenga un Evento Inicial. Hay dos excepciones:
- Un Subproceso Embedido usado para "cajas paralelas" nunca debe tener Evento Inicial, ni Final.
- Un Subproceso Evento siempre deber tener un y sólo un Evento Inicial.
Si no hay Evento Inicial, entonces todos los Objetos de Flujo que no tengan un Flujo de Secuencia entrante serán instanciados cuando se instancia el Proceso. Las excepciones a esto son:
- Las Actividades de Compensación (tiene el marcador de Compensación), que no son parte del Flujo Normal, no deben instanciarse cuando se instancia el proceso.
- Eventos Intermedios Enlace de Captura, que no pueden tener Flujos de Secuencia entrantes.
- Subprocesos Evento, que no pueden tener Flujos de Secuencia entrantes y solo se instancian cuando se gatillan Eventos Iniciales.
Un Proceso puede tener más de un Evento Inicial. Cada Evento Inicial es un Evento independiente. Es decir, se genera una instancia del Proceso cuando se activa el Evento Inicial. Es una buena práctica que el Proceso tenga sólo un Evento Inicial, pues los lectores del diagrama podrían tener dificultades para comprender la intención del modelador.
Si hay un Evento Final, debe haber al menos un Evento Inicial.
Cuando se gatilla un Evento Inicial, se crea una nueva instancia del Proceso y se genera un Token para cada Flujo de Secuencia saliente del Evento.
También se puede iniciar un Proceso a través de una Compuerta de Eventos. Para mayor detalle ver xxxx.
Los eventos de inicio se pueden utilizar para estos tipos de Procesos:
- Proceso Principal (Top-level Process)
- Proceso Global (Proceso Principal referenciado por una Actividad de Llamada)
- Subproceso Embebido
- Subproceso Evento
Eventos Iniciales para Proceso Principal
Hay siete (7) Tipos de Eventos que pueden usarse para iniciar (instanciar) un Proceso Principal: Vacío, Mensaje, Timer, Condicional, Señal, Múltiple y Múltiple Paralelo.
Evento Inicial para Subproceso Embebido y Proceso Global
Sólo puede usarse el Evento Inicial Vacío.
Manejo de eventos de inicio
Para un Evento Inicial único, el manejo consiste en iniciar una nueva instancia del Proceso cada vez que ocurre el Evento. Los Flujos de Secuencia que salen del Evento se siguen como de costumbre. Para múltiples eventos de inicio, BPMN admite varios escenarios de modelado que se pueden aplicar según el escenario.
Para múltiples Eventos Iniciales, BPMN admite varios escenarios.
Inicio exclusivo: el Proceso comienza cuando ocurre un Evento de entre varios posibles. Cada ocurrencia de uno de estos Eventos crea una nueva instancia del Proceso. Por ejemplo (ver Figura 10.97), si el Proceso tiene dos Eventos Iniciales, en tiempo de ejecución, cada ocurrencia de uno de los Eventos conducirá a la creación de una nueva instancia del Proceso. Nótese que un único Evento Inicial Múltiple que contenga estos dos Eventos se comportaría de la misma manera.
Un Proceso también se puede iniciar a través de una Compuerta de Eventos (Figura 10.98), o un Evento Inicial Múltiple Paralelo.
Si el modelador requiere que varios eventos de inicio disjuntos se fusionen en una sola instancia de proceso (Figura 10.99), entonces debe usar un Evento Inicial paralelo, que puede agrupar varios Eventos Iniciales, cada uno de los cuales debe ocurrir una vez para que se instancie el Proceso. Los Flujos de Secuencia salientes se siguen como de costumbre.
| Tipo | Proceso Principal | Subproceso | Descripción |
|---|---|---|---|
| None | Descripción | ||
| Message | Descripción | ||
| Timer | Descripción | ||
| Error | Descripción | ||
| Escalation | Descripción | ||
| Cancel | Descripción | ||
| Compensation | Descripción | ||
| Conditional | Descripción | ||
| Link | Descripción | ||
| Signal | Descripción | ||
| Terminate | Descripción | ||
| Multiple | Descripción | ||
| Parallel Multiple | Descripción |
Conexiones con Flujos de Secuencia
Un Evento Inicial no debe tener Flujos de Secuencia entrantes.
La única excepción es cuando se usa un Evento Inicial en un Subproceso Expandido y se coloca en el borde del Subproceso. En este caso, un Flujo de Secuencia del Proceso de nivel superior puede conectarse a ese Evento Inicial en lugar de conectarse al borse del Subproceso.
Un Evento Inicial debe tener Flujos de Secuencia salientes, cada uno de los cuales genera una nueva ruta paralela.
Los Flujos de Secuencia salientes de un Evento no pueden ser condicionales, ni un Flujo de Secuencia por Defecto.
Cuando no se usa un Evento Inicial, todos los Objetos de Flujo que no tienen un Flujo de Secuencia entrante serán el inicio de una ruta paralela separada, con su propio Token.
Conexiones de Flujo de Mensaje
NOTA: Los Flujos de Mensaje siempre deben conectar dos Piscinas separadas, no pueden conectar dos objetos dentro de la misma Piscina.
Un Evento Inicial nunca puede ser el origen de un Flujo de Mensaje.
Sólo los Eventos Iniciales de tipo: Mensaje, Múltiple y Múltiple Paralelo, pueden tener cero (0) o más Flujos de Mensaje entrantes. En el caso de Múltiple y Múltiple Paralelo, a lo menos uno de los Eventos involucrados debe ser de tipo Mensaje.
Cada Flujo de Mensajes que llega a un Evento Inicial puede instanciar el Proceso. Solo se requiere que llegue un Mensaje por un de los Flujos para iniciar el Proceso. Excepto cuando se usa el Múltiple Paralelo.
Texto. texto. texto. texto. texto. texto.
Intermedio
Un Evento Intermedio indica que algo sucede en algún lugar entre el inicio y el final del Proceso. Afecta el Flujo del Proceso, pero no lo inicia ni termina.
El Evento Intermedio se representa con un círculo de línea doble con un centro abierto para colocar Marcadores que indican el Tipo del Evento.
Los Eventos Intermedios se utilizan para:
- Mostrar dónde el Proceso comunica, a sí mismo o a otros Procesos, que algo ha ocurrido. Por ejemplo, mediante un Mensaje, le comunica a otro Proceso que la Cotización ha sido aceptada.
- Indicar dónde el Proceso entra en pausa. Por ejemplo, espera que se cumpla una fecha límite para continuar el trabajo.
- Romper el Flujo Normal e indicar el comienzo de un Flujo de Excepción. Por ejemplo, si se produce un error en un Subproceso, éste es interrumpido y el Evento Intermedio marca el comienzo del Flujo de Excepción que manejará el error.
- Marcar dónde se debe aplicar una Compensación.
Cuando los Eventos Intermedios se usan para representar el manejo de Excepciones o Compensaciones, se colocan en el borde de la Actividad afectada. Esta puede ser una Tarea o un Subproceso (expandido o colapsado).
El Evento Intermedio puede en cualquier parte del borde de la Actividad, y los Flujos de Secuencia salientes del Evento pueden ir en cualquier dirección. Sin embargo, para mayor claridad de los diagramas, se recomienda elegir una ubicación y usarla consistentemente en todos los diagramas. Por ejemplo, para diagramas orientados horizontalmente, los Eventos Intermedios se pueden colocar en el borde inferior de la Actividad, y los Flujos de Secuencia se dirigen hacia abajo y luego a la derecha.
Para Eventos Intermedios en el Flujo en modo captura, el manejo consiste en esperar a que ocurra el Evento. La espera comienza cuando el Flujo llega al Evento Intermedio. Una vez que ocurre el Evento, se consume, y los Flujos de Secuencia que salen del Evento se siguen como de costumbre.
Los Eventos Intermedios de captura y lanzamiento de Mensajes tienen el mismo comportamiento que las Tareas de Recepción y Envío de Mensaje respectivamente.
Los Eventos Intermedios en el Borde de una Actividad siempre son en modo captura. El manejo consiste esperar y consumir el Evento. Si es un Evento Interruptor, la Actividad se cancela. Si es un Evento No Interruptor, la Actividad continúa ejecutándose. En ambos casos, se sigue el Flujo de Secuencia de Excepción que sale del Evento.
Si es un Evento Intermedio en el Borde en modo Interruptor y la Actividad es Multi Instancia, todas sus instancias se cancelan.
Tipos de Eventos Intermedios
Un Evento Intermedio puede estar en una de dos posiciones: en el Flujo o en el Borde de una Actividad.
Si está en el Flujo, puede estar en Modo Captura o en Modo Lanzamiento.
Si está en el Borde de una Actividad, siempre está en Modo Captura, pero puede estar en Modo Interruptor o No Interruptor.
Hay trece Tipos de Eventos, un Evento Intermedio puede ser de cualquier Tipo excepto Terminador. Sin embargo, no todos los Tipos pueden estar en todos los Modos permitidos. Por ejemplo, el Evento Intermedio de Tipo Mensaje puede estar en el Flujo (en Captura o Lanzamiento) y en el Borde (Interruptor y No Interruptor), pero Evento Intermedio de Tipo Error sólo puede estar en el Borde de una Actividad en Modo Interruptor.
Eventos Intermedios en el Flujo.
Cuando un Token llega a un Evento Intermedio colocado en Flujo de un Proceso, sucede una de dos cosas:
- Si el Evento está en Modo Lanzamiento, entonces el Evento ocurre inmediatamente (por ejemplo, se envia un Mensaje), y luego el Token seguirá por el o los Flujos de Secuencia salientes.
- Si el Evento está en Modo Captura, entonces el Token permanecerá en el Evento hasta que éste ocurra (por ejemplo, se recibe un Mensaje). Una vez que ocurre el Evento, se consume. Los Flujos de Secuencia que salen del Evento se siguen como de costumbre.
Diez de los doce Tipos de Eventos Intermedios se pueden utilizar en el Flujo.
Eventos Intermedios en el Borde de una Actividad.
Si en Evento está en Modo Interruptor, se dibuja de manera normal, con una línea continua. Si está en Modo No Interruptor, se dibuja con una línea segmentada. Si la Actividad no es cancelada, el Evento puede ocurrir varias veces.
Uno más Eventos Intermedios, de los permitidos, puede colocarse en el Borde de una Actividad. Un Evento Intermedio Cancelar sólo se puede colocar en el Borde un Subproceso Transacción.
Para Eventos Intermedios en el Borde de una Actividad en Modo Interrupción, una vez que ocurre el Evento, se consume el Evento y se cancela la Actividad. El Flujo de Secuencia (de excepción) que salen del Evento se sigue como de costumbre. Por lo general, se une nuevamente al Flujo de Control Principal, aunque también puede crear un camino independiente con su propio fin.
Para Eventos Intermedios en el Borde de una Actividad en Modo No Interrupción, el comportamiento es el mismo, excepto que la Actividad no es cancelada. Dado que se genera un Token para el Flujo de Secuencia desde el Evento en el Borde mientras la Actividad continúa ejecutando, se debe cuidado si éste Flujo se une al Flujo de Control Principal; por lo general, se prefiere un camino independiente con su propio fin.
Un Subproceso Evento tiene acceso al contexto del Subproceso que lo contiene. En cambio un Controlador de Excepción accesado desde un Evento en el Borde no tiene acceso al contexto de la Actvidad donde está el Evento.
Sólo puede modelarse un Evento Intermedio de Borde Interruptor para un mismo Evento. De este modo, en caso de ocurrir el Evento el Proceso sólo seguirá un camino. Esta restricción incluye el hecho de que para un mismo Evento Eventos Intermedios de Borde interruptores y no interruptores.
Para Eventos no interruptores, se puede modelar y ejecutar en paralelo un número ilimitado de Eventos Intermedios de Borde para el mismo Evento. En tiempo de ejecución, se invocarán en un orden no determinista.
Manejadores de eventos sin interrupción (escala, mensaje, señal, temporizador, condicional, múltiple y múltiple en paralelo)
| Type | En el Flujo Captura | En el Flujo Lanzamiento | En el Borde Interruptor | En el Borde No Interruptor |
|---|---|---|---|---|
| None | ||||
| Message | ||||
| Timer | ||||
| Error | ||||
| Escalation | ||||
| Cancel | ||||
| Compensation | ||||
| Conditional | ||||
| Link | ||||
| Signal | ||||
| Terminate | ||||
| Multiple | ||||
| Parallel Multiple |
Conexiones con Flujos de Secuencia
Si el Evento Intermedio está en el Borde de una Actividad, excepto si es de Tipo Compensación:
- No debe tener Flujos de Secuencia entrantes.
- Debe tener Flujos de Secuencia salientes, cada uno de los cuales genera una nueva ruta paralela.
Si es de Tipo Compensación, entonces no debe tener Flujos de Secuencia entrantes ni salientes. Debe tener una asociación hacia el Manejador de la Compensación.
Si es Evento Intermedio en el Flujo, excepto si es de Tipo Enlace:
- Debe tener a lo menos un Flujo de Secuencia entrante. Si varios Flujos de Secuencia entrantes, se considera un Flujo no Controlado, esto significa que cuando llega un Token por uno de los Flujos, se habilitará el Evento (para Captura o Lanzamiento). Si llega otro Token por el mismo u otro Flujo, se creará una instancia separada del Evento. Si se necesita controlar el Flujo, entonces se debería colocar una Compuerta que sincronize los Flujos antes del Evento.
- Debe tener Flujos de Secuencia salientes, cada uno de los cuales genera una nueva ruta paralela.
na excepción a esto es el Evento Intermedio de Enlace: un Evento Intermedio de Enlace lanzador NO DEBE tener un Flujo de Secuencia saliente. Y un evento intermedio de enlace de captura NO DEBE tener un flujo de secuencia entrante.
Si es un Evento Intermedio en el Flujo de Tipo Enlace:
- Si de Lanzamiento, debe tener a lo menos un Flujo de Secuencia entrante, y ningún Flujo de Secuencia saliente.
- Si es Captura, no debe tener Flujos de Secuencia entrantes, y debe tener a lo menos un Flujo de Secuencia saliente.
Conexiones de Flujo de Mensaje
NOTA: Los Flujos de Mensaje siempre deben conectar dos Piscinas separadas, no pueden conectar dos objetos dentro de la misma Piscina.
Los únicos Eventos que pueden estar conectados a Flujos de Mensaje son aquellos de tipos Mensaje.
- Si es de Captura, puede tener un Flujo de Mensaje entrante. No debe tener Flujo de Mensaje saliente.
- Si es de Lanzamiento, puede tener un Flujo de Mensajes saliente. No debe tener Flujo de Mensaje entrante.
- Un evento intermedio de mensaje PUEDE tener un flujo de mensajes entrantes o un flujo de mensajes salientes, pero no ambos.
El Flujo de Mensaje es opcional porque el Participante que envía o recibe el Mensaje puede no estar mostrado en el diagrama.
En el Borde
Para los eventos límite, el manejo consiste en consumir la ocurrencia del evento y cancelar la actividad a la que está asociado el evento, seguido de flujos de secuencia normales que abandonan esa actividad, o ejecutar un controlador de eventos sin cancelar la actividad (solo para mensajes, señales, temporizadores y eventos). Eventos condicionales, no para eventos de error).
Un evento de límite de interrupción se define por un valor verdadero de su atributo cancelActivity. Cada vez que ocurre el Evento, la Actividad asociada finaliza. Luego se genera un token descendente, que activa el siguiente elemento del Proceso (conectado al Evento por un Flujo de Secuencia incondicional llamado flujo de excepción).
Para eventos de límite que no interrumpen, el atributo cancelActivity se establece en falso. Cada vez que ocurre el Evento, la Actividad asociada continúa activa. Dado que se genera un token para el flujo de secuencia desde el evento límite en paralelo a la ejecución continua de la actividad, se DEBE tener cuidado cuando este flujo se fusiona con el flujo principal del proceso; por lo general, debe finalizar con su propio evento final. .
Los controladores de eventos de interrupción: Cada vez que ocurre el evento la actividad asociada se interrumpe. Se siguen los flujos de secuencia de ese evento de límite. La actividad principal se cancela después se sigue el flujo de secuencia del evento límite.
Para eventos de límite, cada vez que ocurre el evento, el controlador se ejecuta simultáneamente con la actividad. Si también se especifica un Subproceso de Evento para ese Evento (en el caso de un Subproceso), se ejecuta dentro del contexto de ese Subproceso. Luego, se siguen los flujos de secuencia del evento límite. Dado que se genera un token para el flujo de secuencia desde el evento límite en paralelo a la ejecución continua de la actividad, se DEBE tener cuidado cuando este flujo se fusiona con el flujo principal del proceso; por lo general, debe finalizar con su propio evento final. .
Texto. texto. texto. texto. texto. texto.
Final
Un Evento Final indica dónde termina un Proceso.
El Evento Final no tiene Flujos de Secuencia salientes.
El Evento Final se representa con un círculo de línea gruesa con un centro abierto para colocar Marcadores que indican el Tipo del Evento
El Evento Final consume un Token que se generó en un Evento Inicial dentro del mismo nivel de Proceso. Si varios Flujos de Secuencia paralelos llegan al Evento Final, los Tokens se consumirán a medida que vayan lleguando. Todos los tokens que se generaron dentro del Proceso DEBEN ser consumidos por un Evento de finalización antes de que se complete el Proceso.
Todos los Tokens que se generan dentro del Proceso deben ser consumidos por Evento Finales para que se complete el Proceso.
Un Subproceso puede detenerse antes de su final normal mediante por la ocurrencia de un Evento Intermedio Interruptor en su Borde. En este caso, los Tokens serán consumidos por el Evento que provocó la interrupción.
Si un Flujo no tiene Evento Final, el Token que lo recorre se consumirá una vez que se complete la Actividad que marca el final del Flujo, como si hubiera un Evento Final Vacío después de dicha Actividad.
La instancia de un Proceso termina cuando se consumen todos los Tokens generados.
Semántica del Evento Final:
Puede haber varios Eventos Finales dentro de un nivel de Proceso: Proceso Princial, Subprocesos Embebidos, Llamadas a Procesos Globales. El uso de Eventos Iniciales y Finales es independiente para cada nivel de Proceso.
El Evento Final es opcional, pero es una buena práctica colocar Eventos Finales al término de cada Flujo.
La buena práctica es que se usan Eventos Inciales y Finales en el inicio y final de todos los Flujos de Proceso de cualquier nivel. La única excepción es un Subproceso Embebido usado para crear una "caja paralela", que no tiene Eventos Iniciales ni Finales.
Un Evento Finales siempre está en modo Lanzamiento. Para estos Eventos no apliza el modo Interruptor/No Interruptor.
Hay nueve (9) Tipos de Eventos que pueden usarse para finalizar un Flujo de un Proceso: Vacío, Mensaje, Escalada, Error, Cancelar, Compensación, Señal, Terminar y Múltiple. Cada tipo define la consecuencia (resultado) de alcanzar el Evento Final.
Manejo de eventos finales
Para un Evento Final Terminar, se terminan todas las Actividades activas restantes dentro del Proceso.
Un Evento Final Cancelar sólo se permite dentro de Subproceso Transacción y, como tal, cancela el Subproceso y aborta una Transacción asociada.
Para todos los demás Eventos Finales, se realiza el comportamiento determinado por su tipo, por ejemplo, lanzar un Mensaje. Cuando no hay más Actividades activas, entonces se completa la instancia del Subproceso o Proceso.
| Type | End Throwing | Description |
|---|---|---|
| None | Descripción | |
| Message | Descripción | |
| Timer | Descripción | |
| Error | Descripción | |
| Escalation | Descripción | |
| Cancel | Descripción | |
| Compensation | Descripción | |
| Conditional | Descripción | |
| Link | Descripción | |
| Signal | Descripción | |
| Terminate | Descripción | |
| Multiple | Descripción | |
| Parallel Multiple | Descripción |
Evento Final Terminar
- Proceso Principal: Cuando se llega a un Evento Final Terminar, la instancia del Proceso finaliza de manera anormal. Otras posibles instancias activas del Proceso no se ven afectadas.
- Subproceso: Cuando se llega a un Evento Final Terminar, la instancia del Subproceso finaliza de manera anormal. No se ven afectadas otras instancias de Subprocesos en curso o instancias de Procesos de nivel superior. Si es un Subproceso de Multi Instancia, sólo se termina la instancia afectada.
Para todos los demás Eventos Finales, se realiza el comportamiento asociado con el tipo del Evento, por ejemplo, el Evento Señal emite la señal asociada.
La instancia del Proceso o Subproceso se completa, si y sólo no queda ningún Token dentro de la instancia.
Conexiones con Flujos de Secuencia
Un Evento Final debe tener Flujos de Secuencia entrantes.
El Evento Final consume los Token que llegan por los Flujos de Secuencia entrantes.
Los Flujos de Secuencia pueden provenir de caminos alternativos o paralelos. Por conveniencia de modelado, cada camino puede conectarse a su propio Evento Final.
Un Evento Final no debe tener Flujos de Secuencia salientes.
Una excepción a esto es cuando se usa un Evento Final en un Subproceso Expandido y se coloca en el borde del Subproceso. En este caso, un Flujo de Secuencia del Proceso de nivel superior puede conectarse desde ese Evento Final en lugar de conectarse desde el borde del Subproceso.
Conexiones con Flujos de Mensaje
NOTA: Los Flujos de Mensaje siempre deben conectar dos Piscinas separadas, no pueden conectar dos objetos dentro de la misma Piscina.
Un Evento Final nunca puede ser el destino de un Flujo de Mensaje.
Sólo los Eventos Finales de tipo: Mensaje (1) y Múltiple (1 o más), pueden tener cero (0) o más Flujos de Mensaje salientes.
Si el Evento Final es Múltiple, a lo menos uno de los Eventos involucrados debe ser de tipo Mensaje. Al gatillarse el Evento, por cada Cada Flujo de Mensaje saldrá un Mensaje.
El Flujo de Mensaje es opcional porque el Participante que envía o recibe el Mensaje puede no estar mostrado en el diagrama.
Modo
BPMN proporciona construcciones avanzadas para tratar con eventos que ocurren durante la ejecución de un proceso (es decir, la "captura" de un evento). Además, BPMN admite la creación explícita de un Evento en el Proceso (es decir, el "lanzamiento" de un Evento).
Texto. texto. texto. texto. texto. texto.
Captura
Para Eventos Intermedios, el manejo consiste en esperar a que ocurra el Evento. La espera comienza cuando se alcanza el Evento Intermedio. Una vez que ocurre el Evento, se consume. Los flujos de secuencia que salen del Evento se siguen como de costumbre.
xxxxxxx
Texto. texto. texto. texto. texto. texto.
Especificación BPMN
Type Dimension (e.g., None, Message, Timer, Error, Cancel, Compensation, Conditional, Link, Signal, Multiple, Terminate.)
Event Definitions refers to the triggers of Catch Events (Start and receive Intermediate Events) and the Results of Throw Events (End Events and send Intermediate Events).
The Start and some Intermediate Events have “triggers” that define the cause for the Event (See “Start Event” on page 237. and “Intermediate Event” on page 248). There are multiple ways that these events can be triggered. End Events MAY define a “result” that is a consequence of a Sequence Flow path ending. Start Events can only react to (“catch”) a trigger. End Events can only create (“throw”) a result. Intermediate Events can catch or throw triggers. For the Events, triggers that catch, the markers are unfilled, and for triggers and results that throw, the markers are filled.
Additionally, some Events, which were used to interrupt Activities in BPMN 1.1, can now be used in a mode that does not interrupt. The boundary of these Events is dashed (see figure to the right).
Forwarding the trigger to catching Events
Depending on the type of the Event there are different strategies to forward the trigger to catching Events: publication, direct resolution, propagation, cancellations, and compensations.
Messages are triggers, which are generated outside of the Pool they are published in. They typically describe B2B communication between different Processes in different Pools. When Messages need to reach a specific Process instance, correlation is used to identify the particular instance.
Signals are triggers generated in the Pool they are published. They are typically used for broadcast communication within and across Processes, across Pools, and between Process diagrams.
Timer and Conditional triggers are implicitly thrown. When they are activated they wait for a time based or status based condition respectively to trigger the catch Event.
A trigger that is propagated is forwarded from the location where the Event has been thrown to the innermost enclosing scope instance (e.g., Process level) which has an attached Event being able to catch the trigger. Error triggers are critical and suspend execution at the location of throwing. Escalations are non critical and execution continues at the location of throwing. If no catching Event is found for an error or escalation trigger, this trigger is unresolved. Termination, compensation, and cancellation are directed towards a Process or a specific Activity instance. Termination indicates that all Activities in the Process or Activity should be immediately ended. This includes all instances of multi-instances. It is ended without compensation or Event handling.
Cancellation will terminate all running Activities and compensate all successfully completed Activities in the Sub- Process it is applied to. If the Sub-Process is a Transaction, the Transaction is rolled back.
Common Event attributes
properties. Modeler-defined properties MAY be added to an Event. These properties are contained within the Event.
Common Catch Event attributes
eventDefinitions (ordered set). Defines the event's EventDefinitions that are triggers expected for a catch Event. These EventDefinitions are only valid inside the current Event.
- If there is no EventDefinition defined, then this is considered a catch None Event and the Event will not have an internal marker (see Figure 10.91).
- If there is more than one EventDefinition defined, this is considered a catch Multiple Event and the Event will have the pentagon internal marker (see Figure 10.90).
eventDefinitionRefs. References the reusable EventDefinitions that are triggers expected for a catch Event. Reusable EventDefinitions are defined as top-level elements. These EventDefinitions can be shared by different catch and throw Events.
parallelMultiple (boolean = false). This attribute is only relevant when the catch Event has more than one EventDefinition (Multiple). If this value is true, then all of the types of triggers that are listed in the catch Event MUST be triggered before the Process is instantiated. (This is true for a start multiple event, check this when it is an inetermediate and an end event.)
As the name implies, the Start Event indicates where a particular Process will start. In terms of Sequence Flows, the Start Event starts the flow of the Process, and thus, will not have any incoming Sequence Flows— no Sequence Flow can connect to a Start Event.
The Start Event shares the same basic shape of the Intermediate Event and End Event, a circle with an open center so that markers can be placed within the circle to indicate variations of the Event.
A Start Event is a circle that MUST be drawn with a single thin line (see Figure 10.70). The thickness of the line MUST remain thin so that the Start Event can be distinguished from the Intermediate and End Events.
A Start Event is OPTIONAL: a Process level—a top-level Process, a Sub-Process (embedded), or a Global Process (called Process)—MAY (is NOT REQUIRED to) have a Start Event.
A Process MAY have more than one Process level (i.e., it can include Expanded Sub-Processes or Call Activities that call other Processes). The use of Start and End Events is independent for each level of the Diagram. (The usage of expanded Sub-Processes for “parallel boxes” is the motivation for having Start and End Events being optional objects. It is a good practice to use start and end events, even if they are none events.)
If a Process is complex and/or the starting conditions are not obvious, then it is RECOMMENDED that a Start Event be used.
The behavior of Process can be harder to understand if there are multiple Start Events. It is RECOMMENDED that this feature be used sparingly and that the modeler be aware that other readers of the Diagram could have difficulty understanding the intent of the Diagram.
If there is an End Event, then there MUST be at least one Start Event.
If a Start Event is not used, then the implicit Start Event for the Process SHALL NOT have a trigger. All Flow Objects that do not have an incoming Sequence Flow (i.e., are not a target of a Sequence Flow) SHALL be instantiated when the Process is instantiated. Exceptions to this are:
- Activities that are defined as being Compensation Activities (it has the Compensation marker). Compensation Activities are not considered a part of the normal flow and MUST NOT be instantiated when the Process is instantiated. See page 301 for more information on Compensation Activities.
- Catching Link Intermediate Events, which are not allowed to have incoming Sequence Flows. See page 266 for more information on Link Intermediate Events.
- Event Sub-Processes, which are not allowed to have incoming Sequence Flows and will only be instantiated when their Start Events are triggered. See page 174 for more information on Event Sub-Processes.
When the trigger for a Start Event occurs, a new Process will be instantiated and a token will be generated for each outgoing Sequence Flow from that Event.
There MAY be multiple Start Events for a given Process level. Each Start Event is an independent Event. That is, a Process instance SHALL be generated when the Start Event is triggered.
For single Start Events, handling consists of starting a new Process instance each time the Event occurs. Sequence Flows leaving the Event are then followed as usual.
Start Events can be used for these types of Processes:
- Top-level Processes
- Global Process (called)
- Sub-Processes (embedded)
- Event Sub-Processes
Start Events for Top-level Processes
There are many ways that top-level Processes can be started (instantiated). The trigger for a Start Event is designed to show the general mechanisms that will instantiate that particular Process. There are seven (7) types of Start Events for top-level Processes in BPMN (see Table 10.84): None, Message, Timer, Conditional, Signal, Multiple, and Parallel.
Start Event for Globlal Process (called)
Start Events for Sub-Processes
There is only one type of Start Event for Sub-Processes in BPMN (see Figure 10.82): None.
Handling Start Events
There are multiple ways in which a Process can be started. For single Start Events, handling consists of starting a new Process instance each time the Event occurs. Sequence Flows leaving the Event are then followed as usual. For multiple Start Events, BPMN supports several modeling scenarios that can be applied depending on the scenario.
Exclusive start: the most common scenario for starting a Process is its instantiation by exactly one out of many possible Start Events. Each occurrence of one of these Events will lead to the creation of a new Process instance. The following example shows two Events connected to a single Activity (see Figure 10.97). At runtime, each occurrence of one of the Events will lead to the creation of a new instance of the Process instance and activation of the Activity. Note that a single Multiple Start Event that contains the Message Event Definitions would behave in the same way.
Event synchronization: if the modeler requires several disjoint Start Events to be merged into a single Process instance, then the following notation MUST be applied (Figure 10.99).
The Parallel Start Event MAY group several disjoint Start Events each of which MUST occur once in order for an instance of the Process to be created. Sequence Flows leaving the Event are then followed as usual.
See page 440 for the execution semantics for the Event Handling of Start Events.
Sequence Flow Connections
A Start Event MUST NOT be a target for Sequence Flows; it MUST NOT have incoming Sequence Flows.
- An exception to this is when a Start Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect to that Start Event in lieu of connecting to the actual boundary of the Sub-Process.
A Start Event MUST be a source for a Sequence Flow.
Multiple Sequence Flows MAY originate from a Start Event. For each Sequence Flow that has the Start Event as a source, a new parallel path SHALL be generated.
The conditionExpression attribute for all outgoing Sequence Flows MUST be set to None.
When a Start Event is not used, then all Flow Objects that do not have an incoming Sequence Flow SHALL be the start of a separate parallel path. Each path will have a separate unique token that will traverse the Sequence Flow.
Message Flow Connections
NOTE: All Message Flows MUST connect two separate Pools. They MAY connect to the Pool boundary or to Flow Objects within the Pool boundary. They MUST NOT connect two objects within the same Pool.
A Start Event MAY be the target for a Message Flow; it can have zero (0) or more incoming Message Flows. Each Message Flow targeting a Start Event represents an instantiation mechanism (a trigger) for the Process. Only one of the triggers is REQUIRED to start a new Process. (Except when the Parallel Multiple is used.)
Only Message, Multiple and Parallel Multiple should be targets for Message Flows.
A Start Event MUST NOT be a source for a Message Flow; it MUST NOT have outgoing Message Flows.
As the name implies, the Intermediate Event indicates where something happens (an Event) somewhere between the start and end of a Process. It will affect the flow of the Process, but will not start or (directly) terminate the Process.
The Intermediate Event shares the same basic shape of the Start Event and End Event, a circle with an open center so that markers can be placed within the circle to indicate variations of the Event. An Intermediate Event is a circle that MUST be drawn with a double thin line.
Intermediate Events can be used to:
- Show where Messages are expected or sent within the Process.
- Show where delays are expected within the Process,
- Disrupt the normal flow through exception handling, or
- Show the extra work needed for compensation.
One use of Intermediate Events is to represent exception or compensation handling. This will be shown by placing the Intermediate Event on the boundary of a Task or Sub-Process (either collapsed or expanded). The Intermediate Event can be attached to any location of the Activity boundary and the outgoing Sequence Flows can flow in any direction. However, in the interest of clarity of the Diagram, we RECOMMEND that the modeler choose a consistent location on the boundary. For example, if the Diagram orientation is horizontal, then the Intermediate Events can be attached to the bottom of the Activity and the Sequence Flows directed down, then to the right. If the Diagram orientation is vertical, then the Intermediate Events can be attached to the left or right side of the Activity and the Sequence Flows directed to the left or right, then down.
For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence Flows leaving the Event are followed as usual. For catch Message Intermediate Events, the Message correlation behavior is the same as for Receive Tasks (see sub clause 13.3.3).
For boundary Events, handling first consists of consuming the Event occurrence. If the cancelActivity attribute is set, the Activity the Event is attached to is then cancelled (in case of a multi-instance, all its instances are cancelled); if the attribute is not set, the Activity continues execution (only possible for Message, Signal, Timer, and Conditional Events, not for Error Events). Execution then follows the Sequence Flow connected to the boundary Event. For boundary Message Intermediate Events, the Message correlation behavior is the same as for Receive Tasks (see sub clause 13.3.3).
Intermediate Event Triggers
There are twelve types of Intermediate Events in BPMN: None, Message, Timer, Escalation, Error, Cancel, Compensation, Conditional, Link, Signal, Multiple, and Parallel Multiple. Each type of Intermediate Event will have a different icon placed in the center of the Intermediate Event shape to distinguish one from another.
There are two ways that Intermediate Events are used in BPMN:
- An Intermediate Event that is placed within the normal flow of a Process can be used for one of two purposes. The Event can respond to (“catch”) the Event trigger or the Event can be used to set off (“throw”) the Event trigger.
- An Intermediate Event that is attached to the boundary of an Activity can only be used to “catch” the Event trigger.
Intermediate Events in Normal Flow
When a token arrives at an Intermediate Event that is placed within the normal flow of a Process, one of two things will happen.
- If the Event is used to “throw” the Event trigger, then trigger of the Event will immediately occur (e.g., the Message will be sent) and the token will move down the outgoing Sequence Flow.
- If the Event is used to “catch” the Event trigger, then the token will remain at the Event until the trigger occurs (e.g., the Message is received). Then the token will move down the outgoing Sequence Flow.
Ten of the twelve Intermediate Events can be used in normal flow.
Intermediate Events Attached to an Activity Boundary
For an Event that interrupts the Activity to which it is attached, the boundary of the Event is solid. Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to true.
For an Event that does not interrupt the Activity to which it is attached, the boundary of the Event is dashed. Note that if using this notation, the attribute cancelActivity of the Activity to which the Event is attached is implicitly set to false. If the Activity is not canceled, multiple instances of a handler can run concurrently.
Activity Boundary Connections
An Intermediate Event can be attached to the boundary of an Activity under the following conditions:
- (One or more) Intermediate Events MAY be attached directly to the boundary of an Activity.
- To be attached to the boundary of an Activity, an Intermediate Event MUST be one of the following triggers (EventDefinition): Message, Timer, Error, Escalation, Cancel, Compensation, Conditional, Signal, Multiple, and Parallel Multiple.
- An Intermediate Event with a Cancel trigger MAY be attached to a Sub-Process boundary only if the Transaction attribute of the Sub-Process is set to true.
Handling Events within normal Sequence Flow (Intermediate Events)
For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flows leaving the Event are followed as usual.
Handling Events attached to an Activity (Intermediate boundary Events and Event Sub-Processes)
For boundary Events, handling consists of consuming the Event occurrence and either canceling the Activity the Event is attached to, followed by normal Sequence Flows leaving that Activity, or by running an Event Handler without canceling the Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).
An interrupting boundary Event is defined by a true value of its cancelActivity attribute. Whenever the Event occurs, the associated Activity is terminated. A downstream token is then generated, which activates the next element of the Process (connected to the Event by an unconditional Sequence Flow called an exception flow). Typically it joins the main control flow again, see page 460.
For non-interrupting boundary Events, the cancelActivity attribute is set to false. Whenever the Event occurs, the associated Activity continues to be active. As a token is generated for the Sequence Flow from the boundary Event in parallel to the continuing execution of the Activity, care MUST be taken when this flow is merged into the main flow of the Process – typically it should be ended with its own End Event (see page 459.)
The following example (see Figure 10.101) shows the same fragment of that Process, using boundary Event handlers rather than inline Event Sub-Processes. Note that in this example, the handlers do not have access to the context of the “Booking” Sub-Process, as they run outside of it. Therefore, the actually compensation logic is shown as a black box.
Note that there is a distinction between interrupting and non-interrupting Events and the handling of these Events, which is described in the sub clauses below. For an interrupting Event (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple), only one Event Sub-Process (or boundary Event) for the same Event Declaration MUST be modeled. This excludes any further non-interrupting handlers for that Event Declaration.
The reason for this restriction lies in the nature of interrupting Event Sub-Processes and boundary Events. They interrupt normal execution of the parent Activity and after their completion, the parent Activity is immediately terminated. This implies that only one such handler can be executed at a time. However, this does not restrict the modeler in specifying several interrupting handlers, if each handler refers to a different Event Declaration.
For non-interrupting Events (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple), an unlimited number of Event Sub-Processes for the same Event Declaration can be modeled and executed in parallel. At runtime, they will be invoked in a non-deterministic order. The same restrictions apply for boundary Events. During execution of a non-interrupting Event Sub-Process, execution of the parent Activity continues as normal.
If for a given Sub-Process, both an inline Event Sub-Process and a boundary Event handler are modeled that Process the same EventDefinition, the following semantics apply:
- If the inline Event Sub-Process “re-throws” the Event after completion, the boundary Event is triggered.
- If the inline Event Sub-Process completes without “re-throwing” the Event, the Activity is considered to have completed and normal Sequence Flow resumes. In other terms, the Event Sub-Process “absorbs” the Event.
Interrupting Event Handlers (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)
Interrupting Event Handlers are those that have the cancelActivity attribute is set to true. Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is interrupted. If an inline error handler is specified (in case of a Sub-Process), it is run within the context of that Sub-Process. If a boundary Error Event is present, Sequence Flows from that boundary Event are then followed. The parent Activity is canceled after either the error handler completes or Sequence Flow from the boundary Event is followed.
In the example above, the “Booking” Sub-Process has an Error handler that defines what should happen in case a “Booking” Error occurs within the Sub-Process, namely, the already performed bookings are canceled using compensation. The Error handler is then continued outside the Sub-Process through a boundary Error Event.
Non-interrupting Event Handlers (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple)
Non-Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.
For Event Sub-Processes, whenever the Event occurs it is consumed and the associated Event Sub-Process is performed. If there are several Events that happen in parallel, then they are handled concurrently, i.e., several Event Sub-Process instances are created concurrently. The non-interrupting Start Event indicates that the Event Sub-Process instance runs concurrently to the Sub-Process proper.
For boundary Events, whenever the Event occurs the handler runs concurrently to the Activity. If an Event Sub-Process is also specified for that Event (in case of a Sub-Process), it is run within the context of that Sub-Process. Then, Sequence Flows from the boundary Event are followed. As a token is generated for the Sequence Flow from the boundary Event in parallel to the continuing execution of the Activity, care MUST be taken when this flow is merged into the main flow of the Process – typically it should be ended with its own End Event.
In the example above, an Event Handler allows to update the credit card information during the “Booking” Sub-Process. It is triggered by a credit card information Message: such a Message can be received whenever the control flow is within the main body of the Sub-Process. Once such a Message is received, the Activities within the corresponding Event Handler run concurrently with the Activities within the body of the Sub-Process.
See “Intermediate Events” on page 440 for the exact semantics of boundary Intermediate Events and “Event Sub-Processes” on page 440 for the operational semantics of non-interrupting Event Sub-Processes.
Sequence Flow Connections
If the Intermediate Event is attached to the boundary of an Activity:
- The Intermediate Event MUST NOT be a target for a Sequence Flow; it cannot have an incoming Sequence Flows.
- The Intermediate Event MUST be a source for a Sequence Flow. Multiple Sequence Flows MAY originate from an Intermediate Event. For each Sequence Flow that has the Intermediate Event as a source, a new parallel path SHALL be generated.
- An exception to this: an Intermediate Event with a Compensation trigger MUST NOT have an outgoing Sequence Flow (it MAY have an outgoing Association).
If the Intermediate Event is used within normal flow:
The Intermediate Events with the following triggers (EventDefinition) MAY be used in normal flow: None, Message, Timer, Escalation, Compensation, Conditional, Link, Signal, Multiple, and ParallelMultiple. Thus, the following MUST NOT: Cancel and Error.
- Intermediate Events MUST be a target of a Sequence Flow. An Intermediate Event MAY have multiple incoming Sequence Flows. If the Event has multiple incoming Sequence Flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the Paths, the Event will be enabled (to catch or throw). It will not wait for the arrival of tokens from the other paths. If another token arrives from the same path or another path, then a separate instance of the Event will be created. If the flow needs to be controlled, then the flow should converge with a Gateway that precedes the Event.
- An Intermediate Event MUST be a source for a Sequence Flow. Multiple Sequence Flows MAY originate from an Intermediate Event. For each Sequence Flow that has the Intermediate Event as a source, a new parallel path SHALL be generated.
- An exception to this is Link Intermediate Event: a throwing Link Intermediate Event MUST NOT have an outgoing Sequence Flow. And a catching Link Intermediate Event MUST NOT have an incoming Sequence Flow.
Message Flow Connections
NOTE: All Message Flows MUST connect two separate Pools. They MAY connect to the Pool boundary or to Flow Objects within the Pool boundary. They MUST NOT connect two objects within the same Pool.
- A Message Intermediate Event MAY be the target for a Message Flow; it can have one incoming Message Flow.
- A Message Intermediate Event MAY be a source for a Message Flow; it can have one outgoing Message Flow.
- A Message Intermediate Event MAY have an incoming Message Flow or an outgoing Message Flow, but not both.
Compare this with start events and receive and send tasks.
As the name implies, the End Event indicates where a Process will end. In terms of Sequence Flows, the End Event ends the flow of the Process, and thus, will not have any outgoing Sequence Flows—no Sequence Flow can connect from an End Event.
The End Event shares the same basic shape of the Start Event and Intermediate Event, a circle with an open center so that markers can be placed within the circle to indicate variations of the Event.
An End Event is a circle that MUST be drawn with a single thick line.
To continue discussing how flow proceeds throughout the Process, an End Event consumes a token that had been generated from a Start Event within the same level of Process. If parallel Sequence Flows targets the End Event, then the tokens will be consumed as they arrive. All the tokens that were generated within the Process MUST be consumed by an End Event before the Process has been completed.
In other circumstances, if the Process is a Sub-Process, it can be stopped prior to normal completion through interrupting Intermediate Events. In this situation the tokens will be consumed by an Intermediate Event attached to the boundary of the Sub-Process.
For Processes without an End Event, a token entering a path-ending Flow Object will be consumed when the processing performed by the object is completed (i.e., when the path has completed), as if the token had then gone on to reach an End Event. When all tokens for a given instance of the Process are consumed, then the Process will reach a state of being completed.
Semantics of the End Event include:
There MAY be multiple End Events within a single level of a Process. (A Process MAY have more than one Process level (i.e., it can include Expanded Sub-Processes or a Call Activity that call other Processes). The use of Start and End Events is independent for each level of the Diagram.)
An End Event is OPTIONAL: a given Process level—a Process or an expanded Sub-Process—MAY (is NOT REQUIRED to) have this shape:
- If an End Event is not used, then the implicit End Event for the Process SHALL NOT have a Result.
- If there is a Start Event, then there MUST be at least one End Event.
- If the End Event is not used, then all Flow Objects that do not have any outgoing Sequence Flow (i.e., are not a source of a Sequence Flow) mark the end of a path in the Process. However, the Process MUST NOT end until all parallel paths have completed.
End Event Results
There are nine types of End Events in BPMN: None, Message, Escalation, Error, Cancel, Compensation, Signal, Terminate, and Multiple. These types define the consequence of reaching an End Event. This will be referred to as the End Event Result.
Handling End Events
For a Terminate End Event, all remaining active Activities within the Process are terminated.
A Cancel End Event is only allowed in the context of a Transaction Sub-Process and, as such, cancels the Sub-Process and aborts an associated Transaction of the Sub-Process.
For all other End Events, the behavior associated with the EventDefinition is performed. When there are no further active Activities, then the Sub-Process or Process instance is completed. See page 443 for exact semantics.
Process level end events
For a “terminate” End Event, the Process is abnormally terminated—no other ongoing Process instances are affected.
For all other End Events, the behavior associated with the Event type is performed, e.g., the associated Message is sent for a Message End Event, the associated signal is sent for a Signal End Event, and so on. The Process instance is then completed, if and only if the following two conditions hold:
- All start nodes of the Process have been visited. More precisely, all Start Events have been triggered, and for all starting Event-Based Gateways, one of the associated Events has been triggered.
- There is no token remaining within the Process instance.
Sub-process level end events
For a “terminate” End Event, the Sub-Process is abnormally terminated. In case of a multi-instance Sub-Process, only the affected instance is terminated—no other ongoing Sub-Process instances or higher-level Sub-Process or Process instances are affected.
For a “cancel” End Event, the Sub-Process is abnormally terminated and the associated transaction is aborted. Control leaves the Sub-Process through a cancel intermediate boundary Event.
For all other End Events, the behavior associated with the Event type is performed, e.g., the associated Message is sent for a Message End Event, the associated signal is sent for a signal End Event, and so on. The Sub-Process instance is then completed, if and only if the following two conditions hold:
- All start nodes of the Sub-Process have been visited. More precisely, all Start Events have been triggered, and for all starting Event-Based Gateways, one of the associated Events has been triggered.
- There is no token remaining within the Sub-Process instance.
Sequence Flow Connections
An End Event MUST be a target for a Sequence Flow.
An End Event MAY have multiple incoming Sequence Flows.
The Flow MAY come from either alternative or parallel paths. For modeling convenience, each path MAY connect to a separate End Event object. The End Event is used as a Sink for all tokens that arrive at the Event. All tokens that are generated at the Start Event for that Process MUST eventually arrive at an End Event. The Process will be in a running state until all tokens are consumed.
An End Event MUST NOT be a source for Sequence Flows; that is, there MUST NOT be outgoing Sequence Flows. An exception to this is when an End Event is used in an Expanded Sub-Process and is attached to the boundary of that Sub-Process. In this case, a Sequence Flow from the higher-level Process MAY connect from that End Event in lieu of connecting from the actual boundary of the Sub-Process.
Message Flow Connections
NOTE: All Message Flows MUST connect two separate Pools. They MAY connect to the Pool boundary or to Flow Objects within the Pool boundary. They MUST NOT connect two objects within the same Pool.
An End Event MUST NOT be the target of a Message Flow; it can have no incoming Message Flows.
An End Event MAY be the source of a Message Flow; it can have zero (0) or more outgoing Message Flows. Each Message Flow leaving the End Event will have a Message sent when the Event is triggered.
- The Result attribute of the End Event MUST be set to Message or Multiple if there are any outgoing Message Flows.
- The Result attribute of the End Event MUST be set to Multiple if there is more than one outgoing Message Flows.
An Event is something that “happens” during the course of a Process (see page 235) or a Choreography (see page 339). These Events affect the flow of the model and usually have a cause (trigger) or an impact (result). Events are circles with open centers to allow internal markers to differentiate different triggers or results. There are three types of Events, based on when they affect the flow: Start, Intermediate, and End.
An Event is something that “happens” during the course of a Process (see page 237) or a Choreography (see page 335). These Events affect the flow of the model and usually have a cause (Trigger) or an impact (Result). Events are circles with open centers to allow internal markers to differentiate different Triggers or Results. There are three types of Events, based on when they affect the flow: Start, Intermediate, and End.
Start. As the name implies, the Start Event indicates where a particular Process (see page 235) or Choreography (see page 339) will start.
Intermediate- Intermediate Events occur between a Start Event and an End Event. They will affect the flow of the Process (see page 237) or Choreography (see page 340), but will not start or (directly) terminate the Process.
End. As the name implies, the End Event indicates where a Process (see page 245) or Choreography (see page 343) will end.
An Event is something that happens during the course of a Process. These Events affect the flow of the Process and usually have a cause or an impact. The term event is general enough to cover many things in a Process. The start of an Activity, the end of an Activity, the change of state of a document, a Message that arrives, etc., all could be considered Events. However, BPMN has restricted the use of Events to include only those types of Events that will affect the sequence or timing of Activities of a Process.
The different positions of the Events (Start, End, and Intermediate) utilize a subset of the available types of Event Definitions.
BPMN provides advanced constructs for dealing with Events that occur during the execution of a Process (i.e., the “catching” of an Event). Furthermore, BPMN supports the explicit creation of an Event in the Process (i.e., the “throwing” of an Event). Both catching and throwing of an Event as well as the resulting Process behavior is referred to as Event handling. There are three types of Event handlers: those that start a Process, those that are part of the normal Sequence Flow, and those that are attached to Activities, either via boundary Events or via separate inline handlers in case of an Event Sub-Process.
A brief explanation of Type, Position and Mode. Examples simples. Don't use "event definition".
For Intermediate Events, the handling consists of waiting for the Event to occur. Waiting starts when the Intermediate Event is reached. Once the Event occurs, it is consumed. Sequence flows leaving the Event are followed as usual.
For boundary Events, handling consists of consuming the Event occurrence and either canceling the Activity the Event is attached to, followed by normal Sequence Flows leaving that Activity, or by running an Event Handler without canceling the Activity (only for Message, Signal, Timer and Conditional Events, not for Error Events).
An interrupting boundary Event is defined by a true value of its cancelActivity attribute. Whenever the Event occurs, the associated Activity is terminated. A downstream token is then generated, which activates the next element of the Process (connected to the Event by an unconditional Sequence Flow called an exception flow).
For non-interrupting boundary Events, the cancelActivity attribute is set to false. Whenever the Event occurs, the associated Activity continues to be active. As a token is generated for the Sequence Flow from the boundary Event in parallel to the continuing execution of the Activity, care MUST be taken when this flow is merged into the main flow of the Process – typically it should be ended with its own End Event.
The following example (see Figure 10.101) shows the same fragment of that Process, using boundary Event handlers rather than inline Event Sub-Processes. Note that in this example, the handlers do not have access to the context of the “Booking” Sub-Process, as they run outside of it. Therefore, the actually compensation logic is shown as a black box.
Note that there is a distinction between interrupting and non-interrupting Events and the handling of these Events, which is described in the sub clauses below. For an interrupting Event (Error, Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple), only one Event Sub-Process (or boundary Event) for the same Event Declaration MUST be modeled. This excludes any further non-interrupting handlers for that Event Declaration.
The reason for this restriction lies in the nature of interrupting Event Sub-Processes and boundary Events. They interrupt normal execution of the parent Activity and after their completion, the parent Activity is immediately terminated. This implies that only one such handler can be executed at a time. However, this does not restrict the modeler in specifying several interrupting handlers, if each handler refers to a different Event Declaration.
For non-interrupting Events (Escalation, Message, Signal, Timer, Conditional, Multiple, and Parallel Multiple), an unlimited number of Event Sub-Processes for the same Event Declaration can be modeled and executed in parallel. At runtime, they will be invoked in a non-deterministic order. The same restrictions apply for boundary Events. During execution of a non-interrupting Event Sub-Process, execution of the parent Activity continues as normal.
If for a given Sub-Process, both an inline Event Sub-Process and a boundary Event handler are modeled that Process the same EventDefinition, th following semantics apply:
- If the inline Event Sub-Process “re-throws” the Event after completion, the boundary Event is triggered.
- If the inline Event Sub-Process completes without “re-throwing” the Event, the Activity is considered to have completed and normal Sequence Flow resumes. In other terms, the Event Sub-Process “absorbs” the Event.
Interrupting Event Handlers are those that have the cancelActivity attribute is set to true. Whenever the Event occurs, regardless of whether the Event is handled inline or on the boundary, the associated Activity is interrupted. If an inline error handler is specified (in case of a Sub-Process), it is run within the context of that Sub-Process. If a boundary Error Event is present, Sequence Flows from that boundary Event are then followed. The parent Activity is canceled after either the error handler completes or Sequence Flow from the boundary Event is followed.
In the example above, the “Booking” Sub-Process has an Error handler that defines what should happen in case a “Booking” Error occurs within the Sub-Process, namely, the already performed bookings are canceled using compensation. The Error handler is then continued outside the Sub-Process through a boundary Error Event.
Non-Interrupting Event Handlers are those that have the cancelActivity attribute is set to false.
For Event Sub-Processes, whenever the Event occurs it is consumed and the associated Event Sub-Process is performed. If there are several Events that happen in parallel, then they are handled concurrently, i.e., several Event Sub-Process instances are created concurrently. The non-interrupting Start Event indicates that the Event Sub-Process instance runs concurrently to the Sub-Process proper.
For boundary Events, whenever the Event occurs the handler runs concurrently to the Activity. If an Event Sub-Process is also specified for that Event (in case of a Sub-Process), it is run within the context of that Sub-Process. Then, Sequence Flows from the boundary Event are followed. As a token is generated for the Sequence Flow from the boundary Event in parallel to the continuing execution of the Activity, care MUST be taken when this flow is merged into the main flow of the Process – typically it should be ended with its own End Event.
In the example above, an Event Handler allows to update the credit card information during the “Booking” Sub-Process. It is triggered by a credit card information Message: such a Message can be received whenever the control flow is within the main body of the Sub-Process. Once such a Message is received, the Activities within the corresponding Event Handler run concurrently with the Activities within the body of the Sub-Process.
See “Intermediate Events” on page 440 for the exact semantics of boundary Intermediate Events and “Event Sub-Processes” on page 440 for the operational semantics of non-interrupting Event Sub-Processes.
