12Reference Materials for Siebel Task UI

Reference Materials for Siebel Task UI

This chapter describes reference information for Siebel Task UI. It includes the following topics:

• Business Component Fields That a Task UI Can Modify

• About Task Transaction

• About Event Handling

• About Event Logging

• About Task Metrics

Business Component Fields That a Task UI Can Modify

A task UI cannot modify the following types of business component fields:

• Fields that use a multivalue group

• Calculated fields

A task UI can do the following for a field that Siebel CRM defines as read-only at the business component level:

• Use another field or a user property to read it.

• Cannot modify it.

Updating a Field That Uses a Multi Value Group

To update a field that uses a multivalue group, you can define a business component for this field, and then use Siebel Tools to link the business component to the object. For example, the Account Team field uses a multivalue group, so you cannot use the Account business component to update it. You can create a business component named Account Team and then use Oracle’s Siebel Tools to reference it to the Account business object. You can then use a Siebel operation step to update the Account Team business component. For more information, see Configuring Siebel Business Applications.

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.

About Event Handling

A task event is a type of event that allows you to define the processing that Siebel CRM does when an operation in a task UI calls an event. The following operations support event handling:

• Pause

• Resume

• Cancel

• Delete

• Complete

If Siebel CRM starts an operation in a task UI, then it calls a task event to handle the operation. The event handler for each operation performs the required action according to the semantics of each operation. A preevent handler is a type of handler that runs before Siebel CRM performs the operation for the handler, such as Resume, Pause, or Delete. Most handlers are preevent handlers.

For example, the Cancel operation includes two event handlers: a preevent handler and a postevent handler:

• The PreCancel event handler runs when the user cancels a task UI and before the temporary storage data rolls back.

• The PostCancel event handler starts after the PreCancel event handler runs and after Siebel CRM rolls back the temporary storage after the task finishes. For example, if the user clicks Finish or Submit, then the PostComplete event handler starts.

Siebel CRM does the following work to run an event handler that starts before the user starts the operation:

• If the event handler succeeds, then the task controller finishes the operation that the user started.

• If the event handler fails, then Siebel CRM stops the operation that the user started and returns the error to the object that called the event.

For more information, see Creating a Task Event and Siebel Object Interfaces Reference.

How Siebel CRM Handles an Event That Occurs in a Subtask

You cannot configure a subtask to reference an event handler. If a task UI calls a task event when the user is in a subtask, then Siebel CRM sends the task event to the parent task UI and runs the corresponding event handler that the parent task references. It runs this event handler in the context of the parent task.

Operations That Call an Event Handler

This topic describes operations that call an event handler.

Pause Operation

The Pause operation saves the following information in the Siebel database:

• Task state and task instance.

• An inbox item. The user can use this inbox item to restart the task instance.

Resume Operation

The Resume operation restores the state and history of a task instance and resumes a paused task instance. The user can click a Task inbox item in the Inbox Items List view to resume a task instance.

Cancel Operation

The Cancel operation stops the task transaction and rolls back the modifications that Siebel CRM saved before the user cancelled this task instance.

Events That the Cancel Operation Uses

The following table describes handling for the PreCancel and PostCancel events.

Table Handling for the Pre Cancel and Post Cancel Events

Event Type	Description	Usage
PreCancel	Note the following: The PreCancel event occurs in the context of the task UI, before the rollback. This event handler can compensate for a modification that occurs in an external system. The Cancel operation calls a PreCancel event before Siebel CRM rolls back temporary storage or before it deletes the task instance. If the user cancels a task, then the PreCancel event handler starts before Siebel CRM rolls back the temporary storage of the Object Manager. If the task includes a parent flow, then the parent flow receives an Abort status from the task. Rollback does not occur before this event, so it can access the context data of a task. The context data includes the field values that existed before the rollback occurred that is part of the Cancel operation. If an error occurs, then the task UI remains on the same view and displays an error in the Siebel client.	You can configure Siebel CRM to use the Pre Cancel event handler in the following situations: If the handler fails, then the Cancel event must quit. An external system must perform some action.
PostCancel	Note the following: The PostCancel event occurs after the PreCancel event finishes, outside of the context of the task UI, and after the rollback. You can use the PostCancel event to compensate for the temporary storage data of the Object Manager that Siebel CRM saves to the Siebel database during a commit step. The Cancel operation calls a PostCancel event after Siebel CRM rolls back the temporary storage due to the Cancel operation. The PostCancel event does not require access to temporary storage or the task context. If an error occurs, then Siebel CRM navigates the user to the view that it displayed after the task cancelled or finished. It displays the next standard view regardless of whether the handler succeeds or fails.	You can configure Siebel CRM to use the Post Cancel event handler in the following situations: If the handler fails, then the Cancel event must not stop. Access to temporary storage is not required.

Delete Operation

The Delete operation removes a task instance from the following items:

• Inbox

• Siebel database

If a parent task starts a task UI, then the subtask sends the parent task an Abort status. The task utility service creates this event.

Complete Operation

The Complete operation ends the task instance in the following situations:

• The user clicks Finish or Submit.

• Siebel CRM finishes the task instance automatically.

If the task finishes, then Siebel CRM starts the PostComplete event.

PostComplete Operation

The PostComplete operation allows the task UI to do more work after it finishes running. The following examples describe how Siebel CRM uses the PostComplete operation:

• A user runs a task UI that updates an account record. If the user submits the modifications to the account, then Siebel CRM passes the modifications and information about who modified the record as inputs to a business service. This configuration creates an audit trail on the account record.

• A task instance finishes running and, after submittal, a workflow process must run. This requirement makes sure no unwanted data exists. For example, a user can follow multiple paths in a task UI and create records in these paths. The user can navigate backward in the task UI and forward again down other paths. In this situation, a cleanup process that occurs at the end of the task session can eliminate unwanted data.

In these situations, it is important that the task instance finishes. The PostComplete event handler can handle a failure that occurs when Siebel CRM creates an audit trail or during cleanup. Siebel CRM does not abort this task instance.

About Event Logging

The event log collects information about different operations that occur while a task instance runs. It can print information that you can analyze. For more information, see Modifying How Siebel CRM Logs Data During Testing.

The table describes the following information:

• Event types that are related toSiebel Task UI that Siebel CRM displays in the Event Configuration View.

• Information about the events that Siebel CRM traces.

• Information symbols that Siebel CRM displays in the log files to identify the events.Siebel Task UI shares some event symbols with Siebel Workflow.

• The Log Level column indicates the minimum level that Siebel CRM uses to turn on tracing.

Caution: Setting a trace level higher than the default parameter affects performance. You must reset the trace level to the default parameter after you finish troubleshooting.

Table Event Logging for Siebel Task UI

Event Type	Level	Symbol	Information Symbol
Workflow Definition Loading	3	DfnLoad	Step. Steps and branch names that Siebel CRM loaded.
	5	DfnLoad	Chapter. Chapter names that Siebel CRM loaded.
Task Execution	3	TskExec	Oper. Includes information about various operations that the user performs during the duration of a task instance. Example operations include create, delete, pause, restore, instantiate, or cancel a task instance.
	5	TskExec	Siebel CRM includes the following symbols: TskState. Details about the state transition that occurs during the duration of a task instance. TskInbox. Internal details about the interactions that occur for the task instance with the Universal Inbox.
Task Navigation	3	TskNav	Oper. Includes information about the navigation operations that the user performed in a task instance.
	4	TskNav	NavPath. Includes information about modifications that occur to backward and forward navigation. Includes logs if Siebel CRM inserts a new frame or deletes a frame from backward or forward stacks.
	5	TskNav	DumpStack. Dumps frames in the forward and backward navigation stacks after Siebel CRM restores or resumes a task instance.
Workflow Process Execution	4	PrcExec	Create. Includes information about the creation of a new task instance.
Workflow Step Execution	4	StpExec	Includes information about a task step and input argument or output arguments of the task step. The following symbols are included: Cond. Information about how Siebel CRM evaluates a branch condition. Create. Information about how Siebel CRM creates a step instance. End. Information about Siebel CRM completes a step instance. Task. Information about calling a business service. TaskArg. Information about arguments to a business service.
Task Presentation Information	4	TskPresInfo	Includes information that the task controller provides to an external component. SWE is an example of an external component. ViewInfo. Information about the entire structure of the task view, including the following items: View name Playbar. Current task pane Records that are pending validation

About Task Metrics

A task metric is a type of metric that collects and stores data about a task UI that Siebel CRM regularly saves to a data warehouse. You can use an online analytical processing (OLAP) tool, such as Oracle Business Intelligence, to analyze this data. You can collect timestamp metrics and property metrics. For more information, see Modifying How Siebel CRM Logs Data During Testing.

Timestamp Metrics

A timestamp metric is a type of metric that stores timestamps for a task UI. Siebel CRM requires the time when an event occurs so that it can measure the timeliness of a business process. For example, Siebel CRM requires the time a task starts and ends so that it can determine the amount of time that a user spends on a task.

If task metrics are turned on when you deploy a task UI, then Siebel CRM stores the following timestamps for the task:

• Task Started

• Task Paused

• Task Resumed

• Task Cancelled

• Task Completed

The collection and persistence of these timestamps incur a minimal and finite performance and scalability overhead. Siebel CRM does not collect timestamp metrics at the step level because the affect on performance is not acceptable.

Property Metrics

A property metric is a type of metric that stores metrics for a task property. It allows you to collect data about a task UI whose source is a task property. You can define a property metric to satisfy the requirements to measure business performance. The following tables store data for property metrics:

• S_WFA_ANLY_INFO

• S_WFA_ANLY_PROP

• S_WFA_ANLY_TS

• S_WFR_PROC_MTRC