Siebel Business Process Framework: Task UI Guide > Task UI Concepts > UI Elements Used in Task UI >

Task Playbar

The task playbar is an applet containing buttons that allow the end user to control the execution of the task.

The Task UI framework provides a standard playbar applet (shown in Figure 8) with buttons for forward and backward navigation, as well as for pausing and canceling the task. The standard playbar applet satisfies the majority of business requirements, but the framework also provides the ability to modify the look and behavior of the task playbar by using a custom playbar applet.

Figure 8. Standard Task Playbar

The task playbar should be positioned at the top right of the view on task views that don't require vertical scrolling. When vertical scrolling is required, the Playbar applet should be positioned at both the top and the bottom right of the view.

The following topics describe behavior of the buttons on the standard task playbar:

• Navigating Forward
• Navigating Backward
• Pausing the Task
• Cancelling the Task

For more information on how to use task playbar applets in your implementation using mobile clients, see About Task Playbar Applets.

Navigating Forward

When an end user clicks the forward navigation button (labeled Next in Figure 8), the Task UI framework first validates the data in the current view.

If there is a validation error, a pop-up error message is displayed, forward navigation is aborted, and the user is given the opportunity to fix the data.

If data in the current view is successfully validated, then the Task UI framework follows the task flow, executing all task steps until the next view step, or end step, whichever comes first. If any of the steps throws an exception not handled by the task flow, then the Task UI framework aborts forward navigation, pops up the error message, and returns control to the end-user in the same view at which forward navigation had been initiated. If the task's forward execution successfully arrived to the next task view step, the task context associated with that step is applied to the specified business components, and the associated view is presented to the end user.

The button for forward navigation can be labeled either Next, Submit, or Finish; and is controlled by the task developer using the Forward Button Type task step property. The label itself doesn't change the behavior of the framework, but is a hint intended to give the end user an idea of what happens when the forward navigation button is clicked:

• Submit indicates that task's data transaction is about to be committed to permanent storage for enterprise-wide consumption, and when committed, can not be rolled back. This typically occurs at the end of the task. However, for tasks that use intermediate commit points (using the Commit step), the Submit button should appear in the last task view before the commit step.
• Finish indicates that clicking the forward navigation button ends the task. It should be used only in tasks where task transaction is fully committed before the last view, which then typically serves as a summary view. This also applies to tasks that don't use the transaction mechanism, and instead directly work with permanent storage.
• Next is used in all other cases.

Navigating Backward

Clicking the backward navigation button (labeled Previous in the standard playbar applet, see Figure 8) causes Task UI framework to first validate data in the current view, and then display the last displayed view. This feature is most useful in the case where the end user makes a mistake (for example, entering erroneous data, or choosing the wrong option) during task execution, and needs to go back to fix it.

NOTE:  The fix can often cause subsequent forward navigation to enter a different branch in the task flow.

Validation is done similarly to forward navigation. The exception being that records in the current view that have been created within task transaction with deferred validation option (through insert step with Defer Write Record property set to TRUE), are not validated. Consequently, data inserted in the task transaction, which has not been validated before the commit step, is not committed to permanent storage.

NOTE:  Data in transient business components is validated because it is not part of the task transaction.

Before presenting the previous view, the Task UI framework attempts to reconstruct that view by applying the original search and sort specifications. It also attempts to reinstate the original current record. However, no reinstatement of original values is performed. The view presents the latest data within the transaction, so if the data presented on the view has later been changed, those changes are seen when navigating back to the target view.

Backward navigation can be continued until the first view in the task, and can freely cross subtask boundaries. At the first view shown in the task, the backward navigation button is disabled.

Backward navigation can be prevented by setting the Disable Previous task view step property to TRUE. This feature is useful for situations like a summary page where the task transaction has already been committed to permanent storage, and perhaps a business process has been initiated to start processing the transaction, so going back to change the transaction is no longer possible.

Pausing the Task

Clicking the Pause button in the task playbar applet causes the current task to be paused. This means that the Task UI framework first performs validation of the current view in the same way as in backward navigation. If validation succeeds, the framework executes the pause event handler if one is defined for current task.

Only if the event handling succeeds does the framework continue to persist to database the current state of both the task (including current view, navigation history, and local data), and its transaction. The end user is shown the ad-hoc view from which the current task was invoked. The Inbox item associated with the paused task instance is set to a paused state, which allows the end user to resume the paused task either from the Universal Inbox, or (if the task instance has been associated with any business objects) from an ad-hoc view that shows tasks associated with those business objects.

The Pause button on the playbar can be disabled by setting the Disable Pause task step property to TRUE. However, note that the task is implicitly paused when the user tries to navigate the Web browser outside of the current task (for example, by clicking on a site map, or a screen tab). The task is also implicitly paused if the user's session times out. Disabling the pause button does not prevent implicit pause, but it can be used to give a hint to end user that pausing is not recommended (for example, in the summary view).

Cancelling the Task

Clicking the cancel button in a playbar applet causes the current task to be cancelled. The impact of this action depends on the state of the task. If the task has never been paused, then cancelling it leaves no trace of it (except for the task timestamp metrics). On the other hand, if the task has been paused at least once, then cancelling it resets its state to the last paused state. The task's transaction is also rolled back. If there were any intermediate commits since the last pause, then the transaction is rolled back to the state at the last intermediate commit. Otherwise, the transaction is rolled back to the state saved during the last pause of this task instance.