Expand the Variables tree shown in

Designing Human Tasks 27-87

27.4.5 How to View the Generated Human Task Activity

When you have completed modeling the human task activity, the human task is generated in the designer. Figure 27–77 shows how a workflow interaction is modeled. Figure 27–77 also illustrates the interaction when no BPEL callbacks are modeled. In this case, after a task is complete, the BPEL process is called back with the completed task. No intermediary events are propagated to the BPEL process instance. It is recommended that any user customizations be done in the first assign, AssignTaskAttributes, and that AssignSystemTaskAttributes not be changed. Figure 27–77 Workflow Interaction Modeling Click the Expand icon next to the human task activity in Oracle BPEL Designer to display its contents, as shown in Figure 27–78 . Figure 27–78 Expanding the Human Task Activity

27.4.5.1 Invoking BPEL Callbacks

If intermediary events must be propagated to the BPEL process instance, select the Allow task and routing customization in BPEL callbacks checkbox 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 AssignTaskAttributes Captures the user-defined attributes of the task such as title, payload, creator, priority, and so on InitiateTask Initiates the task by invoking the task service ReceiveCompletedTask Receives the completed task from the task service AssignSystemTaskAttributes Captures the system task attributes such as process id, process version, and so on 27-88 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite 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 27–79 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.