Siebel Remote and Replication Manager Administration Guide > About Siebel Remote > Local Database Creation and Synchronization >

Local Database Synchronization


This topic describes how Siebel Remote synchronizes a local database.

Route and Merge

Figure 5 illustrates how routing and merging synchronizes a remote client.

Figure 5. How Routing and Merging Synchronizes a Remote Client
Explanation of Callouts

To synchronize an existing remote client, the user starts the Siebel Remote client. Siebel Remote does the following work:

  1. Connect. To connect to the Siebel Server, Siebel Remote does one of the following:
    • If the user specifies to use a modem, then Siebel Remote uses connection information from the Windows phone book to dial the modem. After it establishes network connectivity, the remote client connects to the Siebel Server.
    • If the remote client is already connected through a LAN or WAN connection, then Siebel Remote performs a handshake to validate that a network connection exists.
  2. Validate the remote client and examine the version. Synchronization Manager does the following:
    • Validates the remote client:
      • Validates the name of the remote client with the list of valid users that exist in the server database.
      • Verifies that the remote client is connected to the correct Siebel Server. If it is not, then Synchronization Manager reconnects the remote client to the appropriate server and then updates the local configuration information on the remote client.
      • If authentication for Siebel Remote is turned on, then the Synchronization Manager authenticates the remote client credentials.
    • Examines the version:
      • To make sure the remote client runs the most up to date version of the Siebel application, it uses data on the Siebel Server.
      • If the remote client is not running the most up to date version, then it prompts the user to download a new version of the Siebel application.
  3. Examine database extract. Synchronization Manager does the following:
    • Determines if a database extract is pending for the remote client.
    • If a database extract is not pending, then the synchronization session continues.
    • If a database extract is pending, then to reinitialize the remote client, the Synchronization Client uses the same process that is described in Local Database Initialization. In this situation, another synchronization session begins.
  4. Retrieve and send transactions and file attachments. The remote client does the following work:
    • Retrieves transactions and file attachments:
      • Retrieves transaction files that the Transaction Router creates. It creates these files from the outbox directory for the remote client that resides on the Siebel Server.
      • Stores the transaction files in the local inbox directory on the remote client.
      • Retrieves from the Siebel File Server any file attachments that the user requests, publishes, or broadcasts.
    • Sends transactions and file attachments:
      • Extracts pending transactions from the local transaction log to the transaction files.
      • Sends the transaction files to the user inbox directory on the Siebel Server.
  5. Apply changes to the server database. The Transaction Merger applies the incoming transaction files from the user inbox directory on the Siebel Server to the server database, and then applies retrieved file attachments to the Siebel File System.
  6. Apply changes to the local database. The remote client does the following work:
    • Applies the incoming transaction files from the inbox directory on the remote client to the local database
    • Applies retrieved file attachments to the local file system

      The user can use the remote client while this client applies changes to the local database.

      The timing for applying the incoming transactions depends on the options that you choose. By default, the remote client begins applying transactions as soon as Siebel Remote downloads the first transaction file. To configure the remote client to apply transactions only after download finishes or to postpone applying transactions until a later time, you can do the following:

    • Use command line options. For more information, see Using the Stand-Alone Synchronizer.
    • Use synchronization options. For more information, see Synchronizing the Remote Client.
  7. Disconnect. Siebel Remote closes the connection with the Siebel Server and then does one of the following:
    • If the remote client created the network connection automatically, then it disconnects the modem.
    • If the remote client did not create the network connection automatically, then the user can manually disconnect from the network.
  8. Clean up on the remote client. The remote client deletes any transaction files that exist in the local outbox directory on the remote client. These are files that the Transaction Merger successfully applied to the server database during the previous synchronization session.
  9. Clean up on the server. On the Siebel Server, the Synchronization Manager deletes any transaction files that exist in the outbox directory for the remote client that Siebel Remote successfully applied to the local database during the previous synchronization session.

How Siebel Remote Minimizes Connect Time

To minimize the connect time between the remote client and the Siebel Server, the Transaction Router and Transaction Merger server components continuously route and apply transactions for remote clients. These server components process data asynchronously from the synchronization sessions:

  • One or more tasks of the Transaction Router continuously route outgoing transactions to the outbox directories of the remote client. These transactions exist in the txnproc directory. The Transaction Processor creates these transactions.
  • One or more tasks of the Transaction Merger continuously merge incoming transactions from the inbox directories of the remote client to the server database and the Siebel File System.
Siebel Remote and Replication Manager Administration Guide Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices.