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
Comienzo Proceso Principal.
Explicación de inicio de proceso con un Evento Incial distinto de Vacío en diagrama con sólo una Piscina. Cada ocurrencia del Evento Inicial crea una nueva Instancia de Proceso.
Buena práctica que sea distinto de vacío en el Proceso central de una Colaboración, lo demás procesos (posiblemente Públicos) pueden tener inicio Vacío.
Comienzo Subproceso Embebido.
Un Evento Inicial Vacío. Excepto cuando es "caja paralela".
Comienzo Subproceso Reutilizable.
Si es un Proceso que sólo será usado desde llamadas, entonces sólo debe tener un Evento Inicial Vacío.
Si va a ser usado directamente y llamado desde otros Procesos, debe tener un Evento Inicial Vacío y otro no Vacío.
Si se llama a un Proceso global a través de una Actividad de Llamada, entonces la Actividad de Llamada tiene la misma semántica de instanciación y terminación que un Subproceso embebido. Sin embargo, el Proceso Global llamado puede tener también Eventos Iniciales no Vacíos, los que son ignorados cuando se llama al Proceso desde otro Proceso.
Comienzos Complejos.
Varios Eventos Iniciales.
Se crea una instancia del Proceso cuando ocurre uno de sus Eventos Iniciales. Cada Evento Inicial gatillado crea un Token.
Explicar que cuando hay más de un Evento Inicial, en la práctica hay más de un Proceso en la misma Piscina. Una opción es separar los Procesos, pueden ser "subprocesos". Mostrar el ejemplo del curso.
El comportamiento de Proceso puede ser más difícil de entender si hay varios Eventos de inicio. Se recomienda usar esta funcionalidad con moderación. El modelador debe tener en cuenta que los lectores del Diagrama podrían tener dificultades para comprender la intención del Diagrama.
Eventos Iniciales.
Evento Inicial Múltiple: significa que existen múltiples Eventos que pueden instanciar el Proceso (Mensaje, Timer, Condicional y/o Señal), pero sólo uno de ellos es suficiente. Si vuelve a ocurrir uno de los Eventos se crea una nueva instancia. Equivale a un XOR.
Evento Inicial Múltiple Paralelo: significa que existen múltiples Eventos que que deben ocurrir para instanciar el Proceso (Mensaje, Timer, Condicional y/o Señal). Equivale a un AND.
Compuertas Iniciales.
Hacer referencia a página de Compuerta Exclusiva Eventos.
Tarea de Recepción.
Cuando un Proceso comienza con la recepción de un Mensaje, normalmente se usa un Evento Inicial de tipo Mensaje. Alternativamente, se puede usar una variante de Tarea de Recepción, la que difiere de normal en dos aspectos:
- El Marcador en su esquina superior izquierda el un Evento Inicial de tipo Mensaje.
- No tiene Flujos de Secuencia entrantes.
Subproceso Embebido.
Si el Subproceso no tiene Flujos de Secuencia entrantes sino Eventos Iniciales a los que llegan Flujos de Secuencia desde fuera del Subproceso, el Subproceso se instancia cuando un Token alcanza uno de estos Eventos Iniciales. Estos Eventos Iniciales son alternativos, es decir, cada Token que llega genera una nueva instancia. (Cuando el Subproceso está expandido es posible colocar Eventos Inciales en el borde, al que llegan directamente Flujos de Secuencia desde el Proceso contenedor.)
Subproceso Reutilizable.
Si el Proceso Principal, actuando como Proceso Global, tiene varios Eventos Iniciales Vacíos, entonces cuando el Flujo se transfiere al Proceso Global (vía la Actividad de Llamada), sólo uno de los Eventos Inciales Vacíos se activará. Para ello, en la Actividad de Llamada se debe debe identificar el Evento Inicial Vacío que se activará.
Tocar el tema de los Data Input y Output
En una típica interacción entre un comprador y un vendedor, primero el vendedor intenta convercer al comprador, después éste decide si compra o no. ¿Dónde comienza el Proceso?, ¿en la conversación previa o en la venta en sí? La respuesta no es única, pues depende de la relevancia que la organización le otorga a la "conversación previa". Si ésta está sujeta a políticas concretas y se ajusta a determinadas pautas, entonces será la primera fase del Proceso y comenzará con el Evento Inicial Mensaje donde el cliente comunica su intención de comprar. Si, por otro lado, la "conversación previa" es informal y no interesa recopilar datos sobre ventas no realizadas, entonces el Proceso comienza con el Evento Inicial Mensaje donde el cliente comunica su decisión de comprar.
FIGURAS: Inicio de Proceso en las dos versiones.
Especificación BPMN
A Process can also be started via an Event-Based Gateway, as in the following example (Figure 10.98). In that case, the first matching Event will create a new instance of the Process, and waiting for the other Events originating from the same decision stops, following the usual semantics of the Event-Based Exclusive Gateway. Note that this is the only scenario where a Gateway can exist without an incoming Sequence Flows.
It is possible to have multiple groups of Event-Based Gateways starting a Process, provided they participate in the same Conversation and hence share the same correlation information. In that case, one Event out of each group needs to arrive; the first one creates a new Process instance, while the subsequent ones are routed to the existing instance, which is identified through its correlation information.
If the Event Gateway’s instantiate attribute is set to true and the eventGatewayType attribute is set to Parallel, then the marker for the Event Gateway looks like a Parallel Multiple Start Event (see Figure 10.119).
The Event Gateway’s instantiate attribute MUST be set to true in order for the eventGatewayType attribute to be set to Parallel (i.e., for Event Gateway’s that do not instantiate the Process MUST be Exclusive—a standard Parallel Gateway can be used to include parallel Events in the middle of a Process).
When used at the Process start as a Parallel Event Gateway, only message-based triggers are allowed (p.437). The Message triggers that are part of the Gateway configuration MUST be part of a Conversation with the same correlation information. After the first trigger instantiates the Process, the remaining Message triggers will be a part of the Process instance that is already active (rather than creating new Process instances).
There are variations of the Event Gateway that can be used at the start of the Process. The behavior and marker of the Gateway will change.
Event Gateways can be used to instantiate a Process. By default the Gateway’s instantiate attribute is false, but if set to true, then the Process is instantiated when the first Event of the Gateway’s configuration is triggered.
If the Event Gateway’s instantiate attribute is set to true, then the marker for the Event Gateway looks like a Multiple Start Event (see Figure 10.118).
In order for an Event Gateway to instantiate a Process, it MUST not have any incoming Sequence Flows.
In some situations a modeler might want the Process to be instantiated by one of a set of Messages while still requiring all of the Messages for the working of the same Process instance. To handle this, there is another variation of the Event Gateway.
The Parallel Event Gateway is also a type of race condition. In this case, however, when the first Event is triggered and the Process is instantiated, the other Events of the Gateway configuration are not disabled. The other Events are still waiting and are expected to be triggered before the Process can (normally) complete. In this case, the Messages that trigger the Events of the Gateway configuration MUST share the same correlation information.
Attribute instantiate. When true, receipt of one of the Events will instantiate the Process instance.
Attribute eventGatewayType. The eventGatewayType determines the behavior of the Gateway when used to instantiate a Process (as described above). The attribute can only be set to parallel when the instantiate attribute is set to true.
Event-Based Gateways can be used at the start of a Process, without having to be a target of Sequence Flows. There can be multiple such Event-Based Gateways at the start of a Process. Ordinary Start Events and Event-Based Gateways can be used together.
If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.
A Process is instantiated when one of its Start Events occurs. Each occurrence of a Start Event creates a new Process Instance unless the Start Event participates in a Conversation that includes other Start Events. In that case, a new Process instance is only created if none already exists for the specific Conversation (identified through its associated correlation information) of the Event occurrence. Subsequent Start Events that share the same correlation information as a Start Event that created a Process instance are routed to that Process instance. Note that a global Process MUST neither have any empty Start Event nor any Gateway or Activity without incoming Sequence Flows. An exception is the Event Gateway.
A Process can also be started via an Event-Based Gateway or a Receive Task that has no incoming Sequence Flows and its instantiate flag set to true. If the Event-Based Gateway is exclusive, the first matching Event will create a new instance of the Process. The Process then does not wait for the other Events originating from the same Event-Based Gateway (see also semantics of the Event-Based Exclusive Gateway on page 437). If the Event-Based Gateway is parallel, also the first matching Event creates a new Process instance. However, the Process then waits for the other Events to arrive. As stated above, those Events MUST have the same correlation information as the Event that arrived first. A Process instance completes only if all Events that succeed a Parallel Event-Based Gateway have occurred.
To specify that the instantiation of a Process waits for multiple Start Events to happen, a Multiple Parallel Start Event can be used.
If the Process is used as a global Process (a callable Process that can be invoked from Call Activities of other Processes) and there are multiple None Start Events, then when flow is transferred from the parent Process to the global Process, only one of the global Process’s Start Events will be triggered. The targetRef attribute of a Sequence Flow incoming to the Call Activity object can be extended to identify the appropriate Start Event.
NOTE: The behavior of Process can be harder to understand if there are multiple Start Events. It is RECOMMENDED that this feature be used sparingly and that the modeler be aware that other readers of the Diagram could have difficulty understanding the intent of the Diagram.
Each Start Event that occurs creates a token on its outgoing Sequence Flows, which is followed as described by the semantics of the other Process elements.
A Receive Task is often used to start a Process. In a sense, the Process is bootstrapped by the receipt of the Message. In order for the Receive Task to instantiate the Process its instantiate attribute MUST be set to true and it MUST NOT have any incoming Sequence Flow. If the instantiate attribute is set to true, the envelope marker looks like a Message Start Event (as shown in Figure 10.16).
If the Receive Task’s instantiate attribute is set to true, the Receive Task itself can start a new Process instance.
Attribute instantiate. Receive Tasks can be defined as the instantiation mechanism for the Process with the instantiate attribute. This attribute MAY be set to true if the Task is the first Activity (i.e., there are no incoming Sequence Flows). Multiple Tasks MAY have this attribute set to true.
If the Sub-Process does not have incoming Sequence Flows but Start Events that are target of Sequence Flows from outside the Sub-Process, the Sub-Process is instantiated when one of these Start Events is reached by a token. Multiple such Start Events are alternative, i.e., each such Start Event that is reached by a token generates a new instance.
