Siebel Business Process Framework: Task UI Guide > Task UI Concepts > Language Concepts for Task UI >

Subtasks

Using subtasks, you can make a task flow modular. If your task flow diagrams become so large that readability is compromised, use subtasks to break up the work. The primary reasons to use subtasks are the following:

• Task readability. Improve the use of space on the canvas by breaking large tasks into separate modules.
• Reuse. Decrease development and maintenance costs by reusing common Task UI sequences.
• Consistency of design. Maintain a clean, consistent, and intuitive programming model.

While subtasks correspond to tasks in the same way that subprocess steps correspond to workflows, the subtask programming model varies from that of workflow subprocesses. The major differences are the following:

• A subtask and its parent task share the same process instance. In Siebel Workflow, a main process and its subprocess run in separate instances.
• A subtask and its parent task should have the same business object type, and share the same business object instance. In Workflow, the main process and the subprocess can be of two different business object types, and can have two different business object instances.
• Both subtasks and workflow subprocesses support the notation of local process properties. Each workflow subprocess invocation creates a process instance and has its own process properties. Each subtask invocation does not create a new instance, but rather a new context is created for each invocation for storing local task properties. A subtask and its parent task do not share task properties.
• A subtask's boundaries are not visible to end users. This means that if end users click Previous this action might cross the subtask boundaries in either direction.

Other characteristics of subtasks that require special attention include the following:

• Event handlers can be defined only for the main task, and not the subtasks. If an event is triggered by a subtask, it is propagated back to the main task, and handled by the event handlers defined in the main task. The event handler runs under the context of the main task.
• A task must be explicitly defined as the main task or subtask at design time:
  • Each main task has a task state. The task state stores information essential to the task run-time instance. This information includes the current step pointer, task object Id, and the navigation path. Subtasks do not have individual task states, but they do have their own individual local task properties.
  • A subtask cannot be used as a main task.
  • The parent task and its subtask communicate through input and output argument passing.
• Subtasks can be nested (contain more subtasks).

For information on how to configure subtask steps when building task flows, see Configuring Subtask Steps.

Transient Business Component in a Subtask

A transient business component (TBC) can have only one record for each context. In Task UI, TBC context is at the level of the subtask, which means that even if a subtask uses the same TBC with its parent task, the two do not share the same TBC record. If there is no record for a TBC in the current context, a new record is created by the framework when the TBC is queried.