Siebel Remote and Replication Manager Administration Guide > Architecture of Siebel Remote > How Siebel Remote Uses Siebel Servers >

Server Components That Siebel Remote Uses

Table 5 lists some of the server components that Siebel Remote uses. For more information, see Server Component Parameters.

For deployments of Siebel Remote or Siebel Replication Manager, you must enable both the Siebel Remote component group and the Disconnected Mobile Synchronization component group on the same Siebel Server.

The MobileSync component group, which is new for Siebel Innovation Pack 2014 and later, includes components used by Siebel Remote, Siebel Replication Manager, and the Siebel Mobile disconnected applications. The following four components moved from the Siebel Remote component group into the MobileSync component group: Database Extract, Parallel Database Extract, Transaction Processor, and Transaction Router.

Generate New Database Server Component

The Generate New Database server component (alias GenNewDb) creates the local database template for a schema version of the server database. It reads the schema definition from the Siebel runtime repository, and then creates Siebel tables and indexes in a database template file that Siebel Remote stores in the SIEBEL_ROOT\dbtempl folder. The Local Database Initialization program uses the local database template when it initializes a new database on the remote client. For more information, see Running the Generate New Database Server Component.

Dictionary Data That Supports Multiple Languages

The dicdata.dat file and the diccache.dat file are the same dictionary file. Siebel Remote names the dicdata.dat file differently for the remote client. These files store metadata about schema definitions, visibility rules, and other items. The Generate New Database server component copies the diccache.dat file to the dicdata.dat file in the dbtempl folder. Siebel Remote downloads the dicdata.dat file to the remote client, and then uses it during synchronization when it applies transactions to the local database. For help with interchanging the dicdata.dat file between remote clients to support different languages, see Getting Help from Oracle.

Database Extract Server Component

The Database Extract server component (alias DbXtract) creates a snapshot file of the server database for each user. This file contains the data that Siebel Remote uses to initialize the local database. Database Extract gets data according to routing rules that define the level of access to information for each remote client. For more information, see Extracting the Server Database, and Extracting Regional Databases in Parallel.

Synchronization Manager Server Component

The Siebel Server starts a task for the Synchronization Manager server component (alias SynchMgr) for each incoming synchronization request that it receives from a remote client. This task does the following work for each request:

• Verifies the status and credentials of the remote client, provided that authentication for Siebel Remote is enabled. Credentials include user ID and password.
• Transfers the local database template and local database extract, if applicable.
• Exchanges transaction files.
• Transfers file attachments to and from the Siebel File Server.

Each Synchronization Manager task services only one remote client at any one time. The Siebel Server can run multiple synchronization tasks concurrently. You can use the Max Task parameter of the Synchronization Manager server component to configure this behavior. You must configure the Synchronization Manager for the user to allow the remote client to connect to the Siebel Server. Siebel Remote starts tasks for Synchronization Manager automatically. It is not necessary for you to manually start these tasks.

The Siebel File System parameter of the Synchronization Manager server component identifies the location of the file system for the remote client.

Transaction Processor Server Component

The Transaction Processor server component (alias TxnProc) scans the master transaction log of the Siebel database, and then prepares transactions for the Transaction Router server component. A single Transaction Processor process runs on each Siebel Remote server where there are active nodes to be routed. The prepared transactions are saved as DX files in the docking\txnproc folder.

Transaction Router Server Component

The Transaction Router server component (alias TxnRoute) examines the transactions that the Transaction Processor saves as DX files in the docking\txnproc folder. It determines visibility and routing for each transaction. Routing rules determine the dock object instances that Siebel Remote copies to each remote client. After Transaction Router has processed the DX files, they are automatically purged. For more information, see Optimizing the Transaction Router Server Component.

Transaction Merger Server Component

The Transaction Merger server component (alias TxnMerge) applies transactions to the Siebel Database that the user uploads to the Siebel Server inbox. It applies these transactions to the server database after the synchronization finishes and the remote client disconnects. For more information, see Optimizing the Transaction Merger Server Component.

How Siebel Remote Makes Sure Server Components Can Run Concurrently

Siebel Remote uses the following rules and behaviors to make sure server components can run successfully in a concurrent environment:

• The Transaction Processor server component can run while any other server component runs.
• Each Siebel Server can use only one Transaction Processor.
• Only one instance of the Transaction Router, Transaction Merger, Synchronization Manager, or Database Extract server components can process a remote client at any one time:
  • Two Transaction Router server processes cannot route transactions to the same remote client at the same time.
  • Two Transaction Merger processes cannot merge transactions from the same remote client at the same time.

    To improve performance, multiple instances of these server components can run on one Siebel Server.

• The following server components cannot process a remote client while a database extract is in progress for that client:
  • Transaction Router
  • Transaction Merger
  • Synchronization Manager
• If a Transaction Router, Transaction Merger, or Synchronization Manager resides on the same Siebel Server, then they can process the same remote client at the same time.
• Multiple instances of Database Extract that run at the same time allow Siebel Remote to extract multiple lists of users. This configuration reduces the duration of the overall extract.

About Redundant Disks on the Siebel Server

Each Siebel Server manages a distinct group of users that Siebel Remote assigns to this server. Other applications, such as Oracle's Enterprise Integration Manager (EIM), might run on the same Siebel Server. To maintain a high level of integrity and availability, the Siebel Server provides an interim storage area for the data that Siebel Remote requires to synchronize a local database with the Siebel database. It is recommended that you use a redundant disk configuration for the Siebel Server. Using redundant disk configuration reduces the likelihood that malfunctioning hardware will result in a loss of data on the Siebel Server. If a malfunction does occur, then you can reextract the remote clients that are registered on the affected Siebel Server.