Resumen. Resumen. Resumen. Resumen. Resumen. Resumen.
Resumen. Resumen. Resumen. Resumen. Resumen. Resumen.
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.
Advanced
BPMN-Specification-text. BPMN-Specification-text. BPMN-Specification-text.
BPMN-Specification-text. BPMN-Specification-text. BPMN-Specification-text.
Otros
Procesos, Actividades y Eventos a menudo necesitan datos para ejecutarse, y también producen datos durante o como resultado de su ejecución.
- Los datos de entrada se modelan con Entradas de Datos (DataInput).
- Los datos de salida se modelan con Salidas de Datos (DataOutput).
Solo las Tareas, elementos invocables (Procesos Globales y Tareas Globales) y Eventos (Mensaje, Señal, Error y Escalada) puede definir Entradas y Salidas de Datos. Los Subprocesos Embebidos no definen Entradas y Salidas de Datos.
En el caso de las Tareas y Eventos, las Entradas y Salidas de Datos son propiedades internas, no tienen representación gráfica en BPMN.
El contenido de una Salida de Datos de una Tarea o Evento fluye por una Asociación de Datos hacia un Objeto de Datos. Análogamente, el contenido de un Objeto de Datos fluye por una Asociación de Datos y es recibido en un Entrada de Datos de la Tarea o Evento.
En el Modelado de Procesos, Entradas y Salidas de Datos pueden ser parte de la documentación de la Tarea. En la Ejecución de Procesos, el BPMS deberá implementar lo estipulado en la Especificación de BPMN (DataInputs, DataOutputs, InputSets, OutputsSets e InputOutputSpecifications).
En el caso de un Proceso Global (un Proceso Principal invocado a través de una Actividad de Llamada), las Entradas y Salidas de Datos sí se muestran en el diagrama.
La notación es la misma que el Objeto de Datos, pero con una flecha sin relleno ("⇨") para la Entrada de Datos, y una flecha con relleno ("➨") para la Salida de Datos.
Las Entradas y Salidas de Datos pueden representar un ítem único o una colección. Para indicar que es una colección, al igual que el Objeto de Datos, se agrega un Marcador de tres líneas verticales ("☰"), que se coloca en la parte inferior central.
Para un Proceso Global, el Proceso invocador le provee de datos, que son recibidos por una Entrada de Datos. Igualmente, cuando el Proceso Global termina, entrega los resultados al Proceso invocador a través de una Salida de Datos.
Cuando la Entrada de Datos está contenida directamente en el Proceso Principal, no debe tener Asociaciones de Datos entrantes.
Cuando el Proceso Global es invocado desde una Actividad de Llamada, las Asociaciones de Datos que llegan a las Entradas de Datos de la Actividad de Llamada en el modelo subyacente pueden visualizarse de manera que se conecten a las Entradas de Datos correspondientes del Proceso invocado, cruzando visualmente el límite de la Actividad de Llamada. Pero téngase en cuenta que esto es solo visualización, en el modelo subyacente, las Asociaciones de Datos apuntan a las Entradas de Datos de la Actividad de Llamada y no a las Entradas de Datos del Proceso invocado.
Cuando la Salida de Datos está contenida directamente en el Proceso Principal, no debe tener Asociaciones de Datos salientes.
Cuando el Proceso Global es invocado desde una Actividad de Llamada, las Asociaciones de Datos que se originan en las Salidas de Datos de la Actividad de Llamada en el modelo subyacente pueden visualizarse de manera que se conecten a las Salidas de Datos correspondientes del Proceso invocado, cruzando visualmente el límite de la Actividad de Llamada. Pero téngase en cuenta que esto es solo visualización, en el modelo subyacente, las Asociaciones de Datos se originan en las Salidas de Datos de la Actividad de Llamada y no en las Salidas de Datos del Proceso invocado.
Para permitir que un Proceso Global pueda ser invocado tanto a través de una Actividad de Llamada, como por la llegada de un Mensaje, los Eventos Iniciales y Finales están relacionados con las Entradas y Salidas de Datos.
- En el caso de un Evento Inicial, las Entradas de Datos del Proceso reciben - desde el Evento - los datos del Mensaje recibido. De esta manera, las Entradas de Datos del Proceso se pueden completar utilizando los datos que activaron el Evento Inicial.
- En el caso de un Evento Final, las Salidas de Datos del Proceso proveen los datos para que el Evento cree el Mensaje a enviar. De esta manera, el Evento Final usa como fuente las Salida de Datos del Proceso.
A continuación se describe el mapeo de Entradas y Salidas de Datos para Actividades y Eventos específicos.
Tarea de Envío: debe tener solo una Entrada de Datos, con la misma estructura del Mensaje a enviar.
Tarea de Recepción: debe tener solo una Salida de Datos, con la misma estructura del Mensaje recibido.
Tareas de Servicio: debe tener solo una Entrada de Datos, con la misma estructura del Mensaje a enviar; y debe tener solo una Salida de Datos, con la misma estructura del Mensaje recibido.
Tarea de usuario: tiene acceso a las Entrada y Salidas de datos disponibles en el ámbito de la Tarea.
Tareas Script: tiene acceso a las Entrada y Salidas de datos disponibles en el ámbito de la Tarea.
Actividad de Llamada: Las Entradas y Salidas de Datos de la Actividad de Llamada se mapean a los elementos correspondientes del Elemento invocado (Proceso Global o Tarea Global), sin ninguna Asociación de Datos explícita.
Eventos
Algunos Eventos (Mensaje, Señal, Escalada y Error) transportan datos. Para tales Eventos, se cumple:
- Un Evento de Captura tiene una Salida de Datos con la misma estructura de datos del ítem capturado (Mensaje, Señal, Escalada o Error). El Proceso extrae el ítem mediante una Asociación de Datos que sale del Evento y llega a un Objeto de Datos. Cuando ocurre el Evento, los datos se asignan automáticamente a la Salida de Datos y de ahí fluye por la Asociación de Datos.
- Un Evento de Lanzamiento tiene una Entrada de Datos con la misma estructura de datos del ítem a lanzar (Mensaje, Señal, Escalada o Error). El Proceso coloca el ítem en el Evento mediante una Asociación de Datos que llega al Evento desde un Objeto de Datos. Cuando se activa el Evento, los datos en la Entrada de Datos se asignan automáticamente al ítem correspondiente.
Un Evento Múltiple que tiene Eventos Mensaje, Señal, Escalada y/o Error debe tener las Entradas o Salidas de Datos correspondientes.
Modelo Subyacente
Un Conjunto de Entradas (InputSet) agrupa cero o más Entradas de Datos (DataInput). Un DataInput puede estar en varios InputSet.
Un Conjunto de Salidas (OutputSet) agrupa cero o más Salidas de Datos (DataOutput). Un DataOutput puede estar en varios OutputSet.
Un Elemento tiene un InputOutputSpecification, que contiene uno o más InputSet, y uno o más OutputSet.
Normalmente, la situación es más sencilla. Por ejemplo, una Tarea de Recepción tiene un InputOutputSpecification con un solo un InputSet vacío, y un OutputSet con solo un DataOutput.
Especificación BPMN
To allow invoking a Process from both a Call Activity and via Message Flow, the Start Event and End Event support an additional case.
In the case of a Start Event, the Data Inputs of the enclosing process are available as targets to the DataOutputAssociations of the Event. This way the Process Data Inputs can be filled using the elements that triggered the Start Event.
In the case of an End Event, the Data Outputs of the enclosing process are available as sources to the DataInputAssociations of the Event. This way the resulting elements of the End Event can use the Process Data Outputs as sources.
Activities and Processes often need data in order to execute. In addition they can produce data during or as a result of execution. Data requirements are captured as Data Inputs and InputSets. Data that is produced is captured using Data Outputs and OutputSets. These elements are aggregated in a InputOutputSpecification class.
Certain Activities and CallableElements contain a InputOutputSpecification element to describe their data requirements. Execution semantics are defined for the InputOutputSpecification and they apply the same way to all elements that extend it.
Not every Activity type defines inputs and outputs, only Tasks, CallableElements (Global Tasks and Processes) MAY define their data requirements. Embedded Sub-Processes MUST NOT define Data Inputs and Data Outputs directly, however they MAY define them indirectly via MultiInstanceLoopCharacteristics.
Data Inputs and Data Outputs rendering are optional and only allowed for Processes.
Data Input
A Data Input is a declaration that a particular kind of data will be used as input of the InputOutputSpecification. There may be multiple Data Inputs associated with an InputOutputSpecification.
The Data Input is an item-aware element. Data Inputs are visually displayed on a Process diagram to show the inputs to the top-level Process or to show the inputs of a called Process (i.e., one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process).
Visualized Data Inputs have the same notation as Data Objects, except that they MUST contain a small, unfilled block arrow (see Figure 10.58).
Data Inputs MAY have incoming Data Associations:
- If the Data Input is directly contained by the top-level Process, it MUST not be the target of Data Associations within the underlying model. Only Data Inputs that are contained by Activities or Events MAY be the target of Data Associations in the model.
- If the Process is being called from a Call Activity, the Data Associations that target the Data Inputs of the Call Activity in the underlying model MAY be visualized such that they connect to the corresponding Data Inputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations target the Data Inputs of the Call Activity and not the Data Inputs of the called Process.
If the InputOutputSpecification defines no Data Input, it means no data is REQUIRED to start the Activity.
DataInput elements can optionally reference a DataState element, which is the state of the data contained in the DataInput. The definition of these states, e.g., possible values, and any specific semantics are out of scope of this International Standard. Therefore, BPMN adopters can use the DataState element and the BPMN extensibility capabilities to define their states.
A DataInput is used in one or more InputSets.
Attribute inputSetwithOptional. Each InputSet that uses this DataInput can determine if the Activity can start executing with this DataInput state in “unavailable.” This attribute lists those InputSets.
Attribute inputSetWithWhileExecuting. Each InputSet that uses this DataInput can determine if the Activity can evaluate this DataInput while executing. This attribute lists those InputSets.
Attribute isCollection. Defines if the DataInput represents a collection of elements. It is needed when no itemDefinition is referenced. If an itemDefinition is referenced, then this attribute MUST have the same value as the isCollection attribute of the referenced itemDefinition. The default value for this attribute is false.
Data Output
A Data Output is a declaration that a particular kind of data can be produced as output of the InputOutputSpecification. There MAY be multiple Data Outputs associated with a InputOutputSpecification.
The Data Output is an item-aware element. Data Output are visually displayed on a top-level Process diagram to show the outputs of the Process (i.e., one that is referenced by a Call Activity, where the Call Activity has been expanded to show the called Process within the context of a calling Process).
Visualized Data Outputs have the same notation as Data Objects, except that they MUST contain a small, filled block arrow (see Figure 10.60).
Data Outputs MAY have outgoing DataAssociations.
- If the Data Output is directly contained by the top-level Process, it MUST not be the source of Data Associations within the underlying model. Only Data Outputs that are contained by Activities or Events MAY be the target of Data Associations in the model.
- If the Process is being called from a Call Activity, the Data Associations that originate from the Data Outputs of the Call Activity in the underlying model MAY be visualized such that they connect to the corresponding Data Outputs of the called Process, visually crossing the Call Activity boundary. But note that this is visualization only. In the underlying model, the Data Associations originate from the Data Outputs of the Call Activity and notfrom the Data Outputs of the called Process.
If the InputOutputSpecification defines no Data Output, it means no data is REQUIRED to finish the Activity. This is an ordered set.
DataOutput elements can optionally reference a DataState element, which is the state of the data contained in the DataOutput. The definition of these states, e.g., possible values, and any specific semantics are out of scope of this International Standard. Therefore, BPMN adopters can use the DataState element and the BPMN extensibility capabilities to define their states.
A DataOutput is used in one or more OutputSets.
Attribute outputSetwithOptional. Each OutputSet that uses this DataOutput can determine if the Activity can complete executing without producing this DataInput. This attribute lists those OutputSets.
Attribute outputSetWithWhileExecuting. Each OutputSet that uses this DataInput can determine if the Activity can produce this DataOutput while executing. This attribute lists those OutputSets.
Attribute isCollection. Defines if the DataOutput represents a collection of elements. It is needed when no itemDefinition is referenced. If an
itemDefinition is referenced, then this attribute MUST have the same value as the isCollection attribute of the referenced itemDefinition. The default value for this attribute is false.
The following describes the mapping of data inputs and outputs to the specific Activity and Event implementations.
Service Task Mapping
If the Service Task is associated with an Operation, there MUST be a Data Output on the Service Task and it MUST have an itemDefinition equivalent to the one defined by the Message referred to by the inMessageRef attribute of the operation.
If the operation defines output Messages, there MUST be a single Data Input and it MUST have an itemDefinition equivalent to the one defined by Message referred to by the outMessageRef attribute of the Operation.
Send Task Mapping
If the Send Task is associated with a Message, there MUST be at most inputSet set and at most one Data Input on the Send Task. If the Data Input is present, it MUST have an itemDefinition equivalent to the one defined by the associated Message. If the Data Input is not present, the Message will not be populated with data at execution time.
Receive Task Mapping
If the Receive Task is associated with a Message, there MUST be at most outputSet set and at most one Data Output on the Receive Task. If the Data Output is present, it MUST have an itemDefinition equivalent to the one defined by the associated Message.If the Data Output is not present, the payload within the Message will not flow out of the Receive Task and into the Process.
User Task Mapping
User Tasks have access to the Data Input, Data Output and the data aware elements available in the scope of the User Task.
Call Activity Mapping
The DataInputs and DataOutputs of the Call Activity are mapped to the corresponding elements in the CallableElement without any explicit DataAssociation.
Script Task Mapping
Script Tasks have access to the Data Input, Data Output and the data aware elements available in the scope of the Script Task.
Events
If any of the EventDefinitions for the Event is associated with an element that has an ItemDefinition (such as a Message, Escalation, Error, or Signal), the following constraints apply:
Some Events (like the Message, Escalation, Error, Signal, and Multiple Event) have the capability to carry data. Data Association is used to push data from a Catch Event to a data element. For such Events, the following constraints apply:
- If the Event is associated with multiple EventDefinitions, there MUST be one Data Input (in the case of throw Events) or one Data Output (in the case of catch Event) for each EventDefinition. The order of the EventDefinitions and the order of the Data Inputs/Outputs determine which Data Input/Output corresponds with which EventDefinition.
- For each EventDefinition and Data Input/Output pair, if the Data Input/Output is present, it MUST have an ItemDefinition equivalent to the one defined by the Message, Escalation, Error, or Signal on the associated EventDefinition. In the case of a throw Event, if the Data Input is not present, the Message, Escalation, Error, or Signal will not be populated with data. In the case of a catch Event, if the Data Output is not present, the payload within the Message, Escalation, Error, or Signal will not flow out of the Event and into the Process.
The execution behavior is then as follows:
- For throw Events: When the Event is activated, the data in the Data Input is assigned automatically to the Message, Escalation, Error, or Signal referenced by the corresponding EventDefinition.
- For catch Events: When the trigger of the Event occurs (for example, the Message is received), the data is assigned automatically to the Data Output that corresponds to the EventDefinition that described that trigger.
InputSet
An InputSet is a collection of DataInput elements that together define a valid set of data inputs for an InputOutputSpecification. An InputOutputSpecification MUST have at least one InputSet element. An InputSet MAY reference zero or more DataInput elements. A single DataInput MAY be associated with multiple InputSet elements, but it MUST always be referenced by at least one InputSet.
An “empty” InputSet, one that references no DataInput elements, signifies that the Activity requires no data to start executing (this implies that either there are no data inputs or they are referenced by another input set).
InputSet elements are contained by InputOutputSpecification elements; the order in which these elements are included defines the order in which they will be evaluated.
There are not inputsets for events (check this). A message catching event has not outputset, a recieve task has one, with only one data input.
OutputSet
An OutputSet is a collection of DataOutputs elements that together can be produced as output from an Activity or Event. An InputOutputSpecification element MUST define at least OutputSet element. An OutputSet MAY reference zero or more DataOutput elements. A single DataOutput MAY be associated with multiple OutputSet elements, but it MUST always be referenced by at least one OutputSet.
An “empty” OutputSet, one that is associated with no DataOutput elements, signifies that the ACTIVITY produces no data.
The implementation of the element where the OutputSet is defined determines the OutputSet that will be produced. So it is up to the Activity implementation or the Event, to define which OutputSet will be produced.
