Datos BPMN

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).

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.

Elemento	Icono	Descripción
Objeto de Datos	Icono	Los Objetos de Datos representan ítems que son creados, manipulados y consumidos, por Actividades y Eventos, dentro de los límites de un Proceso.
Almacén de Datos	Icono	Un Almacén de Datos representa un lugar donde se guardan ítems que trascienden al Proceso, es decir, que existen antes y/o después del Proceso. El Proceso recupera estos ítems, los manipula y los actualiza.
Entrada / Salida de Datos	Icono	Las Entradas/Salidas de Datos describen los ítems que recibe/entrega un Proceso cuando es llamado desde otro Proceso, vía una Actividad de Llamada.
Mensaje	Icono	La comunicación entre los Procesos de dos Participantes se describe con un Flujo de Mensaje. El Mensaje representa el contenido de dicha comunicación.

BPMN define notaciones distintas para el intercambio de datos dentro de una Piscina o entre Piscinas:

Dentro de una Piscina:

• Objeto de Datos (simple o múltiple), Almacén de Datos y Asociación de Datos.
• Los datos entran/salen de Actividades y Eventos Mensaje dentro de la Piscina.
• La entrada/salida se muestra con líneas de Asociación.
• Las Asociaciones nunca cruzan los límites de la Piscina.
• Los datos nunca salen o entran de las Compuertas.

Entre Piscinas:

• Mensaje y Flujo de Mensaje
• Los Mensajes fluyen entre Actividades y Eventos Mensaje en diferentes Piscinas.
• Si la Piscina es “caja negra”, los Flujos de Mensaje llegan o salen de esta.
• Los Mensajes representan el elemento que transporta los datos (boleta, e-mail…).
• También se pueden usar para representar objetos físicos.
• Los Mensajes siempre van junto a un Flujo de Mensaje en el espacio entre las Piscinas.
• Los Mensajes son opcionales, se pueden reemplazar por un rótulo junto al Flujo de Mensaje.

Texto.

Texto.

Texto.

Objeto de Datos

Los Objetos de Datos representan ítems que son creados, manipulados y consumidos, por Actividades y Eventos, dentro de los límites de un Proceso.

Los ítems recibidos por un Evento de Captura pueden ser asignados a un Objeto de Datos, debe haber una Asociación de Datos desde el Evento hacia el Objeto de Datos. Para un Evento Múltiple puede haber varios Objeto de Datos, uno para cada Evento en particular.

Los Objetos de Datos deben estar contenidos en un Proceso Principal o en un Subproceso.

Un Objeto de Datos solo puede ser accedido por (Ejemplo p. 206.):

1. El Proceso padre, es decir, el Proceso Principal o Subproceso que lo contiene de manera inmediata.
2. Los Subprocesos Embebidos contenidos en el Proceso padre, y sus Subprocesos Embebidos, en distintos niveles de anidamiento.
3. Actividades, Eventos y Referencias Objetos de Datos contenidos en los anteriores.

Cuando se instancia un Proceso o Subproceso, también se instancian todos los Objetos de Datos que contiene.

Cuando se elimina una instancia de Proceso o Subproceso, también se eliminan todas las instancias de Objeto de Datos que contiene.

Los Objetos de Datos pueden representar un ítem único o una colección. Para indicar que es una colección, el Objeto de Datos tiene un Marcador de tres líneas verticales ("☰"), que se coloca en su parte inferior central.

Las Referencias a Objetos de Datos son una forma de reutilizar Objetos de Datos en un mismo diagrama. Cada referencia puede indicar un estado del mismo Objeto de Datos en diferentes estapas del Proceso. La descripción del contenido se coloca en el Objeto de Datos, y el estado en la Referencia al Objeto de Datos. El nombre de esta última se construye concatenando el nombre del Objeto de Datos y el estado: <Nombre de objeto de datos> [ <estado> ].

Además, se pueden usar varias Referencias a un Objeto de Datos para simplificar las conexiones en un diagrama.

Alternativamente, los Objetos de Datos se pueden asociar directamente a un Flujo de Secuencia (Figuras 10.67 y 10.68). Esta es una simplificación visual, pues sigue habiendo dos Asociaciones de Datos, una que va de la Actividad A hacia el Objeto de Datos, y otra que va de éste hacia la Actividad B.

Almacén de Datos

Un Almacén de Datos representa un lugar donde se guardan ítems que trascienden al Proceso, es decir, que persisten más allá del alcance del Proceso.

Un Almacén de Datos no se muestra directamente en un diagrama. Se usan Referencias a Almacenes de Datos, para mostrar un Almacén de Datos en uno o varios lugares del diagrama.

De este modo, el Almacén de Datos se mantiene como una entidad única que es referenciada en los diagramas de varios Procesos.

Cuando los datos entran o salen de una Referencia a Almacén de Datos, efectivamente están entrando o saliendo del Almacén de Datos al que se hace referencia.

Nota: Compérese esto con un Objeto de Datos, que se puede visualizar directamente o a través de una Referencia de Objeto de Datos, siempre dentro de un único Proceso.

Texto.

Texto.

Entrada/Salida de Datos

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.

Entrada de Datos y Salida de Datos solo se usan para pasar y recibir datos al llamar a un Proceso Global. No hay que confundirlos con la entrada/salida de datos hacia/desde una Actividad, lo que se hace con Objetos y Almacenes de Datos.

Texto.

Mensaje

La comunicación entre los Procesos de dos Participantes se describe con un Flujo de Mensaje. El Mensaje representa el contenido de dicha comunicación.

Opcionalmente, en el diagrama se puede colocar la representación gráfica del Mensaje: un rectángulo con líneas diagonales convergentes en su mitad superior, para dar la apariencia de un sobre. Debe estar colocado en el punto medio del Flujo de Mensaje.

Es posible distinguir entre el Mensaje que inicia una interacción (initiating Message) y el que responde (non-initiating Mesage). Este último se dibuja con un fondo sombreado claro (Figura 8.27).

Las Tareas de Servicio, Envío y Recepción, y los Eventos Mensaje (Captura y Lanzamiento) son los elementos BPMN usados para el envío y recepción de Mensajes.

Texto.

Texto.

Otros

En toda comunicación hay intercambio de datos, por ejemplo: nombre del cliente, dirección de despacho. etc. A nivel tecnológico el intercambio de datos puede ser visto como intercambio de bits o bytes, pero para un Proceso de Negocios el nivel significaivo es el par [atributo, valor]. Por ejemplo: [fecha de nacimiento, 12/enero/1989].

Una parte esencial del modelado de Procesos es el modelado de ítems creados, manipulados y usados durante la ejecución de un Proceso. Estos ítems pueden ser datos, información, elementos físicos, productos y/o servicios. (Poner ejemplos: el catálogo de productos, y los productos en sí.)

(Colocar imagen IDEF que muestra claramente lo que una Actividad requiere y lo que transforma.)

Además de la representación gráfica de los ítems que maneja el Proceso, es importante conocer las estructuras de datos que describen estos ítems, y tener la capacidad de consultarlos y manipularlos. (Esto no es parte de BPMN.)

Se puede hacer una analogía con elementos usados en lengajes de programación como variables, parámetros y conectores a base de datos.

BPMN contiene varios elementos que almacenan y transportan ítems durante la ejecución del Proceso. En la Especificación de BPMN se les denomina "item-aware elements".

Elemento	Icono	Descripción
Error	Icono	Se genera un Error cuando hay un problema crítico en el procesamiento de una Actividad. El Error contiene información sobre sobre su origen. No tiene representación gráfica.
Señal	Icono	Una Señal es un mecanismo general de comunicación dentro y entre niveles de Proceso. La Señal representa el contenido de dicha comunicación. No tiene representación gráfica.
Escalada	Icono	Una Escalada identifica una situación, no crítica, a la que un Proceso necesita reaccionar. La Escalada contiene información sobre su origen. No tiene representación gráfica.

Nota: A pesar de que algunos de los elementos tienen en su nombre la palabra "Dato", no están limitados sólo a representar datos, sino que representan ítems en general: datos, información, elementos físicos, productos y/o servicios.

BPMN establece dos tipos predeterminados de ítem: información y elemento físico (Information y Physical). Sin embargo, no hay diferencia en la figura utilizada. La herramienta o el modelador puede usar diferentes colores para resaltar el tipo de ítem.

Cuando una Actividad o Evento están listos para comenzar la ejecución, deben esperar a que los ítems requeridos estén disponibles. La forma en que esto se lleva a cabo, y se representa gráficamente, depende de la Actividad o Evento, y del elemento que contiene los ítems.

Durante la ejecución de Actividad o la activación de un Evento, se pueden producir ítems. La forma en que esto se lleva a cabo, y se representa gráficamente, depende de la Actividad o Evento, y del elemento que contiene los ítems.

Una Actividad espera que sus ítems estén disponibles para comenzar su ejecución. Una vez terminada su ejecución, se llenan los ítems de salida.

En el caso de los Eventos de Lanzamiento y Captura, dada su naturaleza, el manejo de los ítems es diferente.

Cuando se activa un Evento de Lanzamiento, se toman todos los ítems de entrada, y con estos se crea el elemento lanzado por el Evento (Mensaje, Señal, etc.). En el caso más simple, el Evento tiene solo una entrada que tiene la misma estructura del elemento lanzado.

Cuando se activa un Evento de Captura, los ítems de salida del Evento se llenan con el contenido del elemento que activó el Evento (Mensaje, Señal, etc.). En el caso más simple, el Evento tiene solo una salida que tiene la misma estructura del elemento capturado.

No es parte BPMN la definición de un lenguaje para describir las estructuras de datos y realizar consultas sobre ellos. BPMN permite la coexistencia de múltiples lenguajes para describir los datos (por ejemplo, XPath). La compatibilidad y verificación de estos lenguajes es responsabilidad del proveedor de la herramienta. (Esto es relevante cuando se usa BPMN para la ejecución de procesos, pero no para el modelado de procesos.)

Recursos

Además de ítems que el Proceso crea y/o transforma, las Actividades requieren otros recursos para realizar su trabajo. Por ejemplo: personas, normas, herramientas.

BPMN no incorpora ningún elemento gráfico para mostrar estos Recursos en el diagrama. Es posible crear nuevos Artefactos este efecto. Sin embargo, en la descripción de las Actividades debe entregarse el detalle de los Recursos requeridos.

El Ejecutor de la Actividad es en sí un Recurso que ya está representado por la Piscina o Carril donde está la Actividad.

Nota: para Procesos Ejecutables, el modelo subyacente BPMN sí considera la todación de recursos a las Actividades. Ver Resource y ResourceParameter. Los detalles dependerán de cómo un BPMS implemente esta funcionalidad.

Temporal

Texto.Texto.

Texto.Texto.

Texto.Texto.

Texto.Texto.

Especificación BPMN

Item Definition

BPMN elements, such as DataObjects and Messages, represent items that are manipulated, transferred, transformed, or stored during Process flows. These items can be either physical items, such as the mechanical part of a vehicle, or information items such the catalog of the mechanical parts of a vehicle.

An important characteristics of items in Process is their structure. BPMN does not require a particular format for this data structure, but it does designate XML Schema as its default. The structure attribute references the actual data structure.

In cases where the data structure represents a collection, the multiplicity can be projected into the attribute isCollection.

The itemKind attribute specifies the nature of an item which can be a physical or an information item. The default value is information.

Message, Error, Escalation, ItemAwareElement (Property, DataInput, DataOutput, DataObject, DataStore),  ResourceParameter are related to an ItemDefinition.

Resources

The Resource class is used to specify resources that can be referenced by Activities. These Resources can be Human Resources as well as any other resource assigned to Activities during Process execution time.

The definition of a Resource is “abstract,” because it only defines the Resource, without detailing how e.g., actual user IDs are associated at runtime. Multiple Activities can utilize the same Resource.

Every Resource can define a set of ResourceParameters. These parameters can be used at runtime to define query e.g., into an Organizational Directory. Every Activity referencing a parameterized Resource can bind values available in the scope of the Activity to these parameters.

Resources can be assigned to an Activity using Expressions. These Expressions MUST return Resource entity related data types, like Users or Groups. Different Expressions can return multiple Resources. All of them are assigned to the respective subclass of the ResourceRole element, for example as potential owners.

Error, Escalation and Signal are "item-aware" also. But they are not graphically represented.

A traditional requirement of Process modeling is to be able to model the items (physical or information items) that are created, manipulated, and used during the execution of a Process. An important aspect of this is the ability to capture the structure of that data and to query or manipulate that structure.

This requirement is realized in BPMN through various constructs.

Error, Escalation and Signal are "item-aware" also. The ErrorEventDefinition, EscalationEventDefinition, and SignalEventDefinition subclasses comprise of attributes to carry data. But they are not graphically represented.

Data Objects provide information about what Activities require to be performed and/or what they produce (see page 204), Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.

A Message is used to depict the contents of a communication between two Participants (as defined by a business PartnerRole or a business PartnerEntity—see on page 91). AVERIGUAR SI MESSAGE ES UN DATA OBJECT O UN ARTIFACT.

Execution Semantics for Data

When an element that defines an InputOutputSpecification is ready to begin execution by means of Sequence Flow or Event being caught, the inputs of the interface are filled with data coming from elements in the context, such as Data Objects or Properties. The way to represent these assignments is the Data Association elements.

Each defined InputSet element will be evaluated in the order they are included in the InputOutputSpecification.

For each InputSet, the data inputs it references will be evaluated if it is valid.

All data associations that define as target the data input will be evaluated, and if any of the sources of the data association is “unavailable,” then the InputSet is “unavailable” and the next InputSet is evaluated.

The first InputSet where all data inputs are “available” (by means of data associations) is used to start the execution of the Activity. If no InputSet is “available,” then the execution will wait until this condition is met.

The time and frequency of when and how often this condition is evaluated is out of scope for this International Standard. Implementations will wait for the sources of data associations to become available and then re-evaluate the InputSets.

In the case of throw and catch Events, given their nature, the execution semantics for data is different.

When a throw Event is activated, all DataInputAssociations of the event are executed, filling the Data Inputs of the Event. Finally, DataInputs are then copied to the elements thrown by the Event (Messages, Signals, etc.). Since there are no InputSets defined for Events, the execution will never wait.

When a catch Event is activated, Data Outputs of the event are filled with the element that triggered the Event. Then all DataOutputAssociations of the Event are executed. There are no OutputSets defined for Events. Once an InputSet becomes “available,” all Data Associations whose target is any of the Data Inputs of the InputSet are executed. These executions fill the Activity Data Inputs and the execution of the Activity can begin. When an Activity finishes execution, all Data Associations whose sources are any of the Data Outputs of the OutputSet are executed. These executions copy the values from the Data Outputs back to the container’s context (Data Object, Properties, etc.).

Execution Semantics for DataAssociation

The execution of any Data Associations MUST follow these semantics:

• If the Data Association specifies a “transformation” Expression, this expression is evaluated and the result is copied to the targetRef. This operation replaces completely the previous value of the targetRef element.
• For each “assignment” element specified:
• Evaluate the Assignment’s “from” expression and obtain the *source value*.
• Evaluate the Assignment’s “to” expression and obtain the *target element*. The *target element* can be any element in the context or a sub-element of it (e.g., a DataObject or a sub-element of it).
• Copy the *source value* to the *target element*.
• If no “transformation” Expression nor any “assignment” elements are defined in the Data Association:
• Copy the Data Association “sourceRef” value into the “targetRef.” Only one sourceRef element is allowed in this case.

Advanced

BPMN does not itself provide a built-in model for describing structure of data or an Expression language for querying that data. Instead it formalizes hooks that allow for externally defined data structures and Expression languages. In addition, BPMN allows for the co-existence of multiple data structure and Expression languages within the same model. The compatibility and verification of these languages is outside the scope of this International Standard and becomes the responsibility of the tool vendor.

This requirement is realized in BPMN through various constructs: Data Objects, ItemDefinition, Properties, Data Inputs, Data Outputs, Messages, Input Sets, Output Sets, and Data Associations.

Item-Aware Elements. Several elements in BPMN are subject to store or convey items during process execution. These elements are referenced generally as “item-aware elements.” This is similar to the variable construct common to many languages. As with variables, these elements have an ItemDefinition.

The data structure these elements hold is specified using an associated ItemDefinition. An ItemAwareElement MAY be underspecified, meaning that the structure attribute of its ItemDefinition is optional if the modeler does not wish to define the structure of the associated data.

The elements in the specification defined as item-aware elements are: Data Objects, Data Object References, Data Stores, Properties, DataInputs and DataOutputs.

Properties

Properties, like Data Objects, are item-aware elements. But, unlike Data Objects, they are not visually displayed on a Process diagram. Certain flow elements MAY contain properties, in particular only Processes, Activities, and Events MAY contain Properties.

The Property class is a DataElement element that acts as a container for data associated with flow elements. Property elements MUST be contained within a FlowElement. Property elements are not visually displayed on a Process diagram.

The lifecycle of a Property is tied to the lifecycle of its parent Flow Element. When a Flow Element is instantiated, all Properties contained by it are also instantiated. When a Flow Element instance is disposed, all Property instances contained by it are also disposed. At this point the data within these instances are no longer available.

The accessibility of a Property is driven by its lifecycle. The data within a Property can only be accessed when there is guaranteed to be a live Property instance present. As a result, a Property can only be accessed by its parent Process, Sub-Process, or Flow Element. In case the parent is a Process or Sub-Process, then a property can be accessed by the immediate children (including children elements) of that Process or Sub-Process. For example, consider the following structure: (draw a diagram using the example page 209.)

Data-aware elements

The ErrorEventDefinition, EscalationEventDefinition, and SignalEventDefinition subclasses comprise of attributes to carry data. The data is defined as part of the Events package. The MessageEventDefinition subclass comprises of an attribute that refers to a Message which is defined as part of the Collaboration package.

solocastellano