La Compensación de una Actividad consiste en deshacer sus acciones, porque sus resultados y posibles efectos secundarios ya no son deseados y deben revertirse.
Si se determina que los resultados de una Actividad ya no son deseados, entonces es necesario revertirlos de alguna manera. Se podrían restaurar los datos a como estaban antes de la ejecución de la Actividad, es decir, como si ésta jamás se hubiese activado.
La otra opción es invocar una Actividad que compense los resultados no deseados, pero no eliminar el hecho de que la Actividad fue ejecutada. Por ejemplo, si se cancela un pedido que ya fue despachado y pagado, entonces hay que contrarrestar los efectos del despacho y el pago, pero también se requiere registrar que ambos se hicieron.
Por definición, solo puede ser compensada una Actividad que ha terminado con éxito. Es decir, que una vez concluida la Actividad, el Proceso continúa por uno o más Flujos de Secuencia normales que salen de ella.
Si se intenta compensar una Actividad que está activa o que no ha concluido con éxito, no sucede nada, ni siquiera se genera un error.
Si una Actividad aún está activa y presenta algún problema, no puede ser compensada, sino que debe ser cancelada. La que a su vez puede resultar en la compensación de partes ya completadas exitosamente de la Actividad cancelada, en el caso de un Subproceso.
Manejador de Compensación
La Compensación la realiza un Manejador de Compensación. Este no es parte de la ejecución del Proceso, no está conectado al Flujo del Proceso, es decir, no llegan ni salen de él Flujos de Secuencia.
El Manejador de Compensación puede ser definido por el modelador (Actividad o un Subproceso Evento) o ser implícito:
Actividad de Compensación
El Manejador consiste en una Actividad que está conectada, por una Asociación, a un Evento Compensar en el Borde de la Actividad que será compensada. Tanto la Actividad compensadora como la Actividad a compensar pueden ser una Tarea o un Subproceso.
El Manejador tiene un marcador de rebobinado en su parte inferior para mostrar que se utiliza solo para compensar y está fuera del Flujo Normal.
Este tipo de Manejador solo puede realizar una compensación de "caja negra" de la Actividad original, es decir, no tiene acceso al contenido de la Actividad a compensar en el momento de su finalización.
Nótese que el Manejador consiste en una sola Actividad. Si se requieren varias Actividades para realizar la compensación, entonces se pueden colocar dentro de un Subproceso. Además, solo el Subproceso requiere el marcador de compensación (rebobinado), no las Actividades que contiene.
Subproceso Evento de Compensación
El Manejador consiste en un Subproceso Evento que comienza con un Evento Compensar. Este Subproceso de Evento está dentro de un Subproceso o un Proceso Principal.
Al igual que la Actividad de Compensación, el Subproceso Evento de Compensación está fuera del Flujo Normal.
El Subproceso Evento de Compensación se habilita cuando su Actividad contenedora termina con éxito. En ese momento, se toma una instantánea (snapshot) de los datos de contexto de la Actividad contenedora y se conserva para su uso posterior. Después, cuando se ejecuta el Subproceso Evento de Compensación, los datos de contexto de la Actividad contenedora se restauran a partir de la instantánea. Esto le permite al Subproceso Evento, por ejemplo, compensar de forma selectiva las Actividades del Subproceso (o Proceso Principal) contenedor.
Manejador Implícito de Compensación
Es posible especificar (mediante el atributo compensable) que un Subproceso puede ser compensado sin tener que definir un Manejador de Compensación - Actividad o Subproceso Evento.
Cuando un Subproceso con Compensación Implícita es compensado sus Actividades internas son compensadas en el orden inverso a como fueron originalmente ejecutadas.
Evento Compensar
Los Eventos Compensar de Captura indican el comienzo de Manejadores de Compensación, y los de Lanzamiento para activar las compensaciones, es decir, ejecutar dichos Manejadores. Hay cuatro variantes:
- Evento Intermedio en el Borde: está unido, por medio de una Asociación, a una Actividad que actúa como Manejador de Compensación.
- Evento Inicial: comienza un Subproceso Evento Compensar, no puede usarse para iniciar un Proceso Principal.
- Evento Intermedio en el Flujo de Lanzamiento: se usa para activar la compensación de una o más Actividades.
- Evento Final: se usa para activar la compensación de una o más Actividades.
Evento Compensar - Captura
Un Evento Compensar de Captura indica el comienzo de un Manejador de Compensación. El Evento puede estar al inicio de un Subproceso Evento o en el Borde de una Actividad.
- Evento Intermedio en el Borde: está unido, por medio de una Asociación, a una Actividad que actúa como Manejador de Compensación. A pesar de que se dibuja con una línea doble contínua, este Evento no es Interruptor, ya que solo se compensa una Actividad ya concluida, por lo que el concepto de Interrupción/No-Interrupción no aplica para el Evento Compensar. El Evento queda definido por la Actividad a la que está adosado, ya que la compensación va dirigida a dicha Actividad.
- Evento Inicial: comienza un Subproceso Evento Compensar, no puede usarse para iniciar un Proceso Principal. El Evento queda definido por el Subproceso contenedor, ya que la compensación va dirigida a dicho Subproceso.
Evento Compensar - Lanzamiento
Un Evento Compensar de Lanzamiento, Intermedio en el Flujo o Final, gatilla la Compensación de una o más Actividades.
- Evento Intermedio en el Flujo de Lanzamiento: se usa para activar la compensación de una o más Actividades compensables y visibles desde el Evento.
- Evento Final: se usa para activar la compensación de una o más Actividades compensables y visibles desde el Evento.
Una Actividad es compensable si:
- Ha terminado con éxito, es decir, que una vez concluida la Actividad, el Proceso continúa por uno o más Flujos de Secuencia normales que salen de ella.
- Tiene un Manejador de Compensación explícito (Actividad o Subproceso Evento) o implícito.
Una Actividad es visible desde un Evento Compensar de Lanzamiento si:
- El Evento y la Actividad están en el Flujo en el mismo nivel de un Subproceso o Proceso Principal.
- El Evento está contenido en un Subproceso Evento que está dentro del Subproceso o Proceso Principal que contiene la Actividad.
Si el Evento Compensar de Lanzamiento identifica la Actividad a compensar, y ésta es compensable y visible, entonces se ejecuta su Manejador de Compensación.
Si el Evento Compensar de Lanzamiento no identifica una Actividad, entonces se compensan todas aquellas que sean compensables y visibles, en el orden inverso a como fueron originalmente ejecutadas, bajo las siguientes reglas:
- Si hay un Flujo de Secuencia desde la Actividad A hacia la Actividad B, entonces la compensación de B se realiza antes de la compensación de A.
- Si la Actividad B usa datos producidos por la Actividad A, entonces la compensación de B se realiza antes de la compensación de A.
- Si las Actividades A y B estaban activas dentro de un Subproceso Ad-Hoc, entonces la compensación de B debe realizarse antes de la compensación de A si A terminó antes de que B comenzara.
- Las instancias de un Actividad Iterativa Estándar o de una Multi-Instancia Secuencial se compensan en orden inverso a su finalización original. Las instancias de una Actividad Multi-Instancia Paralela se pueden compensar en paralelo.
- Si una Actividad A tiene un Evento en el Borde conectado a la Actividad B, entonces la compensación de B debe realizarse antes de la compensación de A si se produjo dicho Evento. Esto también se aplica a instancias de Actividades Iterativas.
- Si no hay dependencias entre las Actividades A y B, entonces pueden compensarse en cualquier orden, incluso de forma paralela.
La compensación se activa normalmente por un Manejador de Errores, como parte de una Cancelación, o de forma recursiva por otro Manejador de Compensación.
Si se invoca la Compensación para una Actividad que aún no se ha completado o no se ha completado con éxito, no sucede nada (en particular, no se genera ningún error).
Por defecto, la compensación se realiza de manera sincrónica, es decir, el Evento Compensar de Lanzamiento espera a que se completen los Manejadores de Compensación activados (atributo waitForCompletion=true). Alternativamente, la compensación se puede realizar de manera asincrónica, es decir, el Evento Compensar de Lanzamiento da inicio a las compensaciones y continúa inmediatamente, sin esperar a que éstas terminen (atributo waitForCompletion=false).
Compensación de Acividades Iterativas
Las Actividades Iterativas (Estándar, Multi-Instancia Secuencial y Multi-Instancia Paralela) se instancian varias veces, por lo tanto la Compensación debe considerar este hecho.
Si la Actividad Iterativa es un Subproceso que contiene un Subproceso Evento como Manejedor de Compensación, entonces cada instanciación tiene su propia copia del Manejador de Compensación, que tiene acceso a los datos de la instancia al momento de finalizar exitosamente. Cuando se compensa el Subproceso Iterativo cada una de sus instancias es compensada individualmente.
Si la Actividad Iterativa tiene una Manejador de Compensación conectado a un Evento Compensar en su borde, entonces este Manejador también se invoca una vez para cada instanciación de la Actividad Iterativa. ("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.")
Si la Actividad Iterativa tiene una Manejador de Compensación conectado a un Evento Compensar en su borde, entonces este Manejador solo se invoca una vez y debe compensar los efectos de todas las instancias. ("In case the Activity is a multi-instance or loop, the Compensation Activity is triggered only once, too, and thus has to compensate the effects of all instances.")
Texto
Relación entre el manejo de Errores y la Compensación
Los siguientes elementos definen la relación entre el manejo de errores y la compensación:
- Solo se compensan las Actividades exitósamente completadas. La compensación de una Actividad fallida resulta en una operación vacía.
- Cuando una Actividad falla, es decir, es abandonada porque se ha generado un Error, es responsabilidad del Manejador de Errores garantizar que no será necesaria ninguna compensación adicional una vez que se haya completado el Manejador de Errores.
- Si para un Subproceso en particular y un Error en particular no se especifica ningún Subproceso Evento de Error, el comportamiento por defecto es compensar automáticamente todas las Actividades contenidas en el Subproceso si se produce ese Error.
Dudas
- ¿Qué pasa si se llama más de una vez un Compensación?, ¿qué pasa si se compensa una Actividad que se ha instanciado varias veces?
- ¿Un Subproceso Evento Compensación en un Proceso Principal se usa cuando es referenciado con una Actividad de Llamada?
- Una Actividad de Compensación puede ser Iterativa, ¿qué significa esto?, ¿tiene relación con que la Actividad a compensar sea o no Iterativa? ¿Todas las instancias de una Actividad iterativa terminan con éxito?, ¿qué pasa si una falla? En BPMN 1.2 no se describen las actividades iterativas compensables.
- Si para un Subproceso en particular y un Error en particular no se especifica ningún Subproceso Evento de Error, el comportamiento por defecto es compensar automáticamente todas las Actividades contenidas en el Subproceso si se produce ese Error. ¿Qué pasa si hay un Manejador de Errores general?, ¿qué pasa si el Subproceso termina abruptamente por un Evento Interruptor no Error (en particular Escalada)?
Texto.
Ejemplo
Un escenario típico de uso de Compensación es un Manejador de Errores en línea (Subproceso Evento) que no puede recuperar el error y, como resultado, compensará selectivamente las Actividades del Subproceso que lo contiene.
El ejemplo contiene un Subproceso Evento de Compensación personalizado. Nótese que este Manejador activa las Compensaciones en un orden diferente al de las Actividades originales. Además, contiene una Actividad que agrega lógica de Proceso que vas más allá de solo compensar una o más Actividades.
***************************************************************************
Un Evento TIPO-EVENTO indica un punto donde un Proceso xxxxxxxxxxxxxx.
Como todo Evento, un Evento TIPO-EVENTO se dibuja con un círculo con distintos tipos de línea según sea Inicial, Intermedio o Final. Dentro del círculo se dibuja un(a) xxxxx.
Variantes de Eventos TIPO-EVENTO en BPMN
DESCRIPCIÓN RESUMIDA DEL TIPO DE EVENTO. INCLUYE UNA EXPLICACIÓN DE SU SIGNIFICADO.
Texto.
Texto.
Ejemplo 1
Texto.
Texto.
Ejemplo 1
Texto.
Ejemplo 2
Texto.
Ejemplo 2
- Texto.
- Texto.
- Texto.
- Texto.
Significado del Evento TIPO-EVENTO
- Ejecución de Procesos
- Texto.
- Modelado de Procesos
- Texto.
Texto.
Texto.
Texto.
Tema 1
Texto.
Texto.
Texto.
Tema 2
Texto.
Texto.
Texto.
Evento TIPO-EVENTO Variantes
Hay nnn variantes del Evento TIPO-EVENTO. Este Evento puede ser usado en xxxx Posiciones y Modos.
Variantes de Eventos TIPO-EVENTO
| Posición del Evento | Modo | Notación | Descripción | |
|---|---|---|---|---|
| Evento Inicial | Proceso Principal | Captura | N/A | Comienza una nueva instancia del Proceso cuando TIPO-EVENTO. |
| Subproceso | Captura | N/A | No puede iniciar un Subproceso en el Flujo (Embebido o Reutilizable). | |
| Evento Intermedio | en el Flujo | Captura | N/A | Espera un TIPO-EVENTO. El Flujo continúa cuando llega el TIPO-EVENTO. |
| Lanzamiento | Envía un TIPO-EVENTO. Una vez enviado el TIPO-EVENTO el Flujo continúa. | |||
| en el Borde | Captura con Interrupción | Interrumpe la Actividad a la que está adosado cuando llega un TIPO-EVENTO, y comienza un Flujo de Excepción. | ||
| Captura sin Interrupción | N/A | No interrumpe la Actividad a la que está adosado cuando llega un TIPO-EVENTO, y comienza un Flujo de Excepción. | ||
| Evento Final | Lanzamiento | Envía un TIPO-EVENTO cuando el Flujo llega al final de un camino. | ||
Evento TIPO-EVENTO Intermedio
Un Evento Intermedio TIPO-EVENTO indica xxxxxxxxxxxxxx después de que comienza un Proceso y antes de que termine.
Un Evento Intermedio TIPO-EVENTO puede ser usado en el Flujo o en el Borde de una Actividad.
- Si está en el Flujo, puede recibir o enviar un TIPO-EVENTO.
- Si está en el Borde de una Actividad, solo recibe un TIPO-EVENTO, y puede interrumpir o no la Actividad.
Texto.
Eventos Intermedios TIPO-EVENTO
Conectores
- Flujo de Secuencia
-
Si el Evento Intermedio TIPO-EVENTO está en el Flujo, entonces debe tener Flujos de Secuencia de Entrada y de Salida.
Si el Evento Intermedio TIPO-EVENTO está en el Borde de una Actividad, entonces no debe tener Flujos de Secuencia de Entrada, pero sí debe tener uno o más Flujos de Secuencia de Salida.
- Flujo de Mensaje
-
xxxxxxxx.
Evento TIPO-EVENTO Intermedio en el Flujo Lanzador
|
Un Evento Intermedio TIPO-EVENTO Lanzador en el Flujo envía xxxxx. Texto. Se representa con un círculo de línea doble con un xxxxx oscurecido. |
|
Después de ejecutada la Actividad A el Proceso llega al Evento, lanza xxxxxx y pasa inmediatamente a la Actividad B.
Evento Intermedio TIPO-EVENTO Lanzador en el Flujo
Texto.
Texto.
Un Evento Intermedio TIPO-EVENTO Lanzador también puede estar en el Flujo de un Subproceso Embebido, en cualquier nivel de anidamiento.
Evento Intermedio TIPO-EVENTO Lanzador en el Flujo de Subproceso
Texto.
Los Eventos TIPO-EVENTO en el Flujo usualmente se usan para xxxxxxxxxxxxxxx.
Por ejemplo, en el Proceso de Negocio Ejemplo de la introducción xxxxxxxxxxxx.
Evento Intermedio TIPO-EVENTO en el Flujo
Evento TIPO-EVENTO Intermedio en el Borde Interruptor
|
Un Evento Intermedio TIPO-EVENTO Interruptor en el Borde captura un TIPO-EVENTO, interrumpe la Actividad a la que está adosado y comienza un Flujo de Excepción. El Flujo de Excepción lleva a una o más Actividades que manejan la excepción, y luego continúa hacia un final propio o se une a un Flujo Normal. Se representa con un círculo de línea doble con un xxxxx. |
|
Si TIPO-EVENTO mientras se ejecuta la Actividad B, la Actividad es interrumpida y se continúa por el Flujo de Excepción. Pero si no TIPO-EVENTO, la Actividad B termina normalmente y se pasa a la Actividad C, es decir, continúa el Flujo Normal.
Evento Intermedio TIPO-EVENTO Interruptor en el Borde - dos caminos
En lugar de seguir un camino propio, el Flujo de Excepción se puede reincorporar al Flujo Normal después de procesar la Excepción.
Evento Intermedio TIPO-EVENTO Interruptor en el Borde - un camino
Texto.
Un Evento TIPO-EVENTO en el Borde de una Actividad es usado para que un Proceso reaccione de manera inmediata ante xxxx. Esta reacción consiste en iniciar un Flujo de Excepción.
Por ejemplo, xxx referencia a ejemplo xxxx.
Evento Intermedio TIPO-EVENTO Interruptor en el Borde
Un Evento Intermedio en el Borde siempre es de Captura, nunca de Lanzamiento. La Actividad a la que está adherido puede ser interrumpida o continuar su trabajo.
A diferencia de un Evento Intermedio en el Flujo, que siempre debe gatillarse cuando el Flujo llega a él, un Evento Intermedio en el Borde de una Actividad puede gatillarse o no.
Evento TIPO-EVENTO Final
|
Un Evento Final TIPO-EVENTO lanza un TIPO-EVENTO cuando el Flujo llega al final de un camino. El TIPO-EVENTO es lanzado cuando el Flujo llega al Evento, no hay espera. La instancia del Proceso termina si no hay otros caminos activos. Se representa con un círculo de línea gruesa con un xxxxx oscurecido. |
|
Después de ejecutada la Tarea C el Proceso llega al Evento Final y lanza un TIPO-EVENTO. Como todo Evento Final, el Evento Final TIPO-EVENTO marca en final de un camino en el Flujo del Proceso. Como en el ejemplo solo hay un camino, el Evento también indica el final del Proceso.
Evento Final TIPO-EVENTO
Texto.
Texto.
Un Evento Final TIPO-EVENTO también puede marcar el final de un camino de un Subproceso Embebido, en cualquier nivel de anidamiento.
Evento Final TIPO-EVENTO en Subproceso
Como muestra el ejemplo anterior, un TIPO-EVENTO puede ser lanzado desde cualquier nivel de anidamiento dentro de un Proceso.
Conectores
- Flujo de Secuencia
-
Como todo Evento Final, el Evento Final TIPO-EVENTO debe tener uno o más Flujos de Secuencia de Entrada, y no debe tener Flujos de Secuencia de Salida.
- Flujo de Mensaje
-
xxxxxxxxxxxxxx.
Especificación BPMN
Compensation of a successfully completed Activity triggers its compensation handler. The compensation handler is either user defined or implicit. The implicit compensation handler of a Sub Process calls all compensation handlers of its enclosed Activities in the reverse order of Sequence Flow dependencies. If compensation is invoked for an Activity that has not yet completed, or has not completed successfully, nothing happens (in particular, no error is raised).
Some activities produce complex effects or specific outputs. If the outcome is determined to be undesirable by some specified criteria (such as an order being cancelled), then it will be necessary to “undo” the activities. There are three ways this can be done:
- Restoring of a copy of the initial values for data, thereby overwriting any changes.
- Doing nothing (if nothing has changed because the changes have been set aside until a confirmation).
- Invoking activities that undo the effects--also known as compensation.
An activity that might require compensation could be, for example, one that charges a buyer for some service and debits a credit card to do so. These types of activities usually need a separate activity to counter the effects of the initial activity. Often, a record of both activities is required, so this is another reason that the activity is not “undone.” An Intermediate Event of type Compensation is attached to the boundary of an activity to indicate that compensation may be necessary for that activity.
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.
By default, compensation is triggered synchronously, that is, the throw Compensation Event waits for the completion of the triggered compensation handler. Alternatively, compensation can just be triggered without waiting for its completion, by setting the throw Compensation Event’s waitForCompletion attribute to false.
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.
In normal flow, this Intermediate Event indicates that compensation is necessary. Thus, it is used to "throw" the Compensation Event, and the Event marker MUST be filled. If an Activity is identified, and it was successfully completed, then that Activity will be compensated. The Activity MUST be visible from the Compensation Intermediate Event, i.e., one of the following MUST be true:
- The Compensation Intermediate Event is contained in normal flow at the same level of Sub-Process.
- The Compensation Intermediate Event is contained in a Compensation Event Sub-Process which is contained in the Sub-Process containing the Activity.
If no Activity is identified, all successfully completed Activities visible from the Compensation Intermediate Event are compensated, in reverse order of their Sequence Flows. Visible means one of the following:
- The Compensation Intermediate Event is contained in normal flow and at the same level of Sub-Process as the Activities.
- The Compensation Intermediate Event is contained in a Compensation Event Sub-Process which is contained in the Sub-Process containing the Activities.
To be compensated, an Activity MUST have a boundary Compensation Event, or contain a Compensation Event Sub-Process.
Compensation Events are used in the context of triggering or handling compensation (see page 301 for more details on compensation). There are four variations: a Start Event, both a catch and throw Intermediate Event, and an End Event.
- The Compensation Start Event MAY NOT be used for a top-level Process.
- The Compensation Start Event MAY be used for an Event Sub-Process.
- The catch Compensation Intermediate Event MUST only be attached to the boundary of an Activity and, thus, MAY NOT be used in normal flow.
- The throw Compensation Intermediate Event MAY be used in normal flow.
- The Compensation End Event MAY be used within any Sub-Process or Process.
Attribute activityRef:
- For a Start Event: This Event “catches” the compensation for an Event Sub-Process. No further information is REQUIRED. The Event Sub-Process will provide the Id necessary to match the Compensation Event with the Event that threw the compensation, or the compensation will have been a broadcast.
- For an End Event: The Activity to be compensated MAY be supplied. If an Activity is not supplied, then the compensation is broadcast to all completed Activities in the current Sub-Process (if present), or the entire Process instance (if at the global level).
- For an Intermediate Event within normal flow: The Activity to be compensated MAY be supplied. If an Activity is not supplied, then the compensation is broadcast to all completed Activities in the current Sub-Process (if present), or the entire Process instance (if at the global level). This “throws” the compensation.
- For an Intermediate Event attached to the boundary of an Activity: This Event “catches” the compensation. No further information is REQUIRED. The Activity the Event is attached to will provide the Id necessary to match the Compensation Event with the Event that threw the compensation, or the compensation will have been a broadcast.
Attribute waitForCompletion: For a throw Compensation Event, this flag determines whether the throw Intermediate Event waits for the triggered compensation to complete (the default), or just triggers the compensation and immediately continues (the BPMN 1.2 behavior).
In normal flow, this Intermediate Event indicates that compensation is necessary. Thus, it is used to "throw" the Compensation Event, and the Event marker MUST be filled.
When attached to the boundary of an Activity, this Event is used to "catch" the Compensation Event, thus the Event marker MUST be unfilled. The Event will be triggered by a thrown compensation targeting that Activity. When the Event is triggered, the Compensation Activity that is associated to the Event will be performed. Note that the interrupting a non-interrupting aspect of other Events does not apply in the case of a Compensation Event. Compensations can only be triggered after completion of the Activity to which they are attached. Thus they cannot interrupt the Activity. The boundary of the Event is always solid.
This type of End indicates that compensation is necessary. If an Activity is identified, and it was successfully completed, then that Activity will be compensated. The Activity MUST be visible from the Compensation End Event, i.e., one of the following MUST be true:
- The Compensation End Event is contained in normal flow at the same level of Sub-Process.
- The Compensation End Event is contained in a Compensation Event Sub-Process that is contained in the Sub-Process containing the Activity.
- If no Activity is identified, all successfully completed Activities visible from the Compensation End Event are compensated, in reverse order of their Sequence Flows. Visible means one of the following:
- The Compensation End Event is contained in normal flow and at the same level of Sub-Process as the Activities.
- The Compensation End Event is contained in a Compensation Event Sub-Process that is contained in the Sub-Process containing the Activities.
To be compensated, an Activity MUST have a boundary Compensation Event or contain a Compensation Event Sub-Process.
Compensation Association occurs outside the normal flow of the Process and is based upon a Compensation Intermediate Event that is triggered through the failure of a transaction or a throw Compensation Event (see page 302). The target of the Association MUST be marked as a Compensation Activity.
isForCompensation:boolean = false. A flag that identifies whether this Activity is intended for the purposes of compensation. If false, then this Activity executes as a result of normal execution flow. If true, this Activity is only activated when a Compensation Event is detected and initiated under Compensation Event visibility scope (see page 280 for more information on scopes).
Compensation (p. 301)
Compensation is concerned with undoing steps that were already successfully completed, because their results and possibly side effects are no longer desired and need to be reversed. If an Activity is still active, it cannot be compensated, but rather needs to be canceled. Cancellation in turn can result in compensation of already successfully completed portions of an active Activity, in case of a Sub-Process.
Compensation is performed by a compensation handler. A compensation handler can either be a Compensation Event Sub-Process (for a Sub-Process or Process), or an associated Compensation Activity (for any Activity). A compensation handler performs the steps necessary to reverse the effects of an Activity. In case of a Sub-Process, the compensation handler has access to Sub-Process data at the time of its completion (“snapshot data”).
Compensation is triggered by a throw Compensation Event, which typically will be raised by an error handler, as part of cancellation, or recursively by another compensation handler. That Event specifies the Activity for which compensation is to be performed, either explicitly or implicitly.
Compensation Handler (p. 302)
A compensation handler is a set of Activities that are not connected to other portions of the BPMN model. The compensation handler starts with a catch Compensation Event. That catch Compensation Event either is a boundary Event, or, in case of a Compensation Event Sub-Process, the handler’s Start Event.
A compensation handler connected via a boundary Event can only perform “black-box” compensation of the original Activity. This compensation is modeled with a specialized Compensation Activity, which is connected to the boundary Event through an Association (see Figure 10.121). The Compensation Activity, which can be either a Task or a Sub-Process, has a marker to show that it is used for compensation only and is outside the normal flow of the Process.
Note that there can be only one target activity for compensation. There cannot be a sequence of activities shown. If the compensation does require more than one activity, then these activities must be put inside a single Sub-Process that is the target of the Association. The Sub-Process can be collapsed or expanded. If the Sub-Process is expanded, then only the Sub-Process itself requires the Compensation marker--the activities inside the Sub-Process do not require this marker.
A Compensation Event Sub-Process is contained within a Process or a Sub-Process (see Figure 10.122). Like the Compensation Activity, the Compensation Event Sub-Process is outside the normal flow of the Process. The Event Sub-Process, which is marked with a dotted line boundary, can access data that is part of its parent, a snapshot at the point in time when its parent completed. A Compensation Event Sub-Process can recursively trigger compensation for Activities contained in its parent.
It is possible to specify that a Sub-Process can be compensated without having to define the compensation handler. The Sub-Process attribute compensable, when set, specifies that default compensation is implicitly defined, which recursively compensates all successfully completed Activities within that Sub-Process, invoking them in reverse order of their forward execution.
The example in 10.122, above contains a custom Compensation Event Sub-Process, triggered by a Compensation Start Event. Note that this compensation handler deviates from default compensation in that it runs Compensation Activities in an order different from the order in the forward case; it also contains an additional Activity adding Process logic that cannot be derived from the body of the Sub-Process itself.
Compensation Triggering
Compensation is triggered using a compensation throw 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.
By default, compensation is triggered synchronously, that is, the compensation throw Event waits for the completion of the triggered compensation handler. Alternatively, compensation can just be triggered without waiting for its completion, by setting the throw Compensation Event’s waitForCompletion attribute to false.
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.
*************************************************************
Relationship between Error Handling and Compensation
The following items define the relationship between error handling and compensation:
Compensation employs a “presumed abort principle,” with the following consequences: Compensation of a failed Activity results in a null operation.
When an Activity fails, i.e., is left because an error has been thrown, it’s the error handlers responsibility to ensure that no further compensation will be necessary once the error handler has completed.
If no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to automatically call compensation for all contained Activities of that Sub-Process if that error is thrown, ensuring the behavior for auditing and monitoring.
xxxxxxxxxxxxxxxxxxxxx
Compensation employs a “presumed abort principle,” which has a number of consequences.
First, only completed Activities are compensated; compensation of a failed Activity results in an empty operation. Thus, when an Activity fails, i.e., is left because an error has been thrown, it’s the error handler’s responsibility to ensure that no further compensation will be necessary once the error handler has completed.
Second, if no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to automatically call compensation for all contained Activities of that Sub-Process if that error occurs, thus ensuring the “presumed abort” invariant.
*************************************************************
Operational semantics
- A Compensation Event Sub-Process becomes enabled when its parent Activity transitions into state Completed. At that time, a snapshot of the data associated with the parent Activity is taken and kept for later usage by the Compensation Event Sub-Process. In case the parent Activity is a multi-instance or loop, for each instance a separate data snapshot is taken, which is used when its associated Compensation Event Sub-Process is triggered.
- When compensation is triggered for the parent Activity, its Compensation Event Sub-Process is activated and runs. The original context data of the parent Activity is restored from the data snapshot. In case the parent Activity is a multi-instance or loop, for each instance the dedicated snapshot is restored and a dedicated Compensation Event Sub-Process is activated.
- An associated Compensation Activity becomes enabled when the Activity it is associated with transitions into state Completed. When compensation is triggered for that Activity, the associated Compensation Activity is activated. In case the Activity is a multi-instance or loop, the Compensation Activity is triggered only once, too, and thus has to compensate the effects of all instances.
-
Default compensation ensures that Compensation Activities are performed in reverse order of the execution of the original Activities, allowing for concurrency when there was no dependency between the original Activities. Dependencies between original Activities that default compensation MUST consider are the following:
- A Sequence Flow between Activities A and B results in compensation of B to be performed before compensation of A.
- A data dependency between Activities A and B, e.g., through an IORules specification in B referring to data produced by A, results in compensation of B to be performed before compensation of A.
- If A and B are two Activities that were active as part of an Ad-Hoc Sub-Process, then compensation of B MUST be performed before compensation of A if A completed before B started.
- Instances of a loop or sequential multi-instance are compensated in reverse order of their forward completion. Instances of a parallel multi-instance can be compensated in parallel.
- If a Sub-Process A has a boundary Event connected to Activity B, then compensation of B MUST be performed before compensation of A if that particular Event occurred. This also applies to multi-instances and loops.
