If intermediary events must be propagated to the BPEL process instance, select the Allow task and routing customization in BPEL callbacks check box in the Events section of the Human Task Editor. When this option is selected, the workflow service invokes callbacks in the BPEL instance during each update of the task. The callbacks are listed in the TaskService.wsdl file and described as follows:

• onTaskCompleted

  This callback is invoked when the task is completed, expired, withdrawn, or errored.

• onTaskAssigned

  This callback is invoked when the task is assigned to a new set of assignees due to the following actions:

  • Outcome update

  • Skip current assignment

  • Override routing slip

• onTaskUpdated

  This callback is invoked for any other update to the task that does not fall in the onTaskComplete or onTaskAssigned callback. This includes updates on tasks due to a request for information, a submittal of information, an escalation, a reassign, and so on.

• onSubTaskUpdated

  This callback is invoked for any update to a subtask.

Figure 28-14 shows how a workflow interaction with callbacks is modeled. After this task is initiated, a while loop is used to receive messages until the task is complete. The while loop contains a pick with four onMessage branches — one for each of the above-mentioned callback operations. The workflow interaction works fine even if nothing is changed in the onMessage branches, meaning that customizations in the onMessage branches are not required.

In this scenario, a workflow context is captured in the BPEL instance. This context can be used for all interaction with the workflow services. For example, to reassign a task if it is assigned to a group, then you need the workflow context for the reassignTask operation on the task service.

It is recommended that any user customizations be performed in the first assign, AssignTaskAttributes, and that AssignSystemTaskAttributes not be changed.