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

Transient Business Component

Transient business components (TBCs) provide a way to create task-specific data that can be displayed and edited in the user interface and accessed from within the task-flow logic.

TBCs are used to house data to control the flow or logic (but not stored in the database) and are cleared when a task is completed. They are created similarly to other business components in the repository except that they are based on the S_TU_LOG table and are of the type transient.

TBCs are used for data that is needed for the lifetime of the task, but can be discarded when the task is done. This might include intermediate calculations, end-user decisions made in the user interface, or other data needed during the task that need not be transferred to long-term storage in the database.

TBCs are also used for data that may be later incorporated into longer-term storage, but the initial views of which do not capture enough information to build a complete record. For example, the initial view of a task might ask for a customer's postal code. The postal code is used to make task-flow decisions and to query data. The postal code may also get included in transactional records generated by the task. Using a standard BC to enter the postal code would require entry of a complete record all at once. Using a TBC allows the postal code to be entered alone and written to a standard BC later in the flow.

About Transient Data

Transient data is data that is relevant within a limited time period. In Task UI, that time period is the duration of a task instance. A typical example of transient data is an end user's answers to questions such as "What would you like to do next?"

In Task UI, data that is transient — dynamic data — is tied to a special type of business component called a transient business component (TBC). The TBC is a business component for which the records span the lifetime of a task instance. The records of the TBC can be accessed only within the context of a particular task or subtask. A user property in the top-level Task object, Transient BC - Property, specifies the TBC used in the task to store temporary data that is only necessary throughout the life of the task.

The TBC is used to make sure that only one record exists for each context. Context may be the main task or a subtask. There can be only one TBC with only one record for each context.

NOTE:  Task properties also satisfy the definition of transient data above. The main difference between TBC data and task properties is that while TBC data can be directly presented in the UI, task properties cannot. This difference should be a primary factor when deciding whether to store transient data in a TBC or in a task property.

How Transient BCs Differ from Standard BCs

You distinguish between transient business components and standard (nontransient) business components using the Type property. A TBC's type is Transient, while the type of a standard business component is nontransient.

NOTE:  When a business component's type has been set to Transient or Nontransient, it cannot be changed, even through a copy operation.

A TBC uses either the CSSBCTaskTransient class, or a class derived from CSSBCTaskTransient. The CSSBCTaskTransient class enforces that there is only one row for each context for each TBC. In Task UI, TBC context is at the level of 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.

This specialized class also filters the single record for the current context and current business component. It executes a default query on the first Get/Set function, and creates a new record if no such record exists (Execute () returns no rows).

Further characteristics of TBCs are the following:

• A transient business component is always based on the S_TU_LOG table.
• Changes to transient business components are immediately committed.
• Transient business components do not allow multi-value fields.
• The Column and Join properties of a TBC are auto-populated and are not editable:
  • Explicit joins are not allowed within a TBC.
  • All columns are forced active at run time, to avoid field activation problems.
• LOV-bound data is stored using language-independent code, if the associated LOV type is marked Multilingual.

Managing Transient Data

Transient business components are deployed just like standard business components, through the repository (SRF).

NOTE:  Unlike tasks, TBCs are not deployed in the run-time deployment schema.

TBCs allow you to display transient data. TBC data can be manipulated both by the end user (through UI controls), as well as by business logic embedded in the task definition (through the business component update operation).

NOTE:  Insert, delete, and copy operations on TBCs are not supported.

TBC data can be referenced directly from a task, just as standard business component data can. For example, it can directly drive branching decisions, or it can be assigned to a step's input method arguments. If necessary, TBC data can even be assigned to task properties through a step's output argument assignments.

TBC data is stored in the S_TU_LOG table and, if necessary, in S_TU_LOG_X_* extension tables. The TASK_ID_VAL column stores the Task Instance ID, while the column BC_NAME stores the business component name. After use, the table is wiped clean by a background service, based on TASK_ID_VAL. If Task UI is running on a mobile client connected to a local database, TBC data is cleaned up as soon as the task finishes.

The primary uses of transient data include the following:

• Flow control through radio buttons (in the UI) and decision steps (in the task definition). The selection of the end user determines where the Task UI moves next.
• Control over search specifications. User input based on choices that include a pre-default, such as in response to the question, "In which month did your transaction take place?"
• Data manipulation:
  • Merging fields from different business components in a single applet, for example, to allow creating a new account and entry of contact data through a single task applet.
  • Splitting the entry of required fields across views. The record is not inserted into the business component until all field values are collected.
  • Polymorphic user interface. Based on a selection at run-time, UI controls map to different business component fields. For example, if the user chooses Credit Card as a payment method, then fields for credit card type, number, and expiration date are enabled at run-time.
  • Checking for the existence of a record before committing a new record that might be a duplicate.

Getting Data Out of a TBC

As with standard business components, TBC data can be assigned to task properties and also mapped to other business component fields.

Updating Data in a TBC

Transferring data between business components happens in the same way, regardless of whether one is a TBC. You can transfer data between business components of either type, transient or nontransient.

To transfer data from a transient business component to a task property

1. While positioned on a step after which the assignment should happen (typically, this might be a task view step that allows the end user to manipulate TBC data):
   1. Assign a TBC field to a task property in the Output Arguments tab of the Multi Value Property Window.
   2. For the assignment type, use Business Component.

To transfer data between a transient business component and another business component

1. Use the Siebel operation of type Update to update the target business component.
2. In the Fields tab of the Multi Value Property Window, specify the Business Component type.
3. Pick BC and BC Field properties to select the source.