Siebel Remote and Replication Manager Administration Guide > Extracting Databases for Mobile Web Clients >

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.

Beginning with Siebel 7.5, the 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. When Optimal Mode is set to TRUE, the time required for extraction can also be affected by parameters such as Nodes Per Group and Extract All Repository Files. For more information about Database Extraction parameters, see Table 15.

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. If you need additional temporary tables for the process to use, you can create them using Siebel Tools.

Before running a database extract for a client, you must make sure that your organization's reporting hierarchies are updated. From the application-level menu, choose Navigate > Site Map > Administration - Group > Positions 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 Transaction Router 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

1. From the application-level menu, choose Navigate > Site Map > Administration - Server Management > Jobs.
2. In the Jobs list, click New.
3. In the Component/Job field, select Database Extract from the picklist.
4. In the Requested Server field, enter the name of the server on which you want the Database Extract job to run.

   NOTE:  After the job is completed, the read-only Execution Server field displays the name of the server that ran the job. For a Database Extract Job, this is the same as the Requested Server.

5. In the Job Parameters list, which is located below the Jobs list and the Job Detail form, 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.

6. In the Jobs list, with the Database Extract record still selected, click Start.

   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.