Bookshelf Home | Contents | Index | PDF | ![]() ![]() |
Siebel Business Process Framework: Task UI Guide > Reference Materials for Siebel Task UI > About Task TransactionThis 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:
For more information, see Configuring Siebel CRM to Resolve Task Transaction Conflicts. AtomicitySiebel 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:
IsolationA 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 StorageSiebel 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 RetrievalSiebel 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 DataThe 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:
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 ManagerAssume 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:
How Siebel CRM Shares Temporary StorageSiebel 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 InstanceIf 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. |
![]() ![]() |
Siebel Business Process Framework: Task UI Guide | Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |