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 configure Siebel CRM to keep data for a task instance separate from the base tables until it 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.
• A task transaction that persists for a long time is typically an inbox record.
• Task transaction data can span multiple user sessions, process boundaries, and database or application server restarts.
• The Cancel operation stops a task transaction and rolls back the modifications 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.
• Task transaction is dependent on a feature that resides on the Siebel Server that is external to the underlying Relational Database Management System (RDBMS).

For more information, see Configuring Siebel CRM to Resolve 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, this 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 modification that a user makes in a task transaction is visible only in this 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 modification that resides outside of the task transaction, then this modification is visible in the task transaction as soon as Siebel CRM queries the modified record again.

Transparent Storage

Siebel CRM dedicates a set of generic tables to store data modifications in the task transaction. 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 this 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 that resides in the 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 Siebel CRM does not modify data that resides 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 this 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. The task controller uses a locking feature to handle the concurrency issue in the server component. 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 server calls. For example, if a task UI calls a server component, and this server component then calls another server component, then these server components possess access to the same task transaction.

Example with Assignment Manager

Assume that a task UI must schedule a job. It does the following work to evaluate the skills and availability that an individual possesses, and then to assign and schedule the job:

1. A call center representative runs a task UI To handle a service request while on a phone call with a customer.
2. Siebel CRM passes the task instance ID of the task UI that the user runs to the Assignment Manager server component.
3. The Assignment Manager server component determines if a field service engineer is available.
4. The Assignment Manager server component returns this information to the task UI 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.

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 task UI, then Siebel CRM creates a new task instance. The relationship that exists between a task instance and a task UI is similar to the relationship that exists 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. Siebel CRM typically shares data that resides in the business object that the task references, except for data that resides 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.