1

Every action in the Siebel database is considered a transaction.

These include adds, deletes, updates, merges, and so on.

A copy of each transaction is stored in the Master Transaction Log (S_DOCK_TXN_LOG), provided that the transaction is accomplished using Siebel software. Direct SQL modification of Siebel tables is not supported. SQL changes that are executed outside the Siebel application are not recorded in the Master Transaction Log (S_DOCK_TXN_LOG) and therefore will not be routed to mobile clients.

When using EIM to import records to the database, transactions are logged in the File System to improve performance. If Mobile Web Clients will have read/write access to the records imported during a particular EIM session, it is strongly recommended that the administrator use the row-by-row logging method. For additional information about this topic, see Siebel Enterprise Integration Manager Administration Guide.

Transactions are stored at the field level to minimize the size of S_DOCK_TXN_LOG. When Transaction Logging is turned on and an action occurs, only changes to the fields are captured as transactions. This helps to optimize the synchronization process.

2

The Transaction Processor picks up the transactions stored in S_DOCK_TXN_LOG and copies them to the Applications Server directory DOCKING\TXNPROC.

The Transaction Processor also picks up some transactions from the file system and copies them to DOCKING\TXNPROC. These file system transactions are of type External File.

After the transactions are copied to Applications Servers, TXNPROC clears the S_DOCK_TXN_LOG of the transactions.

3

Transaction Router picks up the transactions from DOCKING\TXNPROC and determines which mobile users should receive them.

4

When a Remote administrator first creates a database extract for a remote user, this action triggers the creation of a docking directory on the remote server (a Siebel Server) for that user.

It creates an inbox and an outbox.

The outbox stores any future extracts as well as DX files from Transaction Router.

It then sends these DX files to each Remote client's outbox on the server in the docking directory based upon visibility and routing rules.

After Transaction Router completes its task, it instructs Transaction Processor to purge the DX files in the DOCKING\TXNPROC directory base on the Transaction Processor's parameter: Clean .dx files iterations.

5

During implementation of Siebel eBusiness Applications, at least one Siebel Server is designated as a Remote server. It will host all or some of the Remote users.

This server contains the Docking Directories for remote users to transfer the files involved with the synchronization process. These files include:

New database templates (from the Generate New Database task)

Database extracts (used with the templates to initialize the local DB)

DX files (.dx)

TOC files (.toc)

Visibility data for the Remote clients (visdata.dbf and dobjinst.dbf)

6

Remote clients process transactions in their local database while in disconnected mode.

A copy of each transaction is stored in the Local Transaction Log (similar to the Master Transaction Log on the server side).

7

When the user starts the synchronization process, the Remote Client creates DX files from the log and moves these DX files to the Remote client's outbox on the local machine.

8

The synchronization process starts when the Remote client initiates a synchronization session.

Synchronization Manager must be running and will authenticate the Remote client, based upon the type of authentication in the Component Parameters.

The synchronization process includes handling communication between the Mobile Web Clients and the file system.

The process moves the DX files from the docking directory outbox to the Remote client's inbox. It will move files from the Remote client's outbox to the docking directory's inbox.

Any attachments, correspondence, or templates that the Remote client creates are copied to the Siebel File System.

9

Changes do not occur in the server database until the synchronization session finishes and the Mobile Web Client disconnects.

Depending on the user synchronization options or command-line options chosen, the Remote client either begins applying the DX files to the local database as soon as the first transaction file is received, or after it completes the file exchange with the server.

10

Transaction Merger, a component on the server side, pulls the DX files from the inbox within the Docking Directory.

11

Transaction Merger applies the changes to the server.

It also identifies conflicts.

A setting for System Preference, MRG: System Conflict Resolution, specifies whether the server or client wins during conflict resolution. The value can be Server Wins or Client Wins.

Conflicts will be communicated to the Remote user during the next synchronization.

Transaction Merger deletes the DX files from the inbox within the Docking Directory.

Remote Configuration File

DockConnString is the name of the computer where the Siebel server software is installed and where the mobile client was extracted. DockConnString should be populated when the client is first initialized.

An important configuration parameter, AutoStopDB, is part of the Local configuration. Its default is FALSE, which means the local database engine will keep running after Siebel eBusiness Applications shut down. This will help shorten the startup time when the user restarts Siebel eBusiness Applications. If AutoStopDB is set to TRUE, the local database engine will shut down automatically when the Siebel eBusiness Applications shut down.

In the local database connecting string, -q means the local database is started in quiet mode. This prevents a SQL Anywhere window from showing up. However, a SQL Anywhere icon will appear on the Windows task bar, whether or not the -q parameter is used. This provides the user with a way to manually stop the database engine, if the user leaves the engine running after Siebel eBusiness Applications shut down.

On the local database connect string, the - m means truncate transaction log after checkpoint; -x NONE means do not load any network drivers; -gp 4096 tells the engine that the database page size is 4,096 bytes;
-c40m -ch60m sets the initial cache size to 40 MB, with a maximum of 60 MB. The cache sizes are suggested values that the user can adjust. However, the SQL Anywhere engine will determine the actual cache size within the given range of values.

Users can specify the sorting order on Local and Sample databases. To enable this feature, users modify their CFG file (for example, siebel.cfg, uagent.cfg). The SortCollation parameter in the CFG file determines the sorting order of the SQL Anywhere database. For best performance, it is recommended that SortCollation be set to Binary. For more details about this topic, see Siebel System Administration Guide.

Authentication method

A Synchronization Manager component parameter that identifies the type of authentication that is used during synchronization. Values include:

None. Does not validate the synchronization authentication credentials. This is the default.

Database. Validates the synchronization authentication credentials against the server database user ID and password.

Siebel. Validates the synchronization authentication credentials against the Mobile Client name and Sync Password that is stored in the server database and is maintained for each Mobile Web Client in the Administration - Siebel Remote > Mobile Clients view under the appropriate parent server.

AppServer. Validates the synchronization authentication credentials against the user ID and its password on the Siebel Server operating system.

SecurityAdapter. Validates the synchronization authentication credentials against a third-party authentication system.

Synchronization Frequency

Siebel Systems recommends that mobile users synchronize against the server at least daily. There is an automatic mechanism called TrickleSync to help enforce frequent synchronization. Users can invoke TrickleSync on their laptops or administrators can set up the feature for their mobile users. For more detail about this topic, see Using TrickleSync.