La Tarea de Recepción espera la llegada de un Mensaje desde otro Participante. Una vez que ha recibido el Mensaje, la Tarea termina.
La Tarea de Envío entrega un Mensaje a otro Participante. Una vez que ha enviado el Mensaje, la Tarea termina.
Ejemplo: proceso sencillo. Explicación del ejemplo.
Ejemplo con Tareas de Recepción.
Una Tarea de Recepción espera la llegada de un Mensaje desde otro Participante. Una vez que se recibido el Mensaje, la Tarea termina.
Como las demás Actividades, se representa con un rectángulo con esquinas redondeadas, dibujado con una línea delgada.
Una Tarea de Envío tiene la figura de un sobre de carta en la esquina superior izquierda.
Ejemplo más elaborado. Explicación del ejemplo.
Imagen ejemplo con Tareas de Recepción.
Ejemplo más elaborado. Explicación del ejemplo.
Video ejemplo con Tareas de Recepción.
Tarea de Envío de Mensaje
|
Una Tarea de Envío envía un Mensaje a otro Participante. Una vez que ha enviado el Mensaje, la Tarea termina. Como las demás Actividades, se representa con un rectángulo con esquinas redondeadas, dibujado con una línea delgada. Una Tarea de Envío tiene la figura de un sobre carta oscurecido en la esquina superior izquierda. |
|
Ejemplo más elaborado. Explicación del ejemplo.
Imagen ejemplo con Tareas de Envío.
Ejemplo más elaborado. Explicación del ejemplo.
Video ejemplo con Tareas de Envío.
Marcas
Como las demás Tareas, una Tarea de Recepción puede ser repetitiva: Estándar a Multi-Instancia. (Ver Actividades-Iteración.)
Ejemplo con Tareas de Recepción.
Como las demás Tareas, una Tarea de Recepción puede ser usada para Compensación. (Ver Compensación.)
Ejemplo con Tareas de Recepción.
Una Tarea de Recepción no puede ser una Tarea Global. (Ver Tarea Global - Reutilizable.)
Como las demás Tareas, una Tarea de Envío puede ser repetitiva: Estándar a Multi-Instancia. (Ver Actividades-Iteración.)
Ejemplo con Tareas de Envío.
Como las demás Tareas, una Tarea de Envío puede ser usada para Compensación. (Ver Compensación.)
Ejemplo con Tareas de Envío.
Una Tarea de Envío no puede ser una Tarea Global. (Ver Tarea Global - Reutilizable.)
Conexión a Flujos de Mensaje
Una Tarea de Recepción tiene cero, uno o varios Flujos de Mensaje entrantes.
Normalmente, sólo tiene un Flujo de Mensaje entrante o ninguno.
Si no tiene Flujo de Mensaje entrante, puede significar:
- El Participante es conocido, pero su Piscina no es mostrada en el diagrama.
- El Participante puede ser cualquiera que pueda enviar el Mensaje adecuado.
Si tiene varios Flujos de Mensaje entrantes, todos deben transpotar los mismos datos. Sin embargo, para cada instancia de la Tarea, el Mensaje sólo puede llegar desde uno de los Flujos de Mensaje.
Una Tarea de Envío tiene cero, uno o varios Flujos de Mensaje salientes.
Normalmente, sólo tiene un Flujo de Mensaje saliente o ninguno.
Si no tiene Flujo de Mensaje saliente, puede significar:
- El Participante es conocido, pero su Piscina no es mostrada en el diagrama.
- El Participante puede ser cualquiera que pueda recibir el Mensaje enviado.
Si tiene varios Flujos de Mensaje salientes, todos deben transportar los mismos datos. La Tarea envía una copia del Mensaje por cada uno de los Flujos de Mensaje salientes.
¿Cómo funciona?
Texto explicando los dos enfoques y con referencias a otras páginas.
Texto explicando los dos enfoques y con referencias a otras páginas.
Modelado de Procesos
Semántica de ejecución en Modelado de Procesos.
Ejecución y finalización.
- Tras la activación, ...
- Una vez realizado el trabajo, la Tarea TIPO finaliza.
Video que muestra el detalle de la ejecución de la Tarea en Modelado de Procesos.
Nombre de Video.
Ejecución de Procesos
El Participante que recibe el Mensaje se puede conectar a la Tarea de Envío mediante un Flujo de Mensaje.
La Tarea de Envío tiene un Objeto de Datos entrante que contiene los datos para crear el Mensaje de salida. De este modo, el Proceso traspasa sus datos internos a otros Procesos.
Tras la activación, el contenido del Objeto de Datos entrante es traspasado al Mensaje, se envía el Mensaje, y la Tarea es completada.
Video que muestra el detalle de la ejecución de la Tarea.
Nombre de Video.
El Participante que envía el Mensaje se puede conectar a la Tarea de Recepción mediante un Flujo de Mensaje.
Los datos trasportados por el Flujo de Mensaje llegan a la Tarea de Recepción y son traspasados al Objeto de Datos saliente. De este modo, los datos entran al Proceso. Si no exise este Objeto de Datos, los datos del Flujo de Mensaje no entran al Proceso.
Tras la activación, la Tarea de Recepción queda a la espera del Mensaje. Cuando éste llega, sus datos son traspasados al Objeto de Datos saliente, y la Tarea es completada.
Video que muestra el detalle de la ejecución de la Tarea.
Nombre de Video.
Configuraciones
Ejemplo 1.
Ejemplo con Tareas de Recepción.
Ejemplo 2.
Ejemplo con Tareas de Recepción.
Tarea de Recepción vs Evento Mensaje
Puede usarse de manera indistinta.
Buena práctica: usar siempre tareas o eventos, pero no mezclarlos.
Se puede usar una Tarea de Recepción para iniciar un Proceso (hacer referencia a "Comenzar un Proceso").
Ejemplo.
Ejemplo con Tareas de Recepción.
Temas Avanzados
Tecnología para recibir el Mensaje.
Si la Tarea está automatizada, la tecnología por defecto es Web Service.
Temporal
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Texto.Texto.
Especificación BPMN
Receive Task
A Receive Task is a simple Task that is designed to wait for a Message to arrive from an external Participant (relative to the Process). Once the Message has been received, the Task is completed.
A Receive Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is an unfilled envelope marker (the same marker as a catch Message Event) in the upper left corner of the shape that indicates that the Task is a Receive Task.
A Receive Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes an unfilled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.15).
The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flows within the definitional Collaboration of the Process – see Table 10.1. One (1) or more corresponding incoming Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all incoming Message Flows, but can arrive for only one (1) of the incoming Message Flows for a single instance of the Task.
The actual Participant from which the Message is received can be identified by connecting the Receive Task to a Participant using a Message Flow. However, the display of the Message Flows is NOT REQUIRED.
The Receive Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints apply when the Receive Task references a Message: The Receive Task has at most one outputSet and at most one Data output. If the Data output is present, it MUST have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Receive Task is executed, the data automatically moves from the Message to the Data Output on the Receive Task. If the Data Output is not present, the payload within the Message will not flow out of the Receive Task and into the Process.
Task execution and completion. Upon activation, the Receive Task begins waiting for the associated Message. When the Message arrives, the data in the Data Output of the Receive Task is assigned from the data in the Message, and Receive Task completes.
Attribute messageRef. A Message for the messageRef attribute MAY be entered. This indicates that the Message will be received by the Task. The Message in this context is equivalent to an in-only message pattern (Web service).
Attribute operationRef. This attribute specifies the operation through which the Receive Task receives the Message.
Attribute implementation. This attribute specifies the technology that will be used to send and receive the Messages. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol A Web service is the default technology.
See page 449. The task doesn't need to know the participant that the receive task is connected to: "The partner link associated with the WS-BPEL receive is derived from the interface referenced by the operation of the Receive Task.
Send Task
A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the Task is completed.
A Send Task object shares the same shape as the Task, which is a rectangle that has rounded corners. However, there is a filled envelope marker (the same marker as a throw Message Event) in the upper left corner of the shape that indicates that the Task is a Send Task.
A Send Task is a rounded corner rectangle that MUST be drawn with a single thin line and includes a filled envelope marker that distinguishes the shape from other Task types (as shown in Figure 10.13).
The actual Participant which the Message is sent can be identified by connecting the Send Task to a Participant using a Message Flows within the definitional Collaboration of the Process (see Table 10.1). One or more corresponding outgoing Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all outgoing Message Flows and the Message will be sent down all outgoing Message Flows at the completion of a single instance of the Task.
The actual Participant which the Message is sent can be identified by connecting the Send Task to a Participant using a Message Flows. However, the display of the Message Flows is NOT REQUIRED.
The Send Task inherits the attributes and model associations of Activity (see Table 10.3). In addition the following constraints apply when the Send Task references a Message: The Send Task has at most one inputSet and one Data Input. If the Data Input is present, it MUST have an ItemDefinition equivalent to the one defined by the associated Message. At execution time, when the Send Task is executed, the data automatically moves from the Data Input on the Send Task into the Message to be sent. If the Data Input is not present, the Message will not be populated with data from the Process.
Task execution and completion. Upon activation, the data in the associated Message is assigned from the data in the Data Input of the Send Task. The Message is sent and the Send Task completes.
See page 449. The task knows the participant it is connected to: "The partner link associated with the WS-BPEL invoke is derived from both the participant Q that the Send Task is connected to by a Message Flow, and from the interface referenced by the operation of the Send Task."
Attribute operationRef: This attribute specifies the operation that is invoked by the Send Task.
Attribute implementation. This attribute specifies the technology that will be used to send and receive the Messages. Valid values are "##unspecified" for leaving the implementation technology open, "##WebService" for the Web service technology or a URI identifying any other technology or coordination protocol A Web service is the default technology.
Attribute messageRef. A Message for the messageRef attribute MAY be entered. This indicates that the Message will be sent by the Task. The Message in this context is equivalent to an out-only message pattern (Web service). One or more corresponding outgoing Message Flows MAY be shown on the diagram. However, the display of the Message Flows is NOT REQUIRED. The Message is applied to all outgoing Message Flows and the Message will be sent down all outgoing Message Flows at the completion of a single instance of the Task.
