Siebel Solutions by Siva Ganga: 2009-06-21

A user of a Siebel application is a record in the User business component. The S_PARTY, S_CONTACT, and S_USER tables in the Siebel Database underlie the User business component. Each user is assigned a responsibility, a user ID, and, depending on the authentication architecture being used, a password.

An employee or a partner user is a user who has a position within a division, either internal or external, in the Siebel Database. Other users, such as those who use customer applications such as Siebel eSales, do not have a position or a division. The S_EMP_PER table underlies the Employee business component, to which employees and partner users belong, in addition to the tables that underlie the User business component.

For more information about the functions of responsibilities, positions, divisions, and organizations, see Access Control.

An administrator uses different views to add employees, partner users, and other users, although each of these users has a record in the User business component.

Adding a New Employee

At a minimum, an employee must have a position, a responsibility, and a Siebel user ID.

You can also associate attributes with employee records such as skills, tools, assignment rules, and availability. By doing so, you can use the employee record and its attributes with features such as Siebel Assignment Manager and Siebel Professional Services Automation.

The following procedure creates a User record for the employee only as a stage in allowing the employee to access the database.

To add a new employee

Log in as an administrator to a employee application, such as Siebel Call Center, and then choose View > Site Map > User Administration > Employees.

The Employees list appears.

Click the menu button, and then choose New Record.

As shown below, a new record appears in the Employees list and a corresponding form appears under the More Info view tab.

Your browser may not support display of this image.

In the More Info form, click the show more button.

Additional fields appear in the More Info form, including the New Responsibility field.

Complete the form. Use the following guidelines.

Field	Guideline
Last Name	Required.
First Name	Required.
User ID	Required. This field must be unique for each user. Depending on your authentication architecture, the user may or may not log in with this identifier. If you implement database authentication, this field must be the login name for a database account.
Password	Optional (required for some authentication implementations). This field is editable only if you implement database or security adapter authentication. For security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database. The password is propagated to the user directory. The user uses this password to log in. This field is not editable if you implement Web SSO authentication. For Web SSO, you maintain the user's login password independently in the external authentication system. For information about user authentication architectures, see User Authentication Overview.
Responsibility	Required. Pick one or more responsibilities which include appropriate views for the employee. If the administrator who creates this user has a value in their New Responsibility field, then that responsibility is assigned to this user by default. For information about the New Responsibility field, see New Responsibility Field.
New Responsibility	If the administrator who creates this user has a value in his or her New Responsibility field, then that responsibility is assigned to this field by default. For information about the New Responsibility field, see New Responsibility Field.
Position	Required. To be an employee, a user must have a position. If you assign multiple positions, the position you specify as Primary is the position the user assumes when he or she logs in.
Division	This field is populated automatically with the division to which the Primary position belongs.
Territory	This field is a read-only multi-value group. You are not able to enter a value manually. When you complete the Position field, the Territory field is populated automatically with territories with which the position is associated.
Organization	This field value is inherited from the user who creates this user, but the field is editable. Users whose positions are in this organization have access to this employee record. For information about organization access control, see About Access Control Mechanisms

Click Save.

Completing Employee Setup

You can set up employees either before or after you assign them a responsibility. For more information about completing employee setup, refer to the initial setup section ofApplications Administration Guide.

Also refer to Siebel Assignment Manager Administration Guide and Siebel Professional Services Automation User Guide.

Deactivating an Employee

You can deactivate an employee by dissociating the employee record from its responsibilities, altering the user ID, and removing the employee's access to the database.

To deactivate an employee

From the application-level menu, choose View > Site Map > User Administration > Employees.

The Employees view appears.

In the Employees list, select the employee you want to deactivate.
In the More Info view tab, delete all records from the Responsibility field.
Change the user ID slightly, to indicate that the employee is no longer current.

You may want to establish a convention for renaming user IDs when you deactivate employees. One possible convention is to append some text such as "expired" to the user ID. For example, you might change CARD to CARD-expired. That way you can continue to see the person's name associated with previous activity in history records.

Remove the employee's access to the database.

If you implemented database user authentication, you should remove the user's database account. If you implemented external authentication, then delete the user from the directory from which the user's database credentials are retrieved.

NOTE: In the case of external authentication, if the external user repository is shared by many applications—as in the case of an LDAP directory or Microsoft Active Directory—do not delete the user from the directory. In such a case, make sure that the user's database access user name and password are different from that user's directory user name and password. Otherwise the user would be able to access the database directly using some database connection tools.

Adding a New Contact User

Users who are not employees or partner users do not have positions. These users include, for example, customers who use Siebel eSales or students who use Siebel eTraining. They are called customer or contact users to distinguish them from employee and partner users.

Contacts, such as contacts at a customer account, can exist in the database without having login capability. You create such contacts as Persons in the User Administration screen. The procedure in this section applies to contact users to whom you are providing a login to the Siebel Database.

CAUTION: You can modify field values for existing contact users, such as in the event of a name change. However, changing the user ID for such a user presents special issues, because this ID may be stored in various types of records, using a field such as CREATOR_LOGIN (where a foreign key to the user record is not used instead). Values for such fields are not automatically updated when the user ID is updated. If you change the user ID, you must manually update such values in other records.

To add a new contact user

Log in as an administrator to a Siebel employee application, and then choose View > Site Map > User Administration > Users.

The All Users list appears.

Click the menu button, and then choose New Record.

As shown below, a new record appears in the All Users list and a corresponding form appears under the More Info view tab.

Complete the fields in the More Info form, and then click Save. Use the following guidelines.

Field	Guideline
Last Name	Required.
First Name	Required.
User ID	Required. The user logs in with this ID.
Password	Optional (required for some authentication implementations). For security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database. The user uses this password to log in. This field is not editable if you implement Web SSO authentication. For Web SSO, you maintain the user's login password independently in the external authentication system. For information about user authentication architectures, see User Authentication Overview.
Account	Pick one or more accounts to associate to the user. Specify one as the primary account. For information about the function of the account in delegated administration, see Delegated (External) Administration of Users.
Responsibility	Pick one or more responsibilities which include appropriate views in the customer application, such as Siebel eService, for this user. If the administrator who creates this user has a value in their New Responsibility field, then that responsibility is assigned to this user by default. For information about the New Responsibility field, see New Responsibility Field.
New Responsibility	If the administrator who creates this user has a value in the New Responsibility field, then that responsibility is assigned to this field by default. For information about the New Responsibility field, see New Responsibility Field.
Time Zone	Choose a time zone so that times for events can be expressed in terms of this zone.
User Type	This field serves as a filter so that different applications can query for contact users only applicable to each particular application.
Auction Privilege	This field applies to users of Siebel eAuction only. For information about auction privileges, seeSiebel eAuction Guide.
Work Phone # Fax # Home Phone #	The application interprets only the digits the user provides.

The new user appears in the All Users list.

You can promote an existing contact to a contact user by assigning user credentials and a responsibility to a Person record.

To promote an existing contact to a contact user

Log in as an administrator to a Siebel employee application, and then choose View > Site Map > User Administration > Persons.

The All Persons list appears.

Select the record of the contact to promote.
Enter the user ID, Password, Responsibility, and New Responsibility fields as described in To add a new contact user.

Q2. What are Audit Trails and How to specify them? How to determine if a business component can be audited (ANS - The underlying business component must be derived from CSSBCBase.)?

Audit Trail Features

You can configure and activate Audit Trail from an administration screen.

Audit Scope

System administrators can specify the audit scope by the following means:

Operations (such as update, new, delete, and copy) performed on business components
Operations performed in a specific time period
Only those operations performed by certain responsibilities, positions, or employees

Audit Trail Content

Audit Trail records the following information in selected business components:

Field
Row ID of the record being changed
Operation being performed (Update/New/Delete/Copy)
Original value
Changed value
User ID performing the operation
Date and time the operation was performed

Audit Trail Constraints

The following cannot be audited:

The underlying business component not derived from CSSBCBase. This is because Audit Trail's functionality resides only in business components of class CSSBCBase. The procedure To determine if a business component can be audited tells you how to determine whether or not a business component can be used in Audit Trail.
Business components based on intersection tables.
Virtual business components, because they are not derived from business components of class CSSBCBase.
The merge action.
Multivalue fields.
Calculated fields. Typically, the value for a calculated field is derived from a table-based field. To audit a calculated field, you can audit the table-based field that was used to derive the calculated field.
Record inserts, updates, and deletes performed through Enterprise Integration Manager (EIM), Assignment Manager or workflow policy actions (because these do not go through the Siebel Object Managers).

To determine if a business component can be audited

Launch Siebel Tools.
In the Object Explorer, navigate to the Business Component object type.
In the Object List Editor, select the business component.
In the Class field, look for CSSBCBase. If the class is CSSBCBase, the business component can be used for Audit Trail.

CSSBCBase and CSSBusComp are the most basic class types. If there is a value in the Class field that is not CSSBCBase or CSSBusComp, then there is specialized functionality that has been written in C++ related to this class.

To see if this specialized class is related to CSSBCBase, drill down on the Class hyperlink.
In the Super Class field, look for CSSBCBase. If the class is not CSSBCBase, drill down on the Super Class hyperlink.

If the Super Class is...	Then the business component...
CSSBCBase	can be audited.
CSSBusComp	cannot be audited.
(blank)	cannot be audited.

NOTE: Repeat Step 6 until the Super Class field is either CSSBCBase, CSSBusComp, or blank.

Audit Trail for Siebel Remote and Siebel Replication Users

The following information applies to remote and replication users:

Disconnected users can use Audit Trail as well as connected users. Audit Trail will stamp transactions with local machine time.
Remote and replication users should not use file auditing mode, only database auditing mode.
Audit trails are synchronized or replicated along with other data.
If the transaction is rejected during the conflict resolution, the corresponding audit trail record is not discarded.

File Auditing and Database Auditing Modes

The following information applies to file auditing and database auditing modes:

Database auditing writes transaction records directly to the database, while file auditing writes to the Siebel file system. You can later import these files into the database. (See To import audit trail items from a file into the Siebel database.) You can schedule import batch processes for these files using workflow processes. (See the ImportAll method in Table 12.)
If you use file auditing mode, you have to import files into the database to have a comprehensive view and to be able to query for the information you need. Otherwise, you can view records only on a file-by-file basis.
For systems in which every user is a connected user, file auditing mode yields better performance. Systems using Siebel Remote or Siebel Sync should use database auditing.
Purging and archiving can be done at the database level.

Audit Trail Recovery in File Auditing Mode

When running in file auditing mode, instead of writing to the Siebel file system every time a new Audit Trail file is created, your Siebel application saves Audit Trail files to a file directory on the Object Manager to improve performance. When the Object Manager closes normally, these files are uploaded to the Siebel file system simultaneously.

If the Object Manager exits abnormally, Audit Trail keeps track of which files have been uploaded to the Siebel file system and which ones have not. The next time Audit Trail starts, any files that have not been uploaded are uploaded automatically.

Audit Trail Engine Business Service

The Audit Trail Engine business service is located in the Object Manager and stays active as long as the Object Manager is active. The purpose of the Audit Trail Engine business service is to capture changes (updates and deletes) to records and to store them in the designated format (database or Siebel file system, according to the audit trail mode selected). For the various data operations, if the auditing condition is met, the business component being audited triggers the Audit Trail Engine business service.

The methods listed in Table 12 are associated with the Audit Trail Engine business service. The Start, Stop, and ImportAll methods are accessible to an administrator and allow the performance of certain tasks.

Table 12. Exposed Methods in the Audit Trail Engine Business Service
Method	Mode	Internal Use Only	Description
Start	Both		Starts the Audit Trail Engine.
Stop	Both		Stops the Audit Trail Engine.
ImportAll	File only		Imports all the associated Audit Trail Item business component records.
AddTrailEntry	Both	X	For the person specified, adds an audit trail entry to the pertinent data structure (unsaved audit list).
CommitTrail	Both	X	Removes the uncommitted elements from the unsaved list and puts them on the saved list, and writes to the database or file if the cache size has been reached.
CrashRecover	File only	X	Saves file from local system to the Siebel file system.
Kill Unsaved Trail	Both	X	Kills the unsaved audit trail; this happens on an UndoRecord.

The easiest way to use these methods is through a workflow process. If you want to stop or restart the Audit Trail Engine, create a new workflow process or reuse an existing one, and then create a business service node that implements the Stop method or the Start method.

Q1. How to do DB Extract and DB Initialize?

Database Extraction for a Mobile Web Client

The database extract process retrieves data visible to a specific mobile user from the server database. It retrieves data according to routing rules that define the level of access to information for each Mobile Web Client. It creates compressed files that contain data to be loaded into a local database when a Mobile Web Client initializes the database.

The database extraction process uses the new database template created by running the Generate New Database Template component. This template lets the database extraction process provide up-to-date database schemas to either new or existing mobile clients. It is strongly recommended that you distribute all database schema changes to all mobile clients, even if the changes are of types that are not visible to the mobile clients, such as changes to private dock objects. This is important because individual tables that are currently in a private dock object may become visible to mobile clients at a later time, and problems can occur if server and local database structures do not match.

The Siebel 7.5 Database Extraction component includes an enhancement when dealing with a list of mobile users to extract. It will identify visible instances for all members of a list of nodes. Then it identifies the commonly visible instances and extracts the records only once for all these nodes. Then it extracts instances outside the common set for each node. This will help reduce the time for extracting large numbers of mobile users. The parameter that enables this is Optimal Mode.

NOTE: Multiple instances of the database extract components can be run simultaneously. In order to reduce contention, each task should be assigned to use a different temporary table called S_DOCK_INITM_n, where n is 1 to 48. Siebel Remote supports up to 100 such tasks. The Siebel Schema includes 48 S_DOCK_INITM tables. You can create additional tables based on your loads and needs by using the ddlexp and ddlimp utilities.

Before running a database extract for a client, you must make sure that your organization's reporting hierarchies are updated. Use the Position Administration view from the Application Administration screen to verify that the user you are about to extract has a valid position in your organization's hierarchy. The resulting information is used by the system's routing rules, and may affect the outcome of the database extract. For more information on positions, see Applications Administration Guide.

CAUTION: If a mobile user's position or routing model changes, reextract the Mobile Web Client's database to delete records that should no longer be visible to the user based on the user's new position.

Additionally, this improves performance because the reorganization process will generate many transactions on the server, which will create a backlog.

Administrators can start several instances of dbxtract and reduce the contention by using more than one table. The parameter is TS Table Number with a default of 1.

During the cleanup of dobjinst.dbf database tables, administrators can choose truncation or deletion of the tables. The parameter is Truncate TS Table with a default of FALSE.

CAUTION: If two instances of dbxtract use the same table, do not set TruncateTSTable to TRUE—one instance can truncate the records entered from another instance.

The Save Client Transactions feature prevents the loss of local transactions a mobile user may have entered into the local database that were not included in the server db extract. This feature is valid for normal re-extract of a mobile user's local database and will not work during a major upgrade process.

The default setting for the server parameter Save Client Transactions is TRUE. If the db extract for a Mobile Web Client occurs when this parameter is set to TRUE, Siebel Remote will invoke an action before applying the new db extract. Remote will extract transactions from the current local database that are not yet synchronized with the server and store them in the mobile user's inbox as DX files.

After the current local database is replaced with the new extract, Remote applies the DX files from the mobile user's inbox to the new local database. These include the saved transactions that were not synchronized with the server. These transactions are then sent to the server during the next synchronization session.

To run a database extract for a Mobile Web Client

From the application-level menu, choose View > Site Map > Server Administration > Enterprise Operations.
Click the Component Requests tab.
In the Component Request form, click New.
In the Component/Job field, select Database Extract from the picklist.
In the Component Request Parameters list, click New and add the necessary parameters.

The required parameter for Database Extract is Client Name.

The value for the Client Name parameter is the name of the Mobile Web Client.

In the Component Requests form, click the menu button and then click Submit request.

The Mobile Web Client database is extracted. This may take a few minutes.

NOTE: For limited-visibility objects, attaching many children to the same parent record can degrade the router performance and the database extract performance. The reason this may happen is that for each child the visibility for all other children must be checked. Whenever there are more than 10,000 child records attached to a parent (such as contacts attached to an account), the database extract performance and router performance need to be tested thoroughly. In case performance degradation is observed, it is necessary to limit the number of children per parent.

Initializing a Mobile Web Client Database

The volume of information that must be downloaded from the Siebel Remote server to initialize a Mobile Web Client's database is usually substantial. You should establish a LAN (rather than a modem or WAN) connection between the server and the Mobile Web Client for this process.

Alternatively, the local database can be initialized from a CD-ROM or other media if compressed files have been copied into the folder specified as FileSystem parameter. For more information, see Performing a Database Extract to a CD Directory.

NOTE: To initialize a Mobile Web Client database, the TableOwner parameter in the CFG file must be set to Siebel (the default).

To initialize the Mobile Web Client database using the GUI

Establish a connection between the Siebel Remote server and the Mobile Web Client.
In the Mobile Web Client's Siebel program group, click the Siebel Remote icon.

NOTE: Verify that the icon is pointing to the appropriate CFG file. The default is siebel.cfg.

In the Siebel Remote Parameters dialog box, enter the appropriate information.

In the Client Name field, enter the registered Siebel client name.

In the User Name field, enter the login name of the mobile user.

Enter the password.

The password must match the authenticator password.

Click Continue.
Monitor the process for errors by clicking the opposing arrows in the lower right corner of the screen.

To initialize the Mobile Web Client database from the command line

The Mobile Web Client database can also be initialized from the command line using the stand-alone synchronizer (siebsync.exe). For information on how to use the stand-alone synchronizer, see Enabling the Stand-Alone Synchronizer.

To initialize the Mobile Web Client database during login

Another way to initialize the Mobile Web Client is to log in to the local database when starting the application. When your Siebel application cannot find a local database, it will attempt to initialize the local database following the procedures described above.

Architecture:

Table 5. Siebel Application Entities
Entity	Comments
Siebel Clients	Includes Siebel Web client, Dedicated Web Client, Wireless Client, Mobile Web Client, handheld client, and Siebel Tools Client. For descriptions of client types, see Siebel Web Client Administration Guide.
Siebel Enterprise Server	Includes the logical grouping of Siebel Servers for a multiple server deployment (for a single Siebel Server and single Web server deployment, the Siebel Enterprise Server contains a single Siebel Server and the Siebel Gateway). The Siebel Enterprise Server, collectively with the Siebel Gateway, provides both batch mode and interactive services to and on behalf of Siebel clients.
Siebel Gateway	Includes the connection broker and name server for a single server deployment. (The name server is a separate entity for multiple server deployments.)
Siebel Database Server	Includes the RDBMS client software and Siebel tables, indexes, and seed data.
Siebel File System	Stores the data and physical files used by Siebel clients and Siebel Enterprise Server.

Siebel Gateway

The Siebel Gateway:

Provides load balancing and high-availability across the Siebel Enterprise Server.
The Siebel Gateway is a logical entity, not a physical server consisting of a Name Server and a Connection Broker.

Siebel Enterprise Server

The Siebel Enterprise Server is a logical grouping of Siebel Servers that supports a group of users accessing a common Siebel Database Server. The Siebel Enterprise Server can be configured, managed, and monitored as a single logical group, allowing the Siebel administrator to start, stop, monitor, or set parameters for Siebel Servers within a Siebel Enterprise Server.

You can set some Siebel Server parameters at the Siebel Enterprise Server level, and these parameters will apply to every Siebel Server and component operating within that Siebel Enterprise Server; other parameters can be adjusted at the Siebel Server or component level to support fine-tuning. If a parameter is set at the server level, then the server-specific value overrides the Siebel Enterprise Server setting for the parameter on that server.

Each Siebel Server belonging to a Siebel Enterprise Server should connect to the same schema in the same database server.

The Siebel Enterprise Server itself has no processes and, therefore, cannot have a state. However, you can start and shut down operations at the Siebel Enterprise Server level, and these actions will apply to every Siebel Server within that Siebel Enterprise Server.

Siebel Server Components

The various programs that operate on the Siebel Server are implemented as components. A component represents only a specific type of program; a component is executed or operated as a task, or instantiation of a component, on a specific Siebel Server. See the following sections for details on server components.

Component Modes

Components can execute tasks in one of three run modes—background, batch, or interactive.

Background mode components. Background mode components execute tasks to perform background operations for the Siebel Server. After a background mode component task starts, it runs until you explicitly stop the task, or until the Siebel Server itself is shut down.

You can manually start a background mode component by using the Siebel Server Manager. Components with a Default Tasks parameter set to a value greater than zero may start automatically when the Siebel Server is started. Examples of background mode components include Transaction Router, Replication Agent, and Workflow Monitor Agent.

Batch mode components. You must manually start these components by using the component request process in the Server Manager GUI or by the Server Manager command-line interface. Batch mode components end after the task has been performed. Examples of batch mode components include Database Extract and Enterprise Integration Manager.
Interactive mode components. Interactive mode components start tasks automatically in response to client requests. Interactive mode component tasks execute for as long as the client maintains the session, and end when the client disconnects. Examples of interactive mode components include Synchronization Manager and Application Object Managers.

Component Types

Siebel Server supports multiple component types; each type performs a specific function or job. A component type is configured with a set of parameters that determine its behavior to create an entity called a defined component (or simply component). Components are defined at the Siebel Enterprise Server level in component groups. Component groups are then assigned to one or more Siebel Servers within the Siebel Enterprise Server on which they can execute tasks.

Component Groups

Component groups are functional areas that involve logical groupings of Siebel Server components and multiple operating system processes. A component group consists of one or more components, which may be running in one or more operating system processes. Component groups act as:

The unit of deployment on, or assignment to, a Siebel server. In general, you include in a Siebel Server the group of components that are deployed on one or more servers.
A unit for monitoring functionality of the interrelated components within the group (you can get a summary of the operational status at the component group status, which is determined by the individual states of the constituent components.
A unit of control, whereby you can make available or unavailable the interrelated components in a single step, such as Siebel Remote or Workflow Management.

Component Processes (Shells)

The Siebel Server runs each component in its own separate process (or shell). These shells provide the interface for a component to communicate with shared memory, and use infrastructure facilities for logging, events, networking, and so on. A shell performs the following actions when it is forked off:

Initializes the logging/networking facility.
Determines which component to run. The component is specified as a DLL (personality DLL), which is run by the Siebel Server either as part of the input parameters or as part of a network message.
Attaches to shared memory.

The Siebel Server forks an appropriate shell based on the component mode (interactive, batch, or background) and whether the component is object manager-based, multithreaded, or both. Table 6, Table 7, and Table 8 define the shell types created in various scenarios.

NOTE: To conserve system resources and minimize the number of processes started on the Siebel Server, disable components and component groups that you do not plan to run. See Configuring Component Groups and Server Components for further details.

Table 6. Interactive Mode Components
Multithreaded	Object Manager Based	Shell
False	False	siebsess
True	False	siebmtsh
True	True	siebmtshmw

Table 7. Batch Mode Components
Multithreaded	Object Manager Based	Shell (Created at Bootstrap)	Shell (Created at Runtime)
False	False	siebproc	siebsh
False	True	siebprocmw	siebshmw
True	False	siebmtsh	siebmtsh
True	True	siebmtshmw	siebmtshmw

Table 8. Background Mode Components
Object Manager Based	Shell (Created at Bootstrap)	Shell (Created at Runtime)
False	siebproc	siebsh
True	siebprocmw	siebshmw

Examples of Siebel Server shells:

A background component that is not object manager based is brought up in a siebproc shell. For example, Transaction Processor (TxnProc).
An interactive component that is multithreaded and not object manager based is brought up in a siebmtsh shell. For example, Server Request Broker (SRBroker).
A multithreaded, object manager-based component is brought up in a siebmtshmw shell. For example, Call Center Object Manager (SCCObjMgr).

Parameters Controlling Number of Shells

The following parameters configure shell (process) start up for interactive, batch, and background mode components.

MaxMTServers
MinMTServers
MaxTasks
DfltTasks

Siebel Remote Server Components

This section discusses the Siebel Remote server components that operate on the Siebel Server and provides an overview of the administration tasks you need to perform for each component.

Creating Siebel Server Directories for Mobile Web Clients

Each registered Mobile Web Client requires a separate directory on the Siebel Remote server. The Database Extract program creates the appropriate directory and its subdirectories for each Mobile Web Client.

NOTE: The installation program also places a directory called txnproc in the docking subdirectory within the Siebel server root directory. Do not modify the contents of this directory under any circumstances.

The following example shows a portion of the server directory tree after you run Database Extract for Mobile Web Clients named Adams and Scott:

siebel

docking

adams

inbox

outbox

scott

inbox

outbox

txnproc

Generate New Database

The Generate New Database component creates the local database template for a given database schema version. The component reads the database schema definition from the Siebel repository, then creates Siebel tables and indexes in a database template file stored on the Siebel Remote server in the dbtempl subdirectory.

The Local Database Initialization program uses the local database template when initializing a new database on the Mobile Web Client.

NOTE: Dicdata.dat and diccache.dat are the same dictionary file. Dicdata.dat is named differently for Mobile Web Clients. These files store metadata about schema definitions, vis-rules, and other items.

The Generate New Database component copies diccache.dat to the dbtempl\\dicdata.dat file. The dicdata.dat file is downloaded to Mobile Web Clients and used by the synchronization process whenever transactions are applied to the local database.

If you need to interchange the dicdata.dat file between Mobile Web Clients for different languages, contact Siebel Technical Support to determine if the languages are interchangeable.

Administration of the Generate New Database Component

You must generate a new database template whenever the Siebel database schema changes in cases such as:

Immediately upon installing the Siebel database server
Following an upgrade to a new version of Siebel applications
Extending the database schema using Siebel Tools—except when using Siebel Anywhere to deliver a database schema upgrade kit

If your deployment requires a different collation template not provided by Siebel eBusiness Applications, please contact Siebel Expert Services for assistance in creating a new collation template.

Optimal Size for Local Databases

The recommended size for the SQL Anywhere local database depends upon several factors. These include the Mobile Web Client user's position and responsibilities. Also, the Data Routing Model assigned to the client impacts the volume of data to be stored in the local database. The local database should not be larger than 700 MB. For further information on this subject, or if a local database will exceed this number, contact Siebel Systems.

Synchronization Manager

The Siebel Remote server starts a Synchronization Manager task for each incoming synchronization request from a Mobile Web Client. For each request, the Synchronization Manager:

Verifies the Mobile Web Client status and password (if Siebel Remote authentication is enabled)
Transfers the local database template and local database extract if applicable
Exchanges transaction files
Transfers file attachments to and from the Siebel File Server

Each Synchronization Manager task services only one Mobile Web Client at any one time, but many synchronization tasks can be started concurrently. This behavior is configured by a Synchronization Manager parameter called Max Task. The Synchronization Manager component must be enabled for Siebel Remote mobile users to be able to connect to the Siebel Remote server for synchronization. Synchronization Manager tasks start automatically; you do not need to start tasks for this component manually.

Starting Siebel Remote Server Components

Use Siebel Server Manager to set values for start-up parameters for the following Siebel Remote server components:

The default parameter values for each component are described in the following sections.

The following procedures describe how to configure these server components.

To start Transaction Processor - srvrmgr command line

From the srvrmgr command line, enter:

start task for comp txnproc with = , ,...

Values are from Start-Up Parameters for Transaction Processor.

NOTE: When logging into srvrmgr command line, indicate the server name. Otherwise srvrmgr will default to the Enterprise Server. For details regarding the Server Manager command-line interface, see Siebel Server Administration Guide.

To start Transaction Processor - GUI

In Siebel 7, the Transaction Processor cannot be started manually through the GUI Server Manager unless the Siebel Server is up and running. The component has been defined to start one task when the Siebel Server is started if the component is enabled. If the component is not started, navigate to Site Map > Server Administration > Servers > Server Components tab, and start the component. A new task should be started.

To start Transaction Router - srvrmgr command line

From the srvrmgr command line, enter:

start task for comp txnroute with =,<parameter2=,...

Values are from Start-Up Parameters for the Transaction Router.

To start Transaction Router - GUI

In Siebel 7, the Transaction Processor cannot be started manually through the GUI Server Manager unless the Siebel Server is up and running. The component has been defined to start at least one task when the Siebel Server is started if the component is enabled. If the component is not started, navigate to Site Map > Server Administration > Servers > Server Components tab, and start the component. A new task should be started.

To start Transaction Merger - srvrmgr command line

From the srvrmgr command line, enter:

start task for comp txnmerge with =,<parameter2>=,...

Values are from Start-Up Parameters for Transaction Merger.

To configure Transaction Merger - GUI

In Siebel 7, the Transaction Processor cannot be started manually through the GUI Server Manager unless the Siebel Server is up and running. The component has been defined to start at least one task when the Siebel Server is started if the component is enabled. If the component is not started, navigate to Site Map > Server Administration > Servers > Server Components tab, and start the component. A new task should be started.

To configure Synchronization Manager - srvrmgr command line

Synchronization Manager is started automatically by the Siebel Server using the default configuration. It does not need an explicit configuration. For information on using Siebel Server Manager to manage and administer server components, see Siebel Server Administration Guide.

Starting and Stopping Siebel Remote Server Components

Use the Siebel Server Manager to start and stop any Siebel Remote server components.

NOTE: Event logs provide helpful information for diagnosing problems that may arise. To enable event logging for Remote components, see Siebel Server Administration Guide. For example, to receive useful information for the dbxtract component, enter the following in the command-line interface for srvrmgr:

change evtloglvl GenericLog=5, Trace=5, SQL=5, EVENT_GENERIC_PROFILE=5 for comp Dbxtract

start task for comp Dbxtract with Client=, SQLFlags=2, TraceFlags=7

To enable the Remote component group

In the command-line interface, change to the Siebel Server bin subdirectory.
Enter the following command to invoke the Line Mode Server Manager:

srvrmgr /e /g /u /p

From the Server Manager command line, enter:

enable compgrp remote

This will enable all Siebel Remote components: Synchronization Manager, Transaction Processor, Transaction Router, Transaction Merger, Replication Agent, Database Extract, Parallel Database Extract, and Generate New Database.

From the GUI, synchronize the components by navigating to View > Site Map > Server Administration > Enterprise Configuration > Batch Component Admin.
Click Synchronize.

To disable the Remote component group

From the Server Manager command line, enter:

disable compgrp remote

To enable Remote component group for a specific server

From the Server Manager command line, enter:

enable compgrp remote for server

This will enable Remote only on certain Application servers in the enterprise, rather than on all of them.

To disable individual components of the Remote component group

From the Server Manager command line, enter:

disable compdef

Component definition will be synchmgr, txnproc, txnroute, txnmerge, repagent, dbxtract, pdbxtract, or gennewdb, depending upon the situation.

Saturday, June 27, 2009

Wednesday, June 24, 2009