Databases Reference
In-Depth Information
This will cause a business event to be sent whenever the task is assigned to another
participant. The business event contains details of the task object, as well as a set of
properties that are populated, based on the context of the fired event.
We can now write a simple BPEL process to subscribe to this event, which, on
receipt of the event, can generate the required notification and send it using the
User Notification
service.
The other approach is to use the
OrderFulfillment
process to generate the
notification. By default, the BPEL process will only receive a callback from the
workflow service upon completion of the task.
However, if we go back to the
Events
tab and select the checkbox
Allow task and
routing customizations in BPEL callbacks
(circled in the preceding screenshot), this
will modify our BPEL process to receive callbacks when either a task is assigned,
updated, or completed, as well as when a subtask is updated.
It does this by replacing the
Receive
activity, which receives the completed task
callback with a
Pick
activity embedded within a
While
activity that essentially
loops until the task is completed, as illustrated in the following diagram:
As you can see, the
Pick
activity contains an
onMessage
branch for each potential
callback. You then just add any additional processing that is required to the
appropriate
onMessage
branch.
In our case, we might add a switch to the
Task is assigned
branch to check where we
are in the workflow and then based on that generate the appropriate notification.