Sub-Proceso Evento

Texto

Resumen. Resumen. Resumen. Resumen. Resumen. Resumen.

Un Subproceso Evento no puede ser iterativo.

Tipo	Interruptor	No Interruptor	Descripción
None			Descripción
Message			Descripción
Timer			Descripción
Error			Captura un Error específico. Es decir, el error debe estar especificado. Siempre interrumpe el Proceso que contiene el Subproceso Evento.
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

Texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. Texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto.

Posición del Evento		Modo	Notación	Descripción
Evento Inicial	Sub-Proceso Evento	Captura con Interrupción		five
		Captura sin Interrupción		five

Texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto. Texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto texto.

Evento Mensaje Inicial Sub-Proceso Evento

Un Sub-Proceso Evento es usado para manejar una excepción dentro de un Proceso (en el Tope o Sub-Proceso). No es parte del Flujo del Proceso que lo contiene: no llegan ni salen de él Flujos de Secuencia.

Un Sub-Proceso Evento comienza con alguno de los siguientes Eventos Iniciales: Mensaje, Error, Escalar, Compensar, Condición, Señal, y Múltiple.

Se dibuja con un rectángulo de esquinas redondeadas como las demás Actividades, pero con línea punteada.

Sub-Proceso Evento en un Proceso en el Tope.

Cuando el Sub-Proceso Evento está colapsado se coloca el tipo de Evento que lo gatilla en la esquina superior izquierda.

Sub-Proceso Evento colapsado en un Proceso en el Tope.

Si la Piscina del Participante que envía el Mensaje está dibujada en el diagrama, un Flujo de Mensaje conecta el Evento Inicial del Sub-Proceso Evento con el Participante emisor.

Flujo de Mensaje conecta el Evento Inicial del Sub-Proceso Evento expandido con el Participante emisor.

Si el el Sub-Proceso Evento está colapsado el Flujo de Mensaje conecta con el Sub-Proceso Evento.

Flujo de Mensaje conecta el Sub-Proceso Evento colapsado con el Participante emisor.

El Sub-Proceso Evento puede estar dentro de un Sub-Proceso. Al igual que cuando está dentro de un Proceso en el Tope, puede estar espandido o comprimido, y estar conectado al Participante que envía el Mensaje.

Sub-Proceso Evento colapsado en un Sub-Proceso.

Al gatillar un Sub-Proceso Evento hay dos escenarios posibles:

• Evento Interruptor: El Proceso (Proceso en el Tope o Sub-Proceso) que lo contiene es interrumpido.
• Evento No Interruptor: El Proceso (Proceso en el Tope o Sub-Proceso) que lo contiene no es interrumpido, continúa trabajando.

Referencias: Sub-Proceso Evento.

Evento Mensaje Inicial Sub-Proceso Evento Interruptor

Un Evento Inicial Mensaje Interruptor en un Sub-Proceso Evento captura un Mensaje, comienza una nueva instancia del Sub-Proceso Evento e interrumpe el Proceso que lo contiene. Se representa con un círculo de línea fina continua con un sobre de carta.

El Evento Inicial Mensaje Interruptor marca el comienzo de la ejecución de una nueva instancia del Sub-Proceso Evento.

Sub-Proceso Evento Mensaje Interruptor en un Proceso en el Tope.

Si no llega un Mensaje dirigido al Sub-Proceso Evento Interruptor el Proceso que lo contiene se ejecuta de manera normal.

Cuando llega un Mensaje el Proceso que lo contiene es interrumpido, se ejecuta el Sub-Proceso Evento, y el Proceso termina.

Es decir, el Sub-Proceso Evento Mensaje Interruptor no se gatilla o se gatilla sólo una vez.

¿Cómo funciona el Sub-Proceso Evento Mensaje Interruptor en un Proceso en el Tope cuando no llega un Mensaje?

1. Comienza una nueva instancia del Proceso en el Tope.
2. El Flujo del Proceso en el Tope fluye a través de sus Activides, Compuertas y Eventos.
3. Durante la ejecución del Proceso en el Tope no llega ningún Mensaje dirigido al Sub-Proceso Evento; por lo tanto, el Sub-Proceso Evento no se gatilla.
4. El Flujo del Proceso en el Tope llega al Evento Final y termina la ejecución normal de la instancia del Proceso.

Sub-Proceso Evento Mensaje Interruptor no gatillado.

¿Cómo funciona el Sub-Proceso Evento Mensaje Interruptor en un Proceso en el Tope cuando llega un Mensaje?

1. Comienza una nueva instancia del Proceso en el Tope.
2. El Flujo del Proceso en el Tope fluye a través de sus Activides, Compuertas y Eventos.
3. Llega un Mensaje dirigido al Sub-Proceso Evento.
4. La instancia del Proceso en el Tope se interrumpe. Es decir, todas sus Actividades en ejecución y Eventos en espera abortan, y aguarda el término de la ejecución de la instancia del Sub-Proceso Evento para finalizar.
5. La instancia del Sub-Proceso Evento comienza. El Flujo del Sub-Proceso Evento fluye a través de sus Activides, Compuertas y Eventos.
6. La ejecución de la instancia del Sub-Proceso Evento termina al llegar al Evento Final.
7. El control vuelve al Proceso en el Tope.
8. La instancia del Proceso en el Tope termina.

Sub-Proceso Evento Mensaje Interruptor gatillado.

Si el Sub-Proceso Evento Mensaje Interruptor está dentro de un Sub-Proceso y no es gatillado, el Sub-Proceso se ejecuta y termina normalmente. Por otro lado, si llega un Mensaje el Sub-Proceso aborta, y aguarda el término del Sub-Proceso Evento para devolver el control al Proceso que lo contiene.

¿Cómo funciona el Sub-Proceso Evento Mensaje Interruptor en un Sub-Proceso cuando llega un Mensaje?

1. Comienza una nueva instancia del Proceso en el Tope.
2. El Flujo del Proceso en el Tope fluye a través de sus Activides, Compuertas y Eventos.
3. El Flujo llega al Sub-Proceso y comienza una nueva instancia del Sub-Proceso.
4. El Flujo del Sub-Proceso fluye a través de sus Activides, Compuertas y Eventos.
5. Llega un Mensaje dirigido al Sub-Proceso Evento.
6. La instancia del Sub-Proceso se interrumpe. Es decir, todas sus Actividades en ejecución y Eventos en espera abortan, y aguarda el término de la ejecución de la instancia del Sub-Proceso Evento para finalizar.
7. La instancia del Sub-Proceso Evento comienza. El Flujo del Sub-Proceso Evento fluye a través de sus Activides, Compuertas y Eventos.
8. La ejecución de la instancia del Sub-Proceso Evento termina al llegar al Evento Final.
9. El control vuelve al Sub-Proceso.
10. La instancia del Sub-Proceso termina.
11. El control vuelve al Proceso en el Tope y continúa a través de sus Activides, Compuertas y Eventos
12. La instancia del Proceso en el Tope termina.

Sub-Proceso Evento Mensaje Interruptor en un Sub-Proceso.

Evento Mensaje Inicial Sub-Proceso Evento No Interruptor

Un Evento Inicial Mensaje No Interruptor en un Sub-Proceso Evento captura un Mensaje, comienza una nueva instancia del Sub-Proceso Evento, el Proceso que lo contiene continúa su ejecución. Se representa con un círculo de línea fina segmentada con un sobre de carta.

El Evento Inicial Mensaje no Interruptor marca el comienzo de la ejecución de una nueva instancia del Sub-Proceso Evento.

Sub-Proceso Evento Mensaje no Interruptor en un Proceso en el Tope.

Ya sea que lleguen o no Mensajes dirigidos al Sub-Proceso Evento no Interruptor, el Proceso que lo contiene se ejecuta de manera normal.

Es decir, el Sub-Proceso Evento Mensaje no Interruptor se puede gatillar varias veces, incluso en paralelo.

Para poder terminar, el Proceso padre del Sub-Proceso Evento no Interruptor debe esperar que todas las instancias activas del Sub-Proceso Evento hayan también finalizado.

¿Cómo funciona el Sub-Proceso Evento Mensaje no Interruptor en un Proceso en el Tope cuando llega un Mensaje?

1. Comienza una nueva instancia del Proceso en el Tope.
2. El Flujo del Proceso en el Tope fluye a través de sus Activides, Compuertas y Eventos.
3. Cada vez que llega un Mensaje dirigido al Sub-Proceso Evento, éste se gatilla y ejecuta.
4. La instancia del Proceso en el Tope continúa en paralelo con las instancias del Sub-Proceso Evento.
5. El Proceso en el Tope llega al Evento Final.
6. Si no hay instancias activas del Sub-Proceso Evento la instancia del Proceso en el Tope termina. En caso contrario, espera a que las instancias activas del Sub-Proceso Evento finalicen.

Sub-Proceso Evento Mensaje no Interruptor en un Proceso en el Tope.

¿Cómo funciona el Sub-Proceso Evento Mensaje no Interruptor en un Sub-Proceso cuando llega un Mensaje?

1. Comienza una nueva instancia del Proceso en el Tope.
2. El Flujo del Proceso en el Tope fluye a través de sus Activides, Compuertas y Eventos.
3. El Flujo llega al Sub-Proceso y comienza una nueva instancia del Sub-Proceso.
4. El Flujo del Sub-Proceso fluye a través de sus Activides, Compuertas y Eventos.
5. Cada vez que llega un Mensaje dirigido al Sub-Proceso Evento, éste se gatilla y ejecuta.
6. La instancia del Sub-Proceso padre continúa en paralelo con las instancias del Sub-Proceso Evento.
7. El Sub-Proceso padre llega al Evento Final.
8. Si no hay instancias activas del Sub-Proceso Evento la instancia del Sub-Proceso padre termina. En caso contrario, espera a que las instancias activas del Sub-Proceso Evento finalicen.
9. El control vuelve al Proceso en el Tope.
10. La instancia del Proceso en el Tope termina.

Sub-Proceso Evento Mensaje no Interruptor en un Sub-Proceso.

Otros

Múltiple Paralelo: Existen múltiples formas de desencadenar el Subproceso de Evento. Todos ellos son REQUERIDOS para iniciar efectivamente el Subproceso de Evento.

There are multiple ways of triggering the Event Sub-Process. All of them are REQUIRED to actually start the Event Sub-Process.

====================================

Hay cuatro variantes de Evento Compensar:

1. Evento Inicial, sólo puede ser usado en un Subproceso Evento. Captura el requerimiento de Compensación.
2. Evento Intermedio en el Borde, sólo en Modo Interruptor. Captura el requerimiento de Compensación. Cuando se desencadena el Evento, se realiza la Manejador de Compensación asociado.
3. Evento Intermedio en el Flujo, sólo en Modo Lanzamiento. Lanza un requerimiento de Compensación.
4. Evento Final. Lanza un requerimiento de Compensación.

El Manejador de Compensación puede ser:

• Una Actividad de Compensacion unida (por una Asociación) a un Evento Intermedio en el Borde de la Actividad a Compensar.
• Un Subproceso Evento Compensar dentro de la Actividad a Compensar.

Para que una Actividad pueda ser compensada debe haberse completado con éxito y tener un Manejador de Compensación (Evento Compensar en el Borde, o contener un Subproceso Evento Compensar).

Un Evento (Intermedio o Final) lanza el requerimiento de compensación. Para que éste tenga efecto, la o las Actividades a compensar deben ser "visibles" para el Evento Intermedio o Final. ESto significa que una de las siguientes condiciones debe cumplirse:

• El Evento y la(s) Actividad(es) a Compensar están en el mismo Proceso Principal o en el mismo Subproceso.
• El Evento está dentro de un Subproceso Evento que está contenido en el Proceso Principal o Subproceso que contiene la(s) Actividad(es).

Para una Actividad Multi Instancia, cada instancia tiene su propia instancia de Subproceso Evento Compensar, que tiene acceso a los datos de su respectiva instancia de la Actividad vigentes al momento de su finalización. Al gatillar la Compensación de la Actividad Multi Instancia se gatillan las Compensaciones de todas sus instancias. Es decir, cada instancia es compensada de manera independiente.

El Evento Inicial Compensar utiliza un marcador de doble triángulo. Este Evento no interrumpe el Proceso ya que el Proceso debe completarse antes de que se pueda activar este Evento, por lo que el límite del Evento es sólido.

(En realidad, el concepto de interrumpir o no interrumpir no tiene sentido para un Evento de Compensación. Los eventos de no interrupción se introdujeron en BPMN 2.0. Antes, todos los eventos intermedios tenían un límite sólido, por lo que, por compatibilidad, Compensación mantiene esta noción aunque, por naturaleza, es más cercana). a un evento no interrumpido.)

Multiple instances typically exist for Loop or Multi-Instance Sub-Processes. Each of these has its own instance of its Compensation Event Sub-Process, which has access to the specific snapshot data that was current at the time of completion of that particular instance. Triggering compensation for the Multi-Instance Sub-Process individually triggers compensation for all instances within the current scope. If compensation is specified via a boundary compensation handler, this boundary compensation handler also is invoked once for each instance of the Multi-Instance Sub-Process in the current scope.

The Event uses a double triangle marker. This Event does not interrupt the Process since the Process has to be completed before this Event can be triggered, so the boundary of the Event is solid.

(Actually the concept of interrupting or not interrupting does not make sense to a Compensation Event. Non-interrupting event were introduced in BPMN 2.0. Before all intermediate events had solid boundary so for compatibility Compensation mantains this noation even though it is by nature more close to a non-interrupting event.)

====================================

La Compensación se activa mediante un Evento Compensar de Lanzamiento, Intermedio o Final. El Evento identifica la Actividad que necesita ser compensada. Si no se especifica ninguna Actividad en un contexto "global", se compensan todas las Actividades completadas en el Proceso. Si la actividad está clara en el contexto, no es necesario especificarla y el valor predeterminado es la actividad actual. Un escenario típico para eso es un controlador de errores en línea de un subproceso que no puede recuperar el error y, como resultado, desencadenaría una compensación para ese subproceso.

Compensation is triggered using a throw Compensation Event, which can either be an Intermediate or an End Event. The Activity that needs to be compensated is referenced. If the Activity is clear from the context, it doesn’t have to be specified and defaults to the current Activity. A typical scenario for that is an inline error handler of a Sub-Process that cannot recover the error, and as a result would trigger compensation for that Sub-Process. If no Activity is specified in a “global” context, all completed Activities in the Process are compensated.

====================================

El Evento Inicial Escalada sólo se permite en Subprocesos Evento. Puede ser Interruptor y No Interruptor.

Los Subprocesos Evento de Escalada implementan medidas para hacer más expedita una Actividad, en caso de que se satisfaga alguna restricción, como puede ser el cumplimiento de un plazo.

The Escalation Start Event is only allowed for triggering an in-line Event Sub-Process.

Escalation Event Sub-Processes implement measures to expedite the completion of a business Activity, should it not satisfy a constraint specified on its execution (such as a time-based deadline).

====================================

Eventos Inicial para Subproceso Evento

Hay siete (9) Tipos de Eventos que pueden usarse para iniciar un Suproceso Evento: Mensaje, Timer, Escalada, Error, Compensación, Condicional, Señal, Múltiple y Múltiple Paralelo.

Un Subproceso de Evento debe tener un solo Evento de Inicio.

Nótese que los Eventos Iniciales: Escalada y Error sólo pueden iniciar un Subproceso Evento.

Un Subproceso Evento es un Subproceso Embebido especializado que está contenido dentro de un Proceso de cualquier nivel. Es decir, puede estar dentro de un Proceso de Primer Nivel o un Subproceso, excepto dentro de otro Subproceso Evento.

Un Subproceso Evento no forma parte del Flujo del Proceso contenedor. Es decir, no tiene Flujos de Secuencia entrantes o salientes.

Un Subproceso Evento puede o no ocurrir mientras el Proceso contenedor está activo, incluso puede ocurrir varias veces. Los demás Subprocesos utilizan el Flujo del Proceso que los contienen como disparador, es decir, su Evento Incial Vacío de activa cuando llega un Token por un Flujo de Secuencia. En cambo, un Subproceso Evento tiene un Evento Inicial distinto de Vacío. Cada vez que se activa el Evento Inicial mientras el Proceso contenedor está activo, se iniciará el Subproceso Evento.

Un Subproceso Evento debe tener un y solo un Evento de Inicio distinto de Vacío. Puede ser uno de los siguientes tipos: Mensaje, Error, Escalada, Compensación, Condicional, Señal y Múltiple.

Un Subproceso Evento, como cualquier otra Actividad, se representa con un rectángulo redondeado, pero se dibuja con una línea punteada delgada.

Si el Subproceso Evento está colapsado, su Evento Inicial se utilizará como Marcador en su esquina superior izquierda.

Hay dos posibles consecuencias para el Proceso contenedor cuando se activa un Subproceso Evento: 1) el Proceso contenedor puede interrumpirse (para una Actividad Multi-Instancia, esto cancela solo la instancia afectada) y 2) el Proceso contenedor puede continuar su trabajo (no interrumpido). Esto está determinado por el modo (con o sin interrupción) del Evento Inicial que se utiliza.

La figura 10.32 muestra un ejemplo de un Subproceso que incluye tres Subprocesos Evento. El primer Subproceso Evento es gatillado por un Mensaje, no interrumpe el Subproceso contenedor y puede ocurrir varias veces. El segundo Subproceso Evento se usa para Compensación y solo ocurrirá después de que se haya completado el Subproceso contenedor en caso que de Cancelación. El tercer Subproceso Evento maneja los errores que ocurren mientras el Subproceso contenedor está activo y detendrá (interrumpirá) el Subproceso contenedor.

Los Subprocesos Evento no pueden tener Eventos de Borde.

Un Subproceso Evento permite manejar un Evento dentro del contexto del Proceso que lo contiene, y, por lo tanto, tienen acceso a sus datos. Esta es la mayor diferencia con un Evento de Borde, el cuál está fuera del contexo de la Actividad padre, por lo que no tiene acceso a sus datos.

Un Subproceso de Evento puede, opcionalmente, en su Evento Final relanzar el Evento que lo desencadenó. De este modo, el trabajo continúa fuera de los límites del Subproceso contendor. En ese caso el Subproceso Evento se realiza cuando ocurre el Evento; luego, el control pasa al Evento de Borde, posiblemente cancelando el Subproceso.

Dada la naturaleza de los Errores, un Subproceso Evento de tipo Error error siempre interrumpirá el Proceso que lo contiene.

semántica operativa

• Un Subproceso Evento se inicia y, por lo tanto, se habilita y ejecuta como parte del Proceso que lo contiene, es decir, sólo puede iniciarse después de que el Proceso contenedor se esté ejecutando.
• Se puede iniciar más de un Subproceso Evento no interruptor, en diferentes momentos. Puede haber varias instancias de un mismo Subproceso Evento no interruptor.
• Sólo se puede iniciar un Subproceso Evento interruptor, pues el Proceso contenedor es interrumpido y no se pueden iniciar otros Subproceso Evento.
• Un Subproceso Evento se completa cuando todos los Tokens han llegado a un Evento Final, como cualquier otro Subproceso.
• Si un Subproceso que contiene Subprocesos Evento ingresa al estado COMPLETANDO, permanece en ese estado hasta que todos los Subprocesos Evento activos contenidos se hayan completado. Durante este tiempo, no deben iniciarse nuevos Subprocesos Eventos.
• Si un Subproceso Evento interruptor se inicia por un Error, entonces la Actividad que lo contiene entra al estado FALLIDA y permanece en este estado hasta que el Subproceso Evento interruptor alcanza un estado final. Durante este tiempo, no deben iniciarse nuevos Subprocesos Eventos.
• De manera similar, si un Subproceso Evento interruptor no se inicia por un Error (por ejemplo, una Escalada), entonces la Actividad que lo contiene entra al estado TERMINANDO y permanece en este estado hasta que el Subproceso Evento interruptor alcanza un estado final. Durante este tiempo, no deben iniciarse nuevos Subprocesos Eventos.

Manejo de Eventos adjuntos a una Actividad (Eventos Intermedios de Borde y Subprocesos Evento)

Para los Eventos Intermedios de Borde, el manejo consiste en consumir el Evento e interrumpir la Actividad a la que está asociado el Evento y seguir los Flujos de Secuencia que salen del Evento Intermedio de Borde, o ejecutar un Manejador de Evento sin interrumpir la Actividad (solo para Eventos Mensaje, Señal, Timer y Condicional, no para Error).

Cada vez que ocurre un Evento Intermedio de Borde interruptor, la Actividad asociada finaliza. Luego se genera un Token que sale por un Flujo de Secuencia (incondicional, llamado Flujo de Excepción) desde el Evento Intermedio de Borde, que activa el siguiente elemento del Proceso, normalmente un Manejador de la Excepción. Por lo general, el Flujo de Excepción se une nuevamente al Flujo principal.

Cada vez que ocurre un Evento Intermedio de Borde no interruptor, la Actividad asociada continúa activa. Dado que se genera un Token para el Flujo de Secuencia desde el Evento Intermedio de Borde en paralelo a la ejecución Actividad, se debe evitar que este Flujo de Excepción se fusiones con el Flujo principal; por lo general, el Flujo de Excepción tiene su propio final.

Para un Evento interruptor (Error, Escalada, Mensaje, Señal, Timer, Condicional, Múltiple y Múltiple Paralelo), sólo puede modelarse un Subproceso Evento (o Evento Intermedio de Borde) 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 no puede haber Subprocesos Evento (o Eventos Intermedios de Borde) interruptores y no interruptores.

Para Eventos no interruptores (Escalada, Mensaje, Señal, Timer, Condicional, Múltiple y Múltiple Paralelo), se puede modelar y ejecutar en paralelo un número ilimitado de Subprocesos de Evento (o Eventos Intermedios de Borde) para el mismo Evento. En tiempo de ejecución, se invocarán en un orden no determinista.

Si para un Subproceso dado, se modelan tanto un Subproceso Evento como un Evento Intermedio de Borde que procesan el mismo Evento, se aplica la siguiente semántica:

• Si el Subproceso Evento "relanza" el Evento al finalizar, se activa el Evento de Borde.
• Si el Subproceso Evento se completa sin "relanzar" el Evento, se considera que la Actividad se ha completado y se reanuda el Flujo de Secuencia normal. En otros palabras, el Subproceso Evento "absorbe" el Evento.

En el ejemplo anterior, el Subproceso de "Reserva" ("Booking") tiene un Manejador de Errores que define qué debe suceder en caso de que ocurra un Error de "Reserva" dentro del Subproceso, es decir, las reservas ya realizadas son compensadas. Después, el Manejador de Errores continúa fuera del Subproceso a través de un Evento Error de Borde.

En el ejemplo anterior, un Controlador de eventos permite actualizar la información de la tarjeta de crédito durante el Subproceso de "Reserva". Se gatilla por un Mensaje con la información de tarjeta de crédito: dicho Mensaje se puede recibir siempre que el Flujo de control se encuentre dentro del Subproceso. Una vez que se recibe el Mensaje, las actividades dentro del Manejador del Evento se ejecutan al mismo tiempo que las actividades dentro del Subproceso.

Los controladores de eventos de interrupción: Cada vez que ocurre el evento y el Subproceso Evento se ejecuta dentro del contexto de ese subproceso. La actividad principal se cancela después de que se completa el Subproceso Evento.

En el ejemplo anterior, el Subproceso de "Reserva" tiene un controlador de errores que define qué debe suceder en caso de que ocurra un Error de "Reserva" dentro del Subproceso, es decir, las reservas ya realizadas se cancelan mediante compensación. Luego, el controlador de errores continúa fuera del subproceso a través de un evento de error de límite.

Para los Subprocesos de Evento, cada vez que ocurre el Evento, se consume y se realiza el Subproceso de Evento asociado. Si hay varios Eventos que suceden en paralelo, entonces se manejan concurrentemente, es decir, se crean varias instancias de Subprocesos de Evento concurrentemente. El Evento de Inicio sin interrupción indica que la instancia del Subproceso de Evento se ejecuta simultáneamente con el Subproceso propiamente dicho.

En el ejemplo anterior, un Controlador de eventos permite actualizar la información de la tarjeta de crédito durante el Subproceso de "Reserva". Se desencadena por un Mensaje de información de tarjeta de crédito: dicho Mensaje se puede recibir siempre que el flujo de control se encuentre dentro del cuerpo principal del Subproceso. Una vez que se recibe dicho mensaje, las actividades dentro del controlador de eventos correspondiente se ejecutan simultáneamente con las actividades dentro del cuerpo del subproceso.

Temporal

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Especificación BPMN

The Event uses an envelope marker.

• For an interrupting Message Event Sub-Process the boundary of the Event is solid.
• For a non-interrupting Message Event Sub-Process the boundary of the Event is dashed.

The actual Participant from which the Message is received can be identified by connecting the Event to a Participant using a Message Flow within the definitional Collaboration of the Process.

Given the nature of Errors, an Event Sub-Process with an Error trigger will always interrupt its containing Process, so the boundary of the Event is solid.

Start Events for Event Sub-Processes

A Start Event can also initiate an inline Event Sub-Process (see page 174). In that case, the same Event types as for boundary Events are allowed (see Table 10.86), namely: Message, Timer, Escalation, Error, Compensation, Conditional, Signal, Multiple, and Parallel.

An Event Sub-Process MUST have a single Start Event.

Note that Escalation and Error Start Events are only allowed for triggering an in-line Event Sub-Process.

An Event Sub-Process is a specialized (Embedded) Sub-Process that is used within a Process (or Sub-Process). 

Event Sub-Processes could also be added to a top-level Process.

An Event Sub-Process is not part of the normal flow of its parent Process (or Sub-Process)—there are no incoming or outgoing Sequence Flows.

An Event Sub-Process MUST NOT have any incoming or outgoing Sequence Flows.

An Event Sub-Process MAY or MAY NOT occur while the parent Process is active, but it is possible that it will occur many times. Unlike a standard Sub-Process, which uses the flow of the parent Process as a trigger, an Event Sub-Process has a Start Event with a trigger. Each time the Start Event is triggered while the parent Process is active, then the Event Sub-Process will start.

The Start Event of an Event Sub-Process MUST have a defined trigger. The Start Event trigger (EventDefinition) MUST be from the following types: Message, Error, Escalation, Compensation, Conditional, Signal, and Multiple (see page 259 for more details).

An Event Sub-Process MUST have one and only one Start Event.

An Event Sub-Process object shares the same basic shape as the Sub-Process object, which is a rounded rectangle.

An Event Sub-Process is a rounded corner rectangle that MUST be drawn with a single thin dotted line (see Figure 10.30 and Figure 10.31).

If the Event Sub-Process is collapsed, then its Start Event will be used as a marker in the upper left corner of the shape (see Figure 10.30).

There are two possible consequences to the parent Process when an Event Sub-Process is triggered: 1) the parent Process can be interrupted, and 2) the parent Process can continue its work (not interrupted). This is determined by the type of Start Event that is used. See page 241 for the list of interrupting and non-interrupting Event Sub-Process Start Events.

Figure 10.32 provides an example of a Sub-Process that includes three Event Sub-Processes. The first Event Sub-Process is triggered by a Message, does not interrupt the Sub-Process, and can occur multiple times. The second Event Sub-Process is used for compensation and will only occur after the Sub-Process has completed. The third Event Sub-Process handles errors that occur while the Sub-Process is active and will stop (interrupt) the Sub-Process if triggered.

See Table 12.16 p.388 for a full list of Event Sub-Processes.

Event Sub-Processes allow to handle an Event within the context of a given Sub-Processes or Process. An Event Sub-Process always begins with a Start Event, followed by Sequence Flows. Event Sub-Processes are a special kind of Sub-Process: they create a scope and are instantiated like a Sub-Process, but they are not instantiated by normal control flow but only when the associated Start Event is triggered. Event Sub-Processes are self-contained and MUST not be connected to the rest of the Sequence Flows in the Sub-Processes; also they cannot have attached boundary Events. They run in the context of the Sub-Process, and thus have access to its context.

An Event Sub-Process cancels execution of the enclosing Sub-Process, if the isInterrupting attribute of its Start Event is set; for a multi-instance Activity this cancels only the affected instance. If the isInterrupting attribute is not set (not possible for Error Event Sub-Processes), execution of the enclosing Sub-Process continues in parallel to the Event Sub-Process.

An Event Sub-Process can optionally re-trigger the Event through which it was triggered, to cause its continuation outside the boundary of the associated Sub-Process. In that case the Event Sub-Process is performed when the Event occurs; then control passes to the boundary Event, possibly canceling the Sub-Process (including running handlers).

Operational semantics

• An Event Sub-Process becomes initiated, and thus Enabled and Running, through the Activity to which it is attached. The Event Handler MAY only be initiated after the parent Activity is Running.
• More than one non-interrupting Event Handler MAY be initiated and they MAY be initiated at different times. There might be multiple instances of the non-interrupting Event Handler at a time. For Event Sub-Processes triggered by a Message, the Message correlation behavior is the same as for Receive Tasks -- see sub clause 13.3.3.
• Only one interrupting Event Handler MAY be initiated for a given EventDefinition within the context of the parent Activity. Once the interrupting Event Handler is started, the parent Activity is interrupted and no new Event Handlers can be initiated or started.
• An Event Sub-Process completes when all tokens have reached an End Event, like any other Sub-Process. If the parent Activity enters the state Completing, it remains in that state until all contained active Event Sub-Processes have completed. While the parent Activity is in the Completing state, no new Event Sub-Processes can be initiated.
• If an interrupting Event Sub-Process is started by an error, then the parent Activity enters the state Failing and remains in this state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, new Event Handlers MUST NOT be started.
• Similarly, if an interrupting Event Sub-Process is started by a non error (e.g., Escalation), then the parent Activity enters the state Terminating and remains in this state until the interrupting Event Handler reaches a final state. During this time, the running Event Handler can access to the context of the parent Activity. However, new Event Handlers MUST NOT be started.

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.

A Sub-Process is defined as an Event Sub-Process when its triggeredByEvent attribute is set to true.

Table 10.84 – Top-Level Process Start Event Types, p. 241.

solocastellano