En BPMN, una Transacción es un Subproceso especializado cuya ejecución es controlada por un protocolo especial (p.ej. WS-Tansaction) que asegura que todas las partes involucradas están de acuerdo en que, una vez que el Subproceso comienza, se completará con éxito o se cancelará, es decir, todas las acciones realizadas hasta el momento de su término prematuro serán reversadas.
Una Transacción se representa con un rectángulo redondeado, como los demás Subprocesos, pero que se dibuja con una línea delgada doble.
Para su funcionamiento, una Transacción requiere de Eventos Cancelar (Intermedio en el Borde Interruptor y Final). Los Eventos Cancelar no se pueden usar en inguna Actividad que no sea un Subproceso Transacción.
La ejecución de un Subproceso Transacción tiene tres posibles resultados:
- Finalización exitosa: esto se representa con Flujos de Secuencia normales que sale de la Transacción. (Es decir, Flujos- Condicionales o Incondionales - que no se originan en Eventos en el Borde.)
- Cancelación: cancelar una Transacción consiste en cancelar sus Actividades internas, lo que incluye reversar (roll back) lo hecho hasta el momento de la cancelación, y compensar algunas Actividades específicas[2]. Un Evento Intermedio Cancelar en el Borde de la Transacción indica el Flujo a seguir después de que se haya reversado la Transacción y se hayan completado todas las compensaciones. Existen dos mecanismos para gatillar la cancelación de una Transacción:
- Se llega a un Evento Final Cancelar dentro de la Transacción.
- Se recibe un Mensaje de cancelación a través del protocolo que está ejecutando la Transacción.
- Peligro (Hazard): Esto significa que algo salió mal y que no es posible una finalización normal, ni una cancelación (salida ordenada). Se utilizan Eventos Intermedios Error para modelar estas situaciones críticas. Cuando esto ocurre, la Actividad se interrumpe (sin compensación) y el flujo continua desde el Evento Intermedio Error en el Borde.
La finalización de una Transacción exitosa es ligeramente diferente al de un Subproceso normal. Cuando todos los camninos dentro de la Transacción llegan a su Evento Final (distinto de Cancelar), el flujo no vuelve inmediatamente al Proceso de nivel superior que contiene la Transacción, como lo hace un subproceso normal. En este caso, el protocolo que ejecuta la Transacción verifica que todos los Participantes hayan completado con éxito su parte de la Transacción. La mayoría de las veces esto será cierto y el flujo se moverá hacia el Proceso de nivel superior. Pero es posible que uno de los Participantes termine con un problema que provoque una Cancelación o un Peligro. En este caso, el flujo se moverá al Evento Intermedio de Borde apropiado, aunque aparentemente haya terminado con éxito.
Las Transacciones (colapsadas o expandidas) también pueden tener Marcadores de Compensación y de Iteración en su parte inferior central.
Cancelación
Si una Actividad aún está activa y presenta algún problema, no puede ser compensada, sino que debe ser cancelada. La Cancelación, a su vez, puede dar lugar a la compensación de partes ya completadas con éxito dentro de la Actividad, en el caso de un subproceso.
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.
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.
Especificación BPMN
A transaction is a Sub-Process that is supported by a special protocol that insures that all parties involved have complete agreement that the activity should be completed or canceled (see page 176). The attributes of the activity will determine if the activity is a transaction. A double-lined boundary indicates that the Sub-Process is a Transaction.
A Transaction is a specialized type of Sub-Process that will have a special behavior that is controlled through a transaction protocol (such as WS-Transaction). The boundary of the Sub-Process will be double-lined to indicate that it is a Transaction (see Figure 10.33).
A Transaction Sub-Process is a rounded corner rectangle that MUST be drawn with a double thin line.
There are three basic outcomes of a Transaction:
- Successful completion: this will be shown as a normal Sequence Flow that leaves the Transaction Sub-Process.
- Failed completion (Cancel): When a Transaction is canceled, the Activities inside the Transaction will be subjected to the cancellation actions, which could include rolling back the Process and compensation (see page 301 for more information on compensation) for specific Activities. Note that other mechanisms for interrupting a Transaction Sub-Process will not cause compensation (e.g., Error, Timer, and anything for a non-Transaction Activity). A Cancel Intermediate Event, attached to the boundary of the Activity, will direct the flow after the Transaction has been rolled back and all compensation has been completed. The Cancel Intermediate Event can only be used when attached to the boundary of a Transaction Sub-Process. It cannot be used in any normal flow and cannot be attached to a non-Transaction Sub-Process. There are two mechanisms that can signal the cancellation of a Transaction:
- A Cancel End Event is reached within the transaction Sub-Process. A Cancel End Event can only be used within a transaction Sub-Process.
- A cancel Message can be received via the transaction protocol that is supporting the execution of the Transaction Sub-Process.
- Hazard: This means that something went terribly wrong and that a normal success or cancel is not possible. Error Intermediate Events are used to show Hazards. When a Hazard happens, the Activity is interrupted (without compensation) and the flow will continue from the Error Intermediate Event.
The behavior at the end of a successful Transaction Sub-Process is slightly different than that of a normal Sub-Process. When each path of the Transaction Sub-Process reaches a non-Cancel End Event(s), the flow does not immediately move back up to the higher-level parent Process, as does a normal Sub-Process. First, the transaction protocol needs to verify that all the Participants have successfully completed their end of the Transaction. Most of the time this will be true and the flow will then move up to the higher-level Process. But it is possible that one of the Participants can end up with a problem that causes a Cancel or a Hazard. In this case, the flow will then move to the appropriate Intermediate Event, even though it had apparently finished successfully.
Transactions (collapsed or expande can also have Compensation and/or Loop Characteristic markers at the bottom center of the shape.
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.
