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

How Siebel Remote Propagates Changes to a Local Database

Between synchronization sessions, the Siebel Server prepares transactions that other users apply to the server database. Server components on the Siebel Server write these transactions to a separate directory for each user. Siebel Remote downloads these transactions and other items from the file system to the remote client during the next synchronization session. Items in the file system include updated, published, or requested marketing literature, correspondence templates, and other types of file attachments. A similar process occurs on the remote client, although without the server component.

Scenario for Propagating Changes with a Connected User

This topic gives one example of how Siebel Remote propagates changes that a connected user makes. You might use Siebel Remote differently, depending on your business model. It describes how Siebel Remote downloads changes from the server database to the local database, covering the steps that occur from when a connected user creates a new opportunity until Siebel Remote displays this opportunity in the local database. This scenario includes a telesales user who works in a Call Center. This user talks with a potential customer who is responding to a new advertising campaign.

Figure 6 illustrates the scenario for propagating changes with a connected user.

Figure 6. Scenario for Propagating Changes with a Connected User

Explanation of Callouts

Propagating changes with a connected user includes the following steps:

1. The telesales person is a user who creates a new opportunity. Siebel Remote saves this opportunity as a transaction in the opportunities table on the server database. It saves a copy to the master transaction log.
2. The Transaction Processor copies this transaction and other transactions to the Siebel Server.
3. A Transaction Router task writes each transaction from the txnproc directory to transaction files in separate outbox directories for each remote client. Siebel Remote stores the outbox directories of the remote client on the Siebel Server.
4. The user starts a synchronization session from the remote client.

   To download the new opportunity to the local database during the synchronization session, steps Step 5 through Step 11 occur.

5. To connect to the Siebel Server, the remote client uses an existing modem or LAN connection to dial the modem.
6. The remote client connects to the Siebel Server.
7. The Siebel Server starts the synchronization session for the remote client.
8. The Synchronization Manager validates the node name of the remote client with the list of valid users that exist in the server database. The remote client receives transaction files that Siebel Remote routes to and from the Siebel Server. It also retrieves file attachments.
9. The remote client retrieves transaction (.dx) files from the user outbox directory that resides on the Siebel Server, and then stores them in the local inbox directory that resides on the remote client. The remote client also retrieves from the Siebel File Server any requested, published, or broadcasted file attachments.
10. Siebel Remote inserts the new opportunity in the opportunity table in the local database.
11. The remote client closes the connection with the Siebel Server. The user can use the remote client while it applies changes to the local database.

Scenario for Propagating Changes with an Unconnected User

This topic gives one example of how Siebel Remote propagates changes that an unconnected user makes. You might use Siebel Remote differently, depending on your business model. This scenario describes how Siebel Remote uploads changes from the local database to the server database. This scenario includes a telesales user who works in a Call Center. This representative is meeting with a potential new customer, which Siebel Remote represents as an existing opportunity in the local database. Another user created this opportunity at an earlier time and then uploaded it to the Siebel Server during a synchronization session. The telesales user then downloaded it during a subsequent synchronization session.

Figure 7 illustrates the scenario for propagating changes with an unconnected user.

Figure 7. Scenario for Propagating Changes with an Unconnected User

Explanation of Callouts

Propagating changes with an unconnected user includes the following steps:

1. The user makes changes to an existing opportunity in the local database. The user enters these changes immediately after meeting with the potential customer while working offline.
2. Siebel Remote saves the modified opportunity to the opportunities table in the local database.
3. Siebel Remote saves a transaction record to the Local Transaction Log.
4. Siebel Remote extracts pending transactions from the Local Transaction Log to transaction dx files. It then places these DX files in the outbox directory on the remote client.
5. The user starts a synchronization session from the remote client.

   To record the changes that occur to the opportunity during this session, Step 6 through Step 12 occur.

6. To connect to the Siebel Server, Siebel Remote dials the modem. If the user is in the office, then Siebel Remote can use a LAN connection.
7. The remote client connects to the Siebel Server.
8. The Siebel Server starts the synchronization session for the user.
9. Synchronization Manager validates the remote client name with the list of valid clients that exist in the server database.
10. Synchronization Manager sends any transaction files that exist in the user outbox directory on the remote client to the user inbox directory on the Siebel Server.
11. Siebel Remote closes the connection with the Siebel Server.
12. Siebel Remote inserts the modified opportunity in the opportunity table on the server database.

How Siebel Remote Manages the Size of the Local Database

The following factors determine the recommended size for the SQL Anywhere local database:

• The position and responsibilities that the remote client requires. For more information, see Impact of Positions, Organizations and Responsibilities.
• The Data Routing Model. The Data Routing Model that Siebel Remote assigns to the remote client impacts the volume of data that it stores in the local database.

A typical mobile user requires about 200 to 350 MB of storage space. Some users require 700 MB to 1 GB of storage space. Although there is no physical limitation until about 4 GB, it is recommended that the local database be no larger than 700 MB. In general, the following benefits exist with a smaller local database:

• Less time required to extract and synchronize
• Improved application performance

For more information about reducing the size of the local database, review this guide for features that prevent the synchronization of unnecessary data. For example, for information about time filtering, see Using Time Filters to Prevent Sending Old Data. For help with reducing the size of the local database, see Troubleshooting a Merge Problem.

How Siebel Remote Handles File Attachments

If a user attaches a file to a record in the local database, then Siebel Remote does the following work:

• Stores the metadata for this file in the local database
• Stores the file in the local Siebel File System

If the remote user synchronizes with the Siebel Server, then Siebel Remote copies the file to the Siebel File System on the Siebel Server. It also copies the metadata to the server database.

If another remote user accesses the record to which the file is attached, then Siebel Remote transfers the metadata for the file to the local database of that user the next time the user synchronizes. Siebel Remote does not transfer the file attachment to the local Siebel File System unless the user specifically requests the file. Some types of file attachments include a Distribution Method setting. For example, a Literature item. If the Distribution Method is set to Publish, then Siebel Remote automatically transfers the file to the user.

To request a file attachment, a remote user can click the link for the attachment in a Siebel application or choose the Request File check box for the attachment. In this situation, Siebel Remote queues the request for the file. To receive the file, the remote user must synchronize again, which instructs Siebel Remote to copy the file to the local Siebel File System. When the synchronization finishes the user must click the link again to view the file.