Una Actividad es un punto en el Proceso donde se realiza el trabajo. Son los elementos ejecutables de un Proceso BPMN. Hay dos tipos de Actividades:
- Tarea
- Actividad atómica - sus detalles no son descritos usando un (sub)diagrama BPMN.
- Subproceso
- Actividad no atómica (compuesta) - sus detalles son descritos usando un (sub)diagrama BPMN.
Las Actividades se representan con rectángulos de esquinas redondeados.
IMAGEN CON ICONOS DE TAREAS Y SUBPROCESOS.
Toda Actividad tiene un responsable de realizarla, es el Ejecutor. El Ejecutor puede ser un individuo específico, un grupo, una cargo o rol, o una organización. En la práctic está representada por el Carril o Piscina.
Una Actividad puede ser ejecutada por un sistema (automatizado) o por humanos (manual).
Una Actividad de Llamada permite la inclusión de Tareas y Procesos reutilizables en el diagrama.
Una actividad puede realizarse una vez o repetirse.
Un Actividad es ejecutada por un individuo específico, un grupo, un cargo o rol en una organización, una unidad organiacional, o una organización.
Una Tarea se usa cuando el trabajo en el Proceso no se desglosa a un nivel más fino de detalle del Proceso.
Un Subproceso es compuesto porque se puede dividir en un nivel de detalle más fino a través de un conjunto de subactividades.
Conexión a Flujos de Secuencia
A una Actividad pueden llegar cero (0) o más Flujos de Secuencia, y puede salir de ella cero (0) o más Flujos de Secuencia.
Nota: Hay dos excepciones a esto: La Actividades de Compensación y los Subprocesos Evento no pueden ser el destino ni la fuente de Flujos de Secuencia, y tampoco se rigen por las reglas que se indican a continuación.
Flujos de secuencia entrantes.
Si no tiene Flujos de Secuencia entrantes, la Actividad debe instanciarse cuando se instancia el Proceso.
Si la Actividad tiene múltiples Flujos de Secuencia entrantes, se considera un Flujo no Controlado. Esto significa que:
- Cuando llega un Token por uno de los caminos, no esperará la llegada de tokens de los otros caminos y se instanciará la Actividad.
- Si llega otro Token desde el mismo u otro Flujo, se creará una instancia separada de la Actividad.
- Si es necesario controlar los Flujos, entonces se debe colocar, antes de la Actividad, una Compuerta que sincronice los Flujos.
Flujos de secuencia salientes
Una Actividad puede tener cero o más Flujos de Secuencia salientes.
Una Actividad sin Flujo de Secuencia saliente marca el final de uno o más caminos en el Proceso. Cuando finaliza la Actividad y no hay otros caminos paralelos activos, el Proceso finaliza.
Una Actividad con varios Flujos de Secuencia salientes crea un camino paralelo separado para cada Flujo de Secuencia.
Conexión a Flujos de Mensaje
A una Actividad pueden llegar cero o más Flujos de Menseje, y puede salir de ella cero o más Flujos de Mensaje.
Todos los Flujos de Mensaje que llegan o salen de una Actividad deben venir de o llegar a una Piscina distinta a la Piscina donde se encuentra la Actividad. Esto se deriva del hecho que todo Flujo de Mensaje conecta dos Piscinas distintas. (Tocar el tema de la matriz RACI.)
Cualquier Actividad puede ser el destino o el origen de los Flujos de Mensaje. Sin embargo, las Tareas de Servicio, Envío y Recepción se suelen utilizar para comunicar, mediante Mensajes, los Procesos.
Los Flujos de Mensaje hacia o desde un Subproceso indican que éste enviará o recibirá Mensajes en algún nivel de anidamiento.
Ciclo de Vida
Todas las actividades comparten atributos y comportamientos comunes, como estados y transiciones de estado.
Una actividad pasa a estado LISTA (lista para ejecutarse) si ha llegado un Token por algún Flujo de Secuencia. (Nota: en configuraciones avanzadas se puede requerir más de un Token para que la Actividad pase a estado Ready.)
Si la Actividad requiere datos y estos están disponibles, la Actividad para de estado LISTA a estado ACTIVA.
Una Actividad estado LISTA o ACTIVA puede ser RETIRADA para que no pueda completarse. Esto ocurre para las Tareas de Recepción que están después de una Compuerta Exclusiva de Eventos. El primer elemento (Evento o Tarea) que se completa hace que las demás tareas sean RETIRADAS.
Si una Actividad falla durante la ejecución, para de estado ACTIVA a FALLIDA. Si ocurre una falla en el entorno de la Actividad, se activa la terminación de la Actividad y pasa a estado TERMINADA.
Si la Actividad finaliza sin anomalías, para a estado COMPLETANDO. Este estado intermedio se ocupa de los pasos previos a la finalización de la Actividad. Esto es útil cuando la Actividad tiene adosados Eventos no interruptores. Si alguno de se ha gatillado, la Actividad debe esperar que los respectivos Manejadores de los Eventos terminen antes que la Actividad pueda completarse. El estado COMPLETANDO indica que la Actividad principal ha terminado y no se aceptan más Eventos adosados.
La ejecución de una Actividad se interrumpe si se produce un Evento de interrupción o si se inicia un Subproceso de Evento de interrupción. En este caso, el estado de la Actividad cambia a FALLANDO (en caso de error) o TERMINANDO (en caso de un Evento interruptor). Todas las Actividades anidadas que no están en estado LISTA, ACTIVA o en un estado final (COMPLETADA, COMPENSADA, FALLIDA, etc.) y los Subprocesos Eventos no interrutores son terminados.
Una vez que cumplidas las dependencias de finalización, la Actividad pasa a estado COMPLETADA. Los Flujos de Secuencia salientes se activan. Si hay más de un Flujo de Secuencia de salida, la Actividad se comporta como una Compuerta Paralela. Al finalizar, también se activan todas sus salidas de datos, si los hubiera.
Si no hay compensación, la instanciación de Actividad termina en estado Completada. Si hay compensación y ésta es gatillada, se invoca el Manejdor de la Compensación y la Actividad pasa a COMPENSANDO hasta que la compenación finaliza correctamente (COMPENSADa), se produce una excepción (FALLIDA), o se gatilla una terminación (TERMINADA).
Iteración
| Marcador | Notación | Descripción | |
|---|---|---|---|
| Iteration | Estándar | Icons |
La Actividad se repite mientras se cumple una condición lógica. La condición se evalúa para cada iteración, al principio o al final de ésta. La actividad se repetirá siempre que la condición lógica sea verdadera. Opcionalmente, se puede especificar un límite numérico, de modo que las iteraciones no pueden superar dicho límite. Se representan con una pequeña flecha enroscada en la parte inferior de la Actividad. |
| Multi-Instancia Paralelo | Icons |
La Actividad se repite un determinado número de veces. Para cada repetición se crea una instancia de la Actividad. Las instancias se ejecutan en paralelo, o una después de otra. Se usa una expresión numérica para calcular el número de instancias, o se puede usar una configuración basada en una entrada de datos de tipo colección. El número de elementos de la colección determina el número de instancias de Actividad. La Multi-Instancia Paralela se representa con tres líneas verticales en la parte inferior de la Actividad. |
|
| Multi-Instancia Secuencial | Icons |
En el caso de la Multi-Instancia Secuencial las líneas son horizontales. |
|
Una vez terminada la Iteración la Actividad como un todo se completa y el Flujo del Proceso continúa.
Cuando es una Iteración Multi-Instancia, se debe indicar cómo obtener la cardinalidad: colección de datos o indicación explícita en el nombre y/o descripción de la Actividad.
Cuando es una Iteración Multi-Instancia se puede indicar que se lanzará un Evento para el primer ciclo que se complete, o que se lanzará un Evento por cada ciclo que se complete. Sin embargo, el lanzamiento no se refleja gráficamente en el diagrama, pero su captura puede realizarse con eventos de borde no interruptores.
El Marcador de Compensación puede usarse en combinación con un Marcador de Iteración.
Todos los marcadores que están presentes DEBEN estar agrupados y todo el grupo centrado en la parte inferior de la forma.
Un Actividad Iterativa Multi-Instancia actúa como un envoltorio para una Actividad que tiene múltiples instancias generadas en paralelo o secuencialmente.
Un Actividad Iterativa Multi-Instancia también puede tener una condición de finalización que se evalúa cada vez que se completa una instancia. Cuando es verdadera, las instancias restantes se cancelan, se produce un token para los flujos de secuencia salientes y se completa la actividad MI.
La Actividad Iterativa Multi-Instancia se compensa solo si todas sus instancias se han completado con éxito.
Compatibilidad con patrones de flujo de trabajo: bucle estructurado WCP-21, patrones de instancias múltiples WCP 13, 14, 34, 36.
Un Actividad Iterativa Multi-Instancia puede producir una colección de datos, donde cada elemento de la colección es producido por un instancia. Esta colección no debe ser accesible hasta que se hayan escrito todos sus elementos. Esto se debe a que una actividad que se ejecuta simultáneamente puede acceder a ella y, por lo tanto, el flujo de control a través del paso de tokens no puede garantizar que la colección esté completamente escrita antes de que se acceda a ella.
Como toda Actividad, una Actividad Iterativa puede ser instanciada varias veces, en la medida que llega un Token. Pero en el caso de una Actividad Multi-Instancia cada instanciación normal (outer instance) lleva a la creación de tantas instancias (inner instances) como lo indique la expresión o el conjunto de datos que la define.
Actividad de Llamada
Una Actividad de Llamada identifica un punto en el Proceso donde se (re)utiliza un Proceso global o una Tarea global. La Actividad de Llamada actúa como un "envoltorio" para la invocación. La activación de una Actividad de Llamada transfiere el control al Proceso Global o a la Tarea Global.
Para implementar la reutilización en cualquier notación se necesitan dos elementos: el objeto que será reutilizado y el objeto que permite llamar (referenciar) al primero.
BPMN permite la reutilización de Tareas y Procesos.
- Una Tarea reutilizable se conoce como Tarea Global. Se define de manera aislada, es decir, no es parte de ningún diagrama.
- Un Proceso reutilizable se conoce como Proceso Global. En realidad es cualquier Proceso Principal, es decir, aquél que está directamente localizado en su Piscina. Para poder ser reutilizado debe tener un Evento Inicial Vacío.
En ambos casos, la llamada (referencia) se realiza a través de una Actividad de Llamada, que puede ser una referencia a:
- Una Tarea Global. Se utiliza la forma de la Tarea normal (rectángulo redondeado con marca de su tipo en la esquina superior izquierda), pero se dibuja con línea gruesa.
- Un Proceso Global. Se utiliza la forma de un Subproceso normal (colapsado o expandido), pero se dibuja con línea gruesa.
La Actividad de Llamada debe proveer los datos al objeto llamado (Tarea Global o Proceso Global), y debe recibir los datos entregados por éste. Además, los Eventos que se propagan a lo largo de la jerarquía (Errores y Escaladas) se propagan desde el elemento llamado a la Actividad de Llamada (y se pueden manejar en su Borde).
Compensación
A veces se dan ciertas condiciones que llevan a que un Proceso (o Subproceso) revierta parte del trabajo realizado. Esto puede conducir, de manera no excluyente, a:
- El Proceso (o Subproceso) que detecta la condición anómala se cancela antes de completarse. Para ello puede usar el Evento Final Terminar, o usar Eventos de Borde Interruptores.
- El Proceso (o Subproceso) que detecta la condición anómala lanza Eventos para cancelar Actividades activas, las que tienen Eventos de Borde que capturan los Eventos lanzados por el Proceso (o Subproceso).
- El Proceso (o Subproceso) que detecta la condición anómala reversa los efectos de Actividades ya completadas. Para ello lanza Eventos de Compensación.
La Compensación se ocupa de deshacer los efectos de Acividades que ya se completaron con éxito, porque sus resultados y posiblemente los efectos secundarios ya no se desean y deben revertirse. Si una Actividad aún está activa, no se puede compensar, sino que debe cancelarse. La cancelación, a su vez, puede resultar en la compensación de partes ya completadas con éxito de una Actividad activa, en el caso de un Subproceso.
La Compensación la realiza un Manejador de Compensación. Este puede ser un Subproceso Evento de Compensación (para un Proceso o Subproceso) o una Actividad de Compensación asociada a cualquier Actividad a través de una Asociación. El Manejador de Compensación realiza los pasos necesarios para revertir los efectos de una Actividad.
La Compensación se gatilla por un Evento de Compensación lanzado, normalmente, por un Manjedor de Errores, como parte de la cancelación de una Actividad, o de forma recursiva por otro Manejador de Compensación. El Evento de Compensación identifica, explícita o implícitamente, la Actividad que debe ser compensada.
Manejador de compensación
Un Manejador de Compensación es una Actividad de Compensación que no está conectada al Flujo del Diagrama BPMN. El Manejador de Compensación comienza con un Evento de Compensación de Borde. O, en el caso de un Subproceso de Evento de compensación, es el Evento Incial del Controlador.
Un Manejador de Compensación conectado a través de un Evento de Borde sólo puede realizar una compensación de "caja negra" de la actividad original.
Un Subproceso Evento de Compensación está contenido dentro de un Proceso o Subprocesos. Puede acceder a datos que forman parte de su padre. Un Subproceso Evento de Compensación puede, en particular, desencadenar recursivamente la Compensación de las Actividades contenidas en su padre. El subproceso de evento, que está marcado con un límite de línea de puntos, puede acceder a los datos que forman parte de su padre, una instantánea en el momento en que se completó su padre.
El ejemplo de 10.122 contiene un Subproceso Evento de Compensación, desencadenado por un Evento Inicial de Compensación. Tenga en cuenta que este Manejador de Compensación se desvía de la Compensación predeterminada en el sentido de que ejecuta Actividades de Compensación en un orden diferente al original; también contiene una Actividad adicional que agrega lógica de proceso que no se puede derivar del propio Subproceso.
Es posible que un Subproceso puede ser compensado sin tener que definir el Manejador de Compensación. Cuando la compensación se define implícitamente, se compensan todas las actividades completadas con éxito dentro del Subproceso, invocándolas en orden inverso a su ejecución original.
Solo se compensan las Actividades completadas. Por lo tanto, cuando una Actividad falla, es decir, se deja porque se ha producido un error, es responsabilidad del manejador de Errores asegurarse de que no se necesiten compensaciones. Además, si no hay Manejador de Errores para un Subproceso, por defecto se se compensan automáticamente todas las Actividades del Subproceso si se produce el error.
Se permite un Marcador de Compensación para cualquier tipo de Actividad (Tarea o Subproceso) pero no para un Subproceso Evento. El Marcador de Compensación es un par de triángulos orientados hacia la izquierda (botón de "rebobinado") colocados en la parte inferior central de la Actividad. El Marcador de Compensación se puede combinar con un Marcador de Iteración.
Semántica Operacional
- Un Subproceso Evento de Compensación queda habilitdoa cuando su Actividad padre pasa al estado COMPLETADO. En ese momento, guardan los datos asociados con la Actividad padre y se conserva para su uso posterior por parte del Subproceso Evento de Compensación. En caso de que la Actividad padre sea una Multi-Instancia, para cada instancia se guardan datos por separado, que se utilizan cuando se activa su Subproceso de Evento de Compensación.
- Cuando se activa la Compensación para la Actividad padre, su Subproceso Evento de Compensación se activa y se ejecuta. Los datos de contexto originales guardados se restauran. Si la Actividad padre es Multi-Instancia, para cada instancia se restaura su propio conjunto de datos y se activa un Subproceso Evento de Compensación propio.
- Una Actividad de Compensación asociada se habilita cuando la Actividad que compensa pasa al estado COMPLETADA. Cuando se activa la Compensación para esa Actividad, se activa la Actividad de Compensación asociada. En caso de que la Actividad sea una Multi-Instancia, la Actividad de Compensación se activa solo una vez y, por lo tanto, tiene que compensar los efectos de todas las instancias.
- La compensación predeterminada garantiza que las actividades de compensación se realicen en orden inverso a la ejecución de las actividades originales, lo que permite la concurrencia cuando no hubo dependencia entre las actividades originales. Las dependencias entre las actividades originales que la compensación predeterminada DEBE considerar son las siguientes:
- Un Flujo de Secuencia entre las actividades A y B da como resultado que la Compensación de B se realice antes que la Compensación de A.
- Una dependencia de datos entre las actividades A y B: datos producidos por A son consumidos por B, da como resultado que la Compensación de B se realice antes que la Compensación de A.
- Si A y B son dos Actividades de un Subproceso ad-hoc, la Compensación de B deberealizarse antes que la Compensación de A, si A se completó antes de que B comenzara.
- Las instancias de una Multi-Instancia secuencial se compensan en orden inverso a su finalización original. Las instancias de una Multi-Instancia paralela se pueden compensar en paralelo.
- Si un Subproceso A tiene un Evento de Borde conectado a la Actividad B, entonces la compensación de B debe realizarse antes que la Compensación de A si ocurrió ese Evento en particular.
Especificación BPMN
An Activity is a Process step that can be atomic (Tasks) or decomposable (Subprocesses) and is executed by either a system (automated) or humans (manual). All Activities share common attributes and behavior such as states and state transitions. An Activity, regardless of type, has lifecycle generally characterizing its operational semantics. The lifecycle, described as a UML state diagram in Figure 13.2, entails states and transitions between the states.
An Activity is a generic term for work that company performs (see page 149) in a Process. An Activity can be atomic or non-atomic (compound). The types of Activities that are a part of a Process Model are: Sub-Process and Task, which are rounded rectangles. Activities are used in both standard Processes and in Choreographies.
An Activity is a generic term for work that company performs (see page 149) in a Process. An Activity can be atomic or nonatomic (compound). The types of Activities that are a part of a Process Model are: Sub-Process and Task, which are rounded rectangles.
An Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic (compound). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inclusion of re-usable Tasks and Processes in the diagram.
An Activity is a Process step that can be atomic (Tasks) or decomposable (Sub-Processes) and is executed by either a system (automated) or humans (manual).
Activities represent points in a Process flow where work is performed. They are the executable elements of a BPMN Process.
An Activity MAY be performed once or MAY be repeated. If repeated, the Activity MUST have loopCharacteristics that define the repetition criteria (if the isExecutable attribute of the Process is set to true).
A resource will perform or will be responsible for the Activity. The resource, e.g., a performer, can be specified in the form of a specific individual, a group, an organization role or position, or an organization.
Activities are used in both standard Processes and in Choreographies.
A Task is an atomic Activity that is included within a Process (see page 154). A Task is used when the work in the Process is not broken down to a finer level of Process detail.
A Sub-Process is a compound Activity that is included within a Process (see page 171) or Choreography (see page 335). It is compound in that it can be broken down into a finer level of detail (a Process or Choreography) through a set of sub-Activities.
An Activity MAY be a target for zero (0) or more Sequence Flows. It MAY be a source for zero (0) or more Sequence Flows also. There are two exceptions to this: Compensation Activities and Event Subprocesses.
Incoming sequence flows
An Activity MAY be a target for Sequence Flows; it can have multiple incoming Sequence Flows. Incoming Sequence Flows MAY be from an alternative path and/or parallel paths.
If the Activity does not have an incoming Sequence Flow, then the Activity MUST be instantiated when the Process is instantiated. (Except for Compensation Activities and Event Subprocesses.)
If the Activity has multiple incoming Sequence Flows, then this is considered uncontrolled flow. This means that when a token arrives from one of the Paths, the Activity will be instantiated. 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 Activity will be created. If the flow needs to be controlled, then the flow should converge on a Gateway that precedes the Activities (see “Gateways” on page 286 for more information on Gateways).
Outgoing sequence flows
An Activity MAY be a source for Sequence Flows; it can have multiple outgoing Sequence Flows. If there are multiple outgoing Sequence Flows, then this means that a separate parallel path is being created for each Sequence Flow (i.e., tokens will be generated for each outgoing Sequence Flow from the Activity).
If the Activity does not have an outgoing Sequence Flow, then the Activity marks the end of one or more paths in the Process. When the Activity ends and there are no other parallel paths active, then the Process MUST be completed. (Except for Compensation Activities and Event Subprocesses.)
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 Activity MAY be the target of a Message Flow; it can have zero (0) or more incoming Message Flows.
An Activity MAY be a source of a Message Flow; it can have zero (0) or more outgoing Message Flows.
Any activity may be the target or a source of message flows. Nevertheless Service, Send and Receive task are usually used to deal with messages. Message Flows into or from a Subprocesses indicate that it will send or receive Messages at some level of nesting.
An Activity is a Process step that can be atomic (Tasks) or decomposable (Subprocesses) and is executed by either a system (automated) or humans (manual). All Activities share common attributes and behavior such as states and state transitions. An Activity, regardless of type, has lifecycle generally characterizing its operational semantics. The lifecycle, described as a UML state diagram in Figure 13.2, entails states and transitions between the states.
An Activity is Ready for execution if the REQUIRED number of tokens is available to activate the Activity. The REQUIRED number of tokens (one or more) is indicated by the attribute StartQuantity. If the Activity has more than one Incoming Sequence Flows, there is an implied Exclusive Gateway that defines the behavior.
When some data InputSet becomes available, the Activity changes from Ready to the Active state. The availability of a data InputSet is evaluated as follows. The data InputSets are evaluated in order. For each InputSet, the data inputs are filled with data coming from the elements of the context such as Data Objects or Properties by triggering the input Data Associations. An InputSet is available if each of its REQUIRED Data Inputs is available. A data input is REQUIRED by a data InputSet if it is not optional in that InputSet. If an InputSet is available, it is used to start the Activity. Further InputSets are not evaluated. If an InputSet is not available, the next InputSet is evaluated. The Activity waits until one InputSet becomes available. Please refer to 10.4.2 on page 224 for a description of the execution semantics for Data Associations.
An Activity, if Ready or Active, can be Withdrawn from being able to complete in the context of a race condition. This situation occurs for Tasks that are attached after an Event-Based Exclusive Gateway. The first element (Task or Event) that completes causes all other Tasks to be withdrawn.
If an Activity fails during execution, it changes from the state Active to Failed. If a fault happens in the environment of the Activity, termination of the Activity is triggered, causing the Activity to go into the state Terminated.
If an Activity’s execution ends without anomalies, the Activity’s state changes to Completing. This intermediate state caters for processing steps prior to completion of the Activity. An example of where this is useful is when noninterrupting Event Handlers (proposed for BPMN 2.0) are attached to an Activity. They need to complete before the Activity to which it is attached can complete. The state Completing of the main Activity indicates that the execution of the main Activity has been completed, however, the main Activity is not allowed to be in the state Completed, as it still has to wait for all non-interrupting Event Handlers to complete. The state Completing does not allow further processing steps, otherwise allowed during the execution of the Activity. For example, new attached non-interrupting Event Handlers MAY be created as long as the main Activity is in state Active. However, once in the state Completing, running handlers should be completed with no possibility to create new ones.
An Activity’s execution is interrupted if an interrupting Event is raised (such as an error) or if an interrupting Event Subprocess is initiated, In this case, the Activity’s state changes to Failing (in case of an error) or Terminating (in case any other interrupting Event). All nested Activities that are not in Ready, Active or a final state (Completed, Compensated, Failed, etc.) and non-interrupting Event Subprocesses are terminated. The data context of the Activity is preserved in case an interrupting Event Subprocess is invoked. The data context is released after the Event Subprocess reaches a final state.
After all completion dependencies have been fulfilled, the state of the Activity changes to Completed. The outgoing Sequence Flows becomes active and a number of tokens, indicated by the attribute CompletionQuantity, is placed on it. If there is more than one outbound Sequence Flows for an Activity, it behaves like an implicit Parallel Gateway. Upon completion, also a data OutputSet of the Activity is selected as follows. All OutputSets are checked for availability in order. An OutputSet is available if all its REQUIRED Data Outputs are available. A data output is REQUIRED by an OutputSet if it is not optional in that OutputSet. If the data OutputSet is available, data is pushed into the context of the Activity by triggering the output Data Associations of all its data outputs. Further OutputSets are not evaluated. If the data OutputSet is not available, the next data OutputSet is checked. If no OutputSet is available, a runtime exception is thrown. If the Activity has an associated IORule, the chosen OutputSet is checked against that IORule, i.e., it is checked whether the InputSet that was used in starting the Activity instance is together with the chosen OutputSet compliant with the IORule. If not, a runtime exception is thrown.
Only completed Activities could, in principle, be compensated, however, the Activity can end in state Completed, as compensation might not be triggered or there might be no compensation handler specified. If the compensation handler is invoked, the Activity changes to state Compensating until either compensation finishes successfully (state Compensated), an exception occurs (state Failed), or controlled or uncontrolled termination is triggered (state Terminated).
A standard loop MUST be a small line with an arrowhead that curls back upon itself. The loop Marker MAY be used in combination with the Compensation Marker. The standardLoopCharacteristics class defines looping behavior based on a boolean condition. The Activity will loop as long as the boolean condition is true. The condition is evaluated for every loop iteration, and MAY be evaluated at the beginning or at the end of the iteration. In addition, a numeric cap can be optionally specified. The number of iterations MAY NOT exceed this cap.
A parallel multi-instance MUST be a set of three vertical lines. The MultiInstanceLoopCharacteristics class allows for creation of a desired number of Activity instances. The instances MAY execute in parallel or MAY be sequential. Either an Expression is used to specify or calculate the desired number of instances or a data driven setup can be used. In that case a data input can be specified, which is able to handle a collection of data. The number of items in the collection determines the number of Activity instances. This data input can be produced by an input Data Association. The modeler can also configure this loop to control the tokens produced.
All the markers that are present MUST be grouped and the whole group centered at the bottom of the shape.
Activities MAY be repeated sequentially, essentially behaving like a loop. The presence of LoopCharacteristics signifies that the Activity has looping behavior. LoopCharacteristics is an abstract class. Concrete subclasses define specific kinds of looping behavior.
Implicit Throw Event
A sub-type of throw Event is the ImplicitThrowEvent. This is a non-graphical Event that is used for Multi-Instance Activities (see page 190).
A Call Activity MUST fulfill the data requirements, as well as return the data produced by the CallableElement being invoked (see Figure 10.41). This means that the elements contained in the Call Activity’s InputOutputSpecification MUST exactly match the elements contained in the referenced CallableElement. This includes DataInputs, DataOutputs, InputSets, and OutputSets.
A Call Activity can override properties and attributes of the element being called, potentially changing the behavior of the called element based on the calling context. For example, when the Call Activity defines one or more ResourceRole elements, the elements defined by the CallableElement are ignored and the elements defined in the Call Activity are used instead. Also, Events that are propagated along the hierarchy (errors and escalations) are propagated from the called element to the Call Activity (and can be handled on its boundary).
The Performer class defines the resource that will perform or will be responsible for an Activity. The performer can be specified in the form of a specific individual, a group, an organization role or position, or an organization.
The Performer element inherits the attributes and model associations of BaseElement (see Table 8.5) through its relationship to ResourceRole, but does not have any additional attributes or model associations.
