Siebel Remote and Replication Manager Administration Guide > About Siebel Remote > Siebel Remote Architecture >

Flow of Data Through the Architecture

Figure 3 illustrates the flow of data through the architecture for Siebel Remote.

Figure 3. Flow of Data Through the Architecture for Siebel Remote

Explanation of Callouts

Data flows through the Siebel Remote architecture in the following sequence:

1. Siebel Remote considers every action in the server database as a transaction. These actions include adding and deleting rows, updating rows, and merging rows. It stores a copy of each transaction in the Master Transaction Log table (S_DOCK_TXN_LOG), provided that Siebel CRM performs the transaction.

   To minimize the size of the S_DOCK_TXN_LOG table, Siebel Remote stores transactions at the field level. If Transaction Logging is turned on, and if an action occurs, then Siebel Remote stores only those changes that have occurred to fields as transactions. This configuration helps to optimize the synchronization process.

2. The Transaction Processor server component does the following work:
   • Copies the transactions that exist in the S_DOCK_TXN_LOG table to the docking\txnproc directory.
   • Copies the file system transactions that are of type External File from the file system to the docking\txnproc directory.
   • Clears the S_DOCK_TXN_LOG table of the transactions.
3. The Transaction Router server component determines which users must receive the transactions that the docking\txnproc directory contains.
4. The first time Siebel Remote extracts a database for a user, it creates a docking directory on the Siebel Server for that user. It does the following work:
   1. Creates an inbox and an outbox. The outbox stores any future extracts and DX files that Siebel Remote receives from the Transaction Router.
   2. Sends these DX files to the outbox for each remote client that exists in the docking directory on the Siebel Server, according to visibility rules and routing rules.
   3. After the Transaction Router finishes the task it is processing, it instructs the Transaction Processor server component to purge any DX files that exist in the docking\txnproc directory, as determined by the following Transaction Processor parameter:

   Clean .dx files iterations

5. When you install a Siebel application you specify at least one Siebel Server as a remote server. This Siebel Server hosts all or some of the users and it contains the docking directories for these users. It uses these directories to transfer the files that are involved with the synchronization process. These files include the following items:
   • New database templates that the Generate New Database task creates
   • Database extracts that Siebel Remote uses with the templates to initialize the local database
   • DX files (.dx)
   • TOC files (.toc)
   • Visibility data for the remote client. This data resides in the visdata.dbf file and the dobjinst.dbf file.
6. The remote client processes any transactions that exist in the local database while in disconnected mode.

   Siebel Remote stores a copy of each transaction in the Local Transaction Log, which is similar to the Master Transaction Log on the Siebel Server. It does not create any audit trail records on the disconnected client. If a Siebel application uses Siebel Audit Trail, then it eventually uses the information that it stores about disconnected transactions to create audit trail records on the Siebel Server.

7. If the user starts the synchronization process, then the remote client creates DX files from the log and then moves these DX files to the remote client outbox.
8. The synchronization process begins when the remote client starts a synchronization session.

   The Synchronization Manager server component must be running. It authenticates the remote client, as determined by the type of authentication that the parameters for the Synchronization Manager specify.

   The synchronization process includes handling communication between the remote client and the file system. It moves the DX files from the outbox of the docking directory to the inbox of the remote client. It also moves files from the outbox of the remote client to the inbox of the docking directory. It copies any attachments, correspondence, or templates that the remote client creates to the Siebel File System.

9. Depending on the user synchronization options or command line options that you choose, the remote client applies the DX files to the local database as soon as it receives the first transaction file or after it completes the file exchange with the Siebel Server. Changes do not occur in the server database until after the file exchange finishes and the remote client disconnects.
10. The Transaction Merger server component on the Siebel Server pulls the DX files from the inbox in the Docking Directory.
11. The Transaction Merger applies the changes to the server database.

    If your Siebel application uses Siebel Audit Trail, then the Transaction Merger places information about disconnected transactions that synchronize successfully to the server database tables that Siebel Audit Trail uses.

    The Transaction Merger also identifies synchronization conflicts. To determine if the Siebel Server or the remote client wins during conflict resolution, the System Conflict Resolution system preference uses one of the following values:

    • Server Wins
    • Client Wins

      Siebel Remote communicates any conflicts that exist to the user during the next synchronization.

      The Transaction Merger deletes any DX files that reside in the inbox in the Docking directory.

      The Transaction Merger does not create audit records for a disconnected transaction that does not synchronize. If the user approves a disconnected transaction for which Siebel Remote detects a conflict, then the Transaction Merger creates audit information on the Siebel Server when the user approves the transaction.

Options for Configuring a Remote Client

You can use the following options when you configure a remote client:

• DockConnString. A parameter in the CFG file that specifies how to synchronize to the Siebel Server. For more information, see Formatting the DockConnString Parameter.
• AutoStopDB. A parameter in the CFG file that instructs Siebel Remote to automatically shut down the local database if the Siebel application shuts down. For more information, see AutoStopDB Parameter.
• Parameters on the Connect String. For more information, see Setting Parameters on the Connect String of the Local Database.
• Sort Order. Determines the sort order of the SQL Anywhere database. For more information, see Configuring the Sort Order.
• EIM. For more information, see Using EIM to Create Multiple Siebel Remote Clients.

How TrickleSync Manages Synchronization Frequency

TrickleSync is a feature that improves usability by increasing how frequently Siebel Remote synchronizes. Frequent synchronization decreases transaction volume for each session and shortens the average connect time. After you initialize the local database, the user can use the DB Synchronization view of the User Preferences screen to enable or disable TrickleSync. It is recommended that the user synchronize with the Siebel Server at least daily.

To perform automatic synchronization when connected to the network, the TrickleSync agent runs in the background at scheduled times. You can enable a synchronization reminder that prompts the user to synchronize if a specified period of time passes without a synchronization session. The user can call TrickleSync from the remote client or you can configure TrickleSync for the user. In earlier Siebel CRM versions, TrickleSync was known as autosynchronization. For more information, see Configuring TrickleSync.