Siebel Business Process Framework: Task UI Guide > Reference Materials for Siebel Task UI >

About Task Transaction

This topic describes some of the features of task transaction.

Task transaction is a feature that allows you to keep data for a task instance separate from the base tables until Siebel CRM explicitly saves the task data to the Siebel database. Task transaction allows data in a task instance to last for an arbitrarily long amount of time while maintaining reliability, performance, and scalability. Task transaction includes the following features:

• Task transaction data can persist only for a moment or it can last for days or months.
• Task transaction data can span multiple user sessions, process boundaries, and database or application server restarts.
• A task transaction that persists for a long time is usually an inbox record.
• Task transaction is dependent on a feature that resides on the Siebel Server that is external to the underlying Relational Database Management System (RDBMS).
• The Cancel operation stops a task transaction and rolls back the changes that Siebel CRM saved before cancellation.
• You can turn task transaction off at the business component level and at the task UI level. For more information, see Disabling Task Transactions.

For more information, see Configuring How Siebel CRM Resolves Task Transaction Conflicts.

Atomicity

Siebel CRM can save as a group the operations that it performs in a task UI or it can stop them. Atomicity is traditionally achieved using a transactional feature that is embedded in the RDBMS. However, that feature is not appropriate for a task transaction because it is limited to a single database connection that can result in the following problems:

• Limits the duration of the transaction
• Jeopardizes reliability of the Siebel system, performance, and scalability

Isolation

A change that a user makes in a task transaction is visible only in that task transaction until Siebel CRM saves it. For example, an insert, update, or delete operation can perform a save operation. If Siebel CRM saves a change that is outside of the task transaction, then this change is visible in the task transaction as soon as Siebel CRM queries the changed record again.

Transparent Storage

To store data changes in the task transaction, Siebel CRM dedicates a set of generic tables. It maps columns in the generic tables to columns in the Siebel database tables. This configuration hides the complexity of the storage details from the person who develops the task UI. However, you must configure Siebel CRM to clean up storage of a task transaction after it saves and ends that transaction. For more information, see Removing Temporary Data After a Task UI Finishes.

Transparent Data Retrieval

Siebel CRM merges the data that resides in task transaction storage with the data in Siebel database tables, and with complete support for data filtering. A search specification is an example of data filtering. Siebel CRM supports declarative data ordering only for a hierarchical business component. A sort specification is an example of declarative data ordering. For other configurations, ordering works as expected only when no data changes in the task transaction.

Sharable Temporary Data

The Object Manager stores the data that the user creates or modifies during a task instance. It stores this data in temporary storage in a special database table but does not save it to the base tables until the user finishes the task or reaches a commit step. Sharable temporary data can include temporary data that spans multiple server components. A thread that is separate from the initiating application can pass the task instance ID to another server component, and then return the information from that other server component back to the task.

Siebel CRM starts and shares temporary storage in the following way:

1. If the Server Request Broker detects that the current Object Manager is running a task transaction, then it passes the task transaction ID to the server component that Siebel CRM called.
2. If the Object Manager in the server component detects the task transaction ID, then the Object Manager uses this ID to start the same task transaction. As a result, the session for the Object Manager gains access to the data in this task transaction. The Object Manager ends the task transaction before the server component thread ends.
3. To handle the concurrency issue in the server component, the task controller uses a locking feature. It makes sure that no more than one transaction for each task UI is active at a time, regardless of how many threads Siebel CRM runs in the server component.

This solution can handle multiple calls. For example, if a task UI calls a server component, which in turn calls another server component, then these server components possess access to the task transaction.

Example with Assignment Manager

Assume a task UI must schedule a job. To schedule this job, this task UI must evaluate the skills and availability that an individual possesses. The following work occurs:

1. To handle a service request while on a phone call with a customer, a call center representative runs a task UI.
2. Siebel CRM passes the task instance ID of the task that the user runs to the Assignment Manager server component.
3. The Assignment Manager server component determines the availability of an appropriate field service engineer.
4. The Assignment Manager server component returns this information to the task that the call center representative is running.

How Siebel CRM Shares Temporary Storage

Siebel CRM disables sharing of temporary storage by default. To make this sharing available, you must define the TASKTEMPSTORAGESHARING task property with a data type of String. If you do not define this property, then Siebel CRM displays an error that indicates that it cannot access temporary storage.

NOTE:  An asynchronous call to the Server Request Manager cannot access temporary storage data even if sharing of temporary storage data is available.

Task Transaction and Task Instance

If the user or if a long-running workflow process starts a particular kind of task UI, then Siebel CRM creates a new task instance. The relationship between a task instance and a task UI is similar to the relationship between an object and a class in an object oriented programming language. Each task instance includes a state that consists of task properties and navigation history. Data in the business object that the task references is usually shared, except for the data in a transient business component, which is unique to a specific task instance. For more information, see Overview of Transient Data.

The duration of a task instance can coincide with the duration of the task transaction. However, the task instance might not use a task transaction, or it might use a series of task transactions through the use of intermediate commit steps.

A paused task UI is a task instance that Siebel CRM stores and that the user can resume from the inbox.