3Architecture of Siebel Remote
Architecture of Siebel Remote
This chapter describes the architecture that Siebel Remote uses. It includes the following topics:
Overview of the Siebel Remote Architecture
The following diagram illustrates the components of the Siebel Remote architecture.
Explanation of Callouts
The Siebel Remote architecture includes the following components:
Siebel database (server database). A database that stores information about the organizational structure of your company, job responsibilities, sales personnel, sales territories, accounts, sales opportunities, contacts, product lines, and so on. It stores data for users who use a stationary client or a remote client. It contains the following items:
Metadata for a Siebel application
Tables that store user data for a Siebel application
A master transaction log table that stores modifications made since the last database extraction
Siebel File System. A folder structure that includes items like the following:
Siebel Encyclopedia items
Correspondence templates
File attachments
Other files that support client access and download
The Siebel Server must possess network connectivity to the Siebel File System that might be located on another Siebel Server on the network, or that Siebel CRM uses with the Siebel database. For more information, see How Siebel Remote Handles Files on Remote Clients.
Database Configuration Utilities. You use the Siebel Enterprise Server installer to install these utilities on a Siebel Server. You typically use an ODBC driver and the connectivity package for the database vendor to create the connectivity that these utilities require for their operations, as well as for subsequent operations that involve the Siebel database. You must provide this access over a 100 MB or faster network connection, such as Fast Ethernet or FDDI, due to the amount of data that is exchanged. For more information, see Installing the Database Configuration Utilities and the Regional Siebel Database on the Regional Node.
Siebel Server. A Siebel Server that runs the server components that Siebel Remote uses to manage synchronizations with the remote client. For more information, see How Siebel Remote Uses Siebel Servers.
LAN, WAN, or VPN. The hardware and software that allows the remote client to communicate with the Siebel Server. The remote client uses the TCP/IP networking protocol to communicate with the Siebel Server. You can use the following types of networks:
Local Area Network (LAN)
Wide Area Network (WAN)
Virtual Private Network (VPN)
Software on remote client. For more information, see How Siebel Remote Uses Mobile Web Clients.
Remote client. A computer that runs a Siebel application that uses a local database and a local file system. The Siebel object definitions are stored in the Siebel database for the Siebel Mobile Web Client. For more information, see How Siebel Remote Uses Mobile Web Clients.
How Siebel Remote Flows Data Through the Architecture
The following diagram illustrates the flow of data through the architecture for Siebel Remote. For more information about the server components and files that this architecture uses, see How Siebel Remote Uses Siebel Servers.
Explanation of Callouts
Data flows through the Siebel Remote architecture in the following sequence:
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 does 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 the modifications that occurred to fields as transactions. This configuration helps to optimize the synchronization process.
For more information, see Modifying the S_DOCK_TXN_LOG Table.
The Transaction Processor server component does the following work:
Copies the transactions that exist in the S_DOCK_TXN_LOG table to the
docking\txnprocfolder.Copies the file system transactions that are of type External File from the file system to the
docking\txnprocfolder.Clears the S_DOCK_TXN_LOG table of the transactions.
The Transaction Router server component determines the users who must receive the transactions that the
docking\txnprocfolder contains.Siebel Remote creates a docking folder on the Siebel Server for the user the first time that it extracts a database for this user. It does the following work:
Creates an inbox and an outbox folder. The outbox stores any future extracts and DX files that Siebel Remote receives from the Transaction Router.
Sends these DX files to the outbox for each remote client that resides in the
dockingfolder on the Siebel Server, according to visibility rules and routing rules.The Transaction Router finishes the task it is processing, and then configures the Transaction Processor server component to remove any DX files that exist in the
docking\txnprocfolder, according to the following Transaction Processor parameter: Clean DX Files Iterations (alias CleanFilesIter)
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 folders for these users. It uses these folders 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 visibility database file.
The remote client processes any transactions that exist in the local database while disconnected.
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. 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.
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.
The synchronization process begins when the remote client starts a synchronization.
The Synchronization Manager server component must be running. It authenticates the remote client according to 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 folder to the inbox on the remote client. It also moves files from the outbox on the remote client to the inbox of the docking folder. It copies any attachments, correspondence, or templates that the remote client creates to the Siebel File System.
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, depending on the user synchronization options or command line options that you choose. Siebel Remote does not modify the server database until the file exchange finishes and the remote client disconnects.
The Transaction Merger server component on the Siebel Server pulls the DX files from the inbox in the docking folder.
The Transaction Merger applies the modifications 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. The System Conflict Resolution system preference uses one of the following values to determine if the Siebel Server or the remote client wins during conflict resolution:
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 folder.
The Transaction Merger does not create audit records for a disconnected transaction that does not synchronize. If the user approves a disconnected transaction that Siebel Remote detects as a conflict, then the Transaction Merger creates audit information on the Siebel Server when the user approves the transaction.
How Siebel Remote Uses Siebel Servers
This topic describes how Siebel Remote uses the Siebel Server. For a visual representation of where some of the components that this topic describe reside on the Siebel Server, see How Siebel Remote Flows Data Through the Architecture.
About the Siebel Enterprise and the Siebel Enterprise Server
A Siebel Enterprise is a system that includes all users on all Siebel Servers in an environment that includes multiple Siebel Servers. The Siebel Enterprise Server is a logical grouping of Siebel Servers that support a group of users who access a common server database in a multiple server environment. You can configure, manage, and monitor the Siebel Servers that the Siebel Enterprise Server contains as a single, logical group that allows you to start, stop, monitor, or set parameters for all of these servers. For an example of a Siebel Enterprise, see the figure in Hierarchy of a Siebel Replication Manager Implementation. For more information, see Siebel System Administration Guide.
Server Folders That Siebel Remote Uses for Remote Clients
Siebel Remote uses a separate folder and subfolders that reside on the Siebel Server for each registered remote client. The Database Extract server component creates these folders.
txnproc in the
SIEBEL_ROOT\docking folder. You must not modify the contents of this folder under any circumstances.
The following example includes a portion of the tree of the Siebel Server folder after Siebel Remote extracts databases for remote clients named Adams and Scott:
siebel
docking
adams
inbox
outbox
scott
inbox
outbox
txnproc
Server Components That Siebel Remote Uses
The following table 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 components moved from the Siebel Remote component group into the MobileSync component group: Database Extract, Parallel Database Extract, Transaction Processor, and Transaction Router.
Table Server Components That Siebel Remote Uses
| Server Component | Alias | Log File Name |
|---|---|---|
Siebel Remote component group (alias Remote) |
||
Generate New Database |
GenNewDb |
GenNewDb_taskId.log |
Replication Agent |
RepAgent |
RepAgent_taskId.log |
Synchronization Manager |
SynchMgr |
SynchMgr_taskId.log |
Transaction Merger |
TxnMerge |
TxnMerge_taskId.log |
Disconnected Mobile Synchronization component group (alias MobileSync) |
||
Database Extract |
DbXtract |
DbXtract_taskId.log |
Parallel Database Extract |
PDbXtract |
Not applicable |
Transaction Processor |
TxnProc |
TxnProc_taskId.log |
Transaction Router |
TxnRoute |
TxnRoute_taskId.log |
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.
How Siebel Remote Uses Mobile Web Clients
The Mobile Web Client is a disconnected Siebel CRM client that is fully functional. It typically runs on a laptop computer that a professional in the field uses. For brevity, this book refers to the Mobile Web Client generically as the remote client, and the person who uses this remote client as the user. The remote client includes the following items:
Local Database and file system
Local Database Initialization Program
This local database and file system contain data and files that Siebel Remote synchronizes with the database and the Siebel File System that reside on the Siebel Server. The remote client manages this synchronization process. It communicates directly with the Synchronization Manager server component on the Siebel Server during synchronization.
The Siebel application that runs on a remote client runs in a typical Web browser. The architecture layers of a Siebel application, including the local database and file system, reside on the remote client and run business logic locally. This architecture requires you to install Siebel CRM on each client computer.
The remote client includes a lightweight HTTP listener that listens on a dynamic port for HTTP requests from the local computer. Siebel Remote ignores requests from other computers on the network. Minimal security risk exists when the user uses the Siebel application on the network.
How Siebel Remote Handles Files on Remote Clients
The Siebel File System is a file system that stores attachments, correspondence, templates, and other types of unstructured data for the user. It uses the File System Manager server component. A connected user accesses files from the Siebel File System. A connected user is a user who connects directly to the Siebel Server. The Siebel Server can transfer files between the user and the file system during synchronization.
The File System Manager server component manages the Siebel File System, handles interplatform security, and handles most of the interactions with the Siebel File System that resides in the Siebel application. The Synchronization Manager server component also interacts with the Siebel File System during a synchronization. The Web Client, Developer Web Client, and server components that use these files can use the Server Request Broker to make requests to the File System Manager.
The local database is a database that resides on the remote client. It contains Siebel application tables that store user data and a local transaction log that stores transactions that the user creates. Siebel Remote copies these transactions to the Siebel Server when the remote client synchronizes.
The Siebel Server sends the Siebel File System files that reside on this server to the local Siebel File System that resides on the remote client. The remote client uses these local files when the user disconnects from the Siebel Server. During synchronization, Siebel Remote uploads any files that the user added to the local Siebel File System while disconnected. It uploads these files to the Siebel File System that resides on the Siebel Server. The user can also request files to download to the local file system during synchronization. You can specify the files that Siebel Remote publishes or distributes to users. For more information, see Siebel System Administration Guide.
Requirements for Remote Clients
The following requirements are mandatory for the remote client:
Each remote client must use exactly one local database at any one time.
Only one user can access the local database at any one time. Siebel Remote does not support multiple logins.
You must not rename any folder that contains software for the remote client.
You must not rename or delete any DX file.
You must not directly modify the local transaction log under any circumstances.
To optimize performance, it is recommended that the user defragment the local hard drive regularly. For more information, see the defragment policies for your company.
Configuration Options That You Can Specify for Remote Clients
You can specify the following options when you configure a remote client:
DockConnString. A parameter in the configuration file that specifies how to synchronize to the Siebel Server. For more information, see Modifying the Siebel Configuration File for Siebel Remote and Formatting the DockConnString Parameter.
EIM. For more information, see Using EIM to Create Multiple Siebel Remote Clients.
Synchronization Options That Users Can Choose
The user can do one of the following to synchronize the remote client:
Background synchronization. The user chooses the File menu, and then the Synchronize Database menu item while the remote client is running. This action starts the remote client as a background process so that the user can continue to use a Siebel application or other Windows applications during the synchronization process.
Stand-alone synchronization. The user uses the Siebel Remote icon or a scheduling program from a third party. This action allows the user to synchronize without starting the Siebel application. TrickleSync also does a stand-alone synchronization when it starts a synchronization session. For more information, see How Siebel Remote Uses TrickleSync to Manage Synchronization Frequency.
For more information, see How Siebel Remote Synchronizes Local Databases.
How Siebel Remote Uses TrickleSync to Manage 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. 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.
The TrickleSync agent runs in the background at scheduled times to do an automatic synchronization when the remote client is connected to the network. You can enable a synchronization reminder that prompts the user to synchronize if a specified period of time expires without doing a synchronization. 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.
Visibility Modifications That Affect Access to Records
Siebel Remote does not typically lose transactions after a client reextract. However, if a visibility modification exists that prevents the user from accessing a record in the future, then any transactions that the user makes to this record that Siebel Remote has not synchronized are lost when it reextracts the user. For information about saving client transactions, see Extracting the Server Database.
Remote Client Usage in a Development Environment
The software that you install for the Mobile Web Client is the same software that you install for the Developer Web Client in earlier releases. Oracle only supports the Developer Web Client in a test environment. The installation program requires more input to install a Developer Web Client than it does to install a Mobile Web Client. If you do all the setup steps for the Developer Web Client that you typically do for a Mobile Web Client, including registering the user as a Mobile Web Client and extracting a local database, then the Developer Web Client uses the local database and local Siebel File System and you can use it in a test environment the same way that you use a Mobile Web Client in a production environment. You must also modify the configuration file that the Developer Web Client references so that it uses test versions of the server database and the Siebel File System. For more information, see Modifying the Siebel Configuration File for Siebel Remote.
How Siebel Remote Creates Local Databases
This topic describes how Siebel Remote creates, extracts, and initializes the local database.
When you configure a Siebel Server for the first time, you must create a new database template, which is a database that contains no user data but that contains the structure that Siebel Remote uses to work with a Siebel application. You run the Generate New Database server component to create a new database template. This server component creates a template and places it in the dbtempl folder on the Siebel Server. For more information, see Running the Generate New Database Server Component.
The user must exist in Siebel CRM as a user before Siebel Remote can register this user. For information on adding a user to Siebel CRM, see Siebel Applications Administration Guide.
How Siebel Remote Extracts Local Databases
The first step in creating a local database for a new user is to extract the server database on the Siebel Server. You run the Database Extract server component to extract a remote client. It extracts visible data for the user to a snapshot file in the outbox folder of the Web client on the Siebel Server. This extract gets data according to the routing rules that define the level of access to information for each remote client. It creates compressed files that contain data that Siebel Remote loads to a local database when the remote client starts a synchronization with the server database. Each local database is unique. A user cannot use multiple computers with the same remote client.
The following diagram illustrates how Siebel Remote extracts a local database.
Explanation of Callouts
Siebel Remote does the following work to extract a local database:
Prompt for connect information. Prompts the user to enter the user ID, the name of the remote client, and a password. A user might use multiple clients, such as two clients on two separate computers. If the user starts the remote client to initialize the database, then Siebel Remote sets the user ID to the value that the user provides, by default.
Connect. Siebel Remote does the following work:
If the user can access the Siebel Server, and if the port for the Synchronization Manager is open, then the Synchronization Client connects to the Siebel Server.
Siebel Remote starts a new synchronization thread for the remote client. For example, a VPN setup might require the user to enter a special PIN (personal identification number) and security number.
Validate remote client. The Synchronization Manager does the following work:
Validates the node name of the remote client with the list of valid users that exist in the server database.
Makes sure that the remote client is connected to the correct Siebel Server.
If authentication for Siebel Remote is turned on, then it authenticates the remote client credentials.
Confirm status of database extract. The Synchronization Manager does the following work:
Verifies that a database extract is pending in the outbox on the Siebel Server.
Determines if UAF files or TOC files exist in the outbox folder for the user. If it does not find these files, then the Synchronization Client prompts the user to contact the Siebel administrator to do a database extract.
Download snapshot and file attachments. Prompts the user to download a new database. The Synchronization Client downloads the extract and file attachments to the inbox folder on the remote client.
Disconnect. The Synchronization Client closes the connection with the Synchronization Manager. The user can disconnect from the network.
Create and load database. The Synchronization Client shuts down the Siebel Remote remote client or program, and then starts the Siebel Upgrade Wizard. This wizard does the following work:
Creates a new local database
Loads data from the extract file to the local database
Applies file attachments to the local file system
For more information, see Initializing the Local Database.
How Siebel Remote Initializes Local Databases
If Siebel Remote determines that all of the following items are true, then it does an initialization:
A user logs in for the first time.
A local database does not exist.
The user specifies the local database as the data source.
Initialization is the process of configuring a remote client. This work includes making sure connect information is correct, validating that the remote client is connected to the correct Siebel Server, extracting a database to a new local database, and so on.
How Siebel Remote Synchronizes Local Databases
This topic describes how Siebel Remote synchronizes local databases. It includes the following information:
For more information, see How Siebel Remote Manages the Amount of Data It Synchronizes.
Overview of How Siebel Remote Synchronizes Local Databases
The following diagram illustrates how Siebel Remote synchronizes the data that a local database contains with the data that the server database contains.
Explanation of Callouts
Siebel Remote does the following work to synchronize the remote client any time a user logs into an existing client:
Connect. Siebel Remote does one of the following:
If the remote client is connected to the Siebel Server through a LAN, WAN, or VPN connection, then Siebel Remote does a handshake to validate that a network connection exists.
Validate the remote client and examine the version. Synchronization Manager does the following work:
Validates the remote client:
Validates the remote client name with the list of valid remote client names 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 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. Synchronization Manager uses data on the Siebel Server to make sure the remote client runs the current version of the Siebel application. If the remote client is not running the current version, then Synchronization Manager prompts the user to download a new version of the Siebel application.
Examine database extract. Synchronization Manager does the following work:
Determines if a database extract is pending for the remote client.
If a database extract is not pending, then the synchronization continues.
If a database extract is pending, then the Synchronization Client uses the process described in How Siebel Remote Initializes Local Databases to reinitialize the remote client. Siebel Remote starts another synchronization in this situation.
Get and send transactions and file attachments. The remote client does the following work:
Gets transactions and file attachments:
Gets transaction files that the Transaction Router creates. It creates these files from the outbox folder of the remote client that resides on the Siebel Server.
Stores the transaction files in the local inbox folder on the remote client.
Gets any file attachments from the Siebel File Server 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 folder that resides on the Siebel Server.
Apply modifications to the server database. The Transaction Merger applies the incoming transaction files from the user inbox folder that resides on the Siebel Server to the server database, and then applies retrieved file attachments to the Siebel File System.
Apply modifications to the local database. The remote client does the following work:
Applies the incoming transaction files from the inbox folder that resides on the remote client to the local database that resides on the remote client
Applies retrieved file attachments to the local file system that resides on the remote client
The user can use the remote client while this client applies modifications to the local database.
The timing for applying the incoming transactions depends on the options that you choose. The remote client begins applying transactions as soon as Siebel Remote downloads the first transaction file, by default. You can do the following to configure the remote client to apply transactions only after download finishes, or to postpone applying transactions until a later time:
Use command line options. For more information, see Using the Stand-Alone Synchronizer.
Use synchronization options. For more information, see Synchronizing the Remote Client.
Disconnect. Siebel Remote closes the connection with the Siebel Server, and then does one of the following, depending on whether the remote client created the network connection automatically:
Created connection automatically. It closes the connection.
Did not create connection automatically. The user can manually disconnect from the network.
Clean up on the remote client. The remote client deletes any transaction files that exist in the local outbox folder on the remote client. These are files that the Transaction Merger successfully applied to the server database during the previous synchronization.
Clean up on the server. The Synchronization Manager deletes any transaction files that exist in the outbox folder on the Siebel Server for the remote client that Siebel Remote successfully applied to the local database during the previous synchronization.
How Siebel Remote Minimizes Connect Time
The Transaction Router and Transaction Merger server components continuously route and apply transactions for remote clients. It does this work to minimize the connect time that occurs between the remote client and the Siebel Server. These server components process data asynchronously from the synchronization sessions. One or more Transaction Router tasks continuously do the following work:
Route outgoing transactions to the outbox folders that reside on the remote client. These transactions reside in the
docking\txnprocfolder. The Transaction Processor creates these transactions.Merge incoming transactions from the inbox folders that reside on the remote client to the server database and the Siebel File System that reside on the Siebel Server.
How Siebel Remote Synchronizes Data That Users Modify
The Siebel Server prepares transactions that other users apply to the server database between synchronizations. Server components on the Siebel Server write these transactions to a separate folder for each user that resides on the server. Siebel Remote downloads these transactions and other items from the file system to the remote client during the next synchronization. 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 using the server component.
Scenario for Synchronizing Modified Data with Connected Users
This topic describes how Siebel Remote downloads data that users have modified from the server database to the local database. It describes the steps that occur when a connected user creates a new opportunity until Siebel Remote displays this opportunity in the local database. It describes a telesales user who works in a Call Center who talks with a potential customer who is replying to a new advertising campaign.
The following diagram illustrates a scenario for synchronizing data with a connected user.
Explanation of Callouts
Siebel Remote does the following work to synchronize data with a connected user:
A telesales user 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.
The Transaction Processor copies this transaction and other transactions to the Siebel Server.
A Transaction Router task writes each transaction from the
docking\txnprocfolder to transaction files that reside in separate outbox folders for each remote client. Siebel Remote stores these outbox folders on the remote client on the Siebel Server.The user starts a synchronization from the remote client.
Siebel Remote performs the remaining steps to download the new opportunity to the local database during the synchronization.
The remote client uses an existing LAN, WAN, or VPN connection to connect to the Siebel Server.
The remote client connects to the Siebel Server.
The Siebel Server starts the synchronization for the remote client.
The Synchronization Manager validates the node name that resides on the remote client with the list of valid node names that exist in the server database. The remote client receives transaction files that Siebel Remote routes to and from the Siebel Server. It also gets file attachments.
The remote client gets transaction (.dx) files from the user outbox folder that resides on the Siebel Server, and then stores them in the local inbox folder that resides on the remote client. The remote client also gets any requested, published, or broadcasted file attachments that reside on the Siebel File Server.
Siebel Remote inserts the new opportunity in the opportunity table in the local database that resides in the client.
The remote client closes the connection with the Siebel Server. The user can use the remote client while it applies synchronized data to the local database.
Scenario for Synchronizing Modified Data with Disconnected Users
This scenario describes how Siebel Remote uploads data that a user has modified from the local database to the server database. It describes how a telesales user works in a call center and meets with a potential new customer who 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. The telesales user then downloaded it during a subsequent synchronization.
The following diagram illustrates a scenario for synchronizing data with an unconnected user.
Explanation of Callouts
Siebel Remote does the following work to synchronize data with an unconnected user:
The user modifies an existing opportunity that resides in the local database. The user enters these modifications immediately after meeting with the potential customer while working offline.
Siebel Remote saves the modified opportunity in the opportunities table that resides in the local database.
Siebel Remote saves a transaction record to the local transaction log.
Siebel Remote extracts pending transactions from the local transaction log to transaction DX files. It then places these DX files in the outbox folder that resides on the remote client.
The user starts a synchronization from the remote client.
Siebel Remote does Step 6 through Step 12 to record the modifications that occur to the opportunity during this session.
The remote client uses an existing LAN, WAN, or VPN connection to connect to the Siebel Server.
The remote client connects to the Siebel Server.
The Siebel Server starts the synchronization for the user.
Synchronization Manager validates the remote client name with the list of valid clients that exist in the server database.
Synchronization Manager sends any transaction files that exist in the user outbox folder on the remote client to the user inbox folder that resides on the Siebel Server.
Siebel Remote closes the connection with the Siebel Server.
Siebel Remote inserts the modified opportunity in the opportunity table on the server database.
How Siebel Remote Resolves Conflicts in Data It Synchronizes
Data divergence is a situation that occurs when the local databases on different remote clients become less synchronized. Data divergence can occur if Siebel Remote does not detect or resolve these complex modifications. Siebel Remote uses conflict detection and resolution logic to prevent data divergence.
To support team selling and field service, Siebel Remote allows different users to access the same data. This situation creates the possibility that two users might make conflicting modifications to the same data when they are disconnected from the Siebel Server. To automatically detect update conflicts, Siebel Remote compares transactions at the field level. It uses rules to resolve conflicts for the following modifications:
Modifications that update values in an existing row
Modifications that delete an existing row
Modifications that add a new row
More complex conflicts involve deleting and adding database rows. For example:
One user might modify a value in a database row and another user might delete the entire row.
One user might add a database row to a local database, but the primary key for this row is in use by an existing row in the server database or in the local database of another remote client.
Update Conflict
An update conflict is a type of conflict that occurs if two users update the same data. For example, one user modifies the area code for a contact to 415 and another user modifies it to 408. The following table describes values you can use in the System Conflict Resolution field of the Remote System Preferences form to specify how to resolve conflicts. For more information, see Setting Preferences for Visibility, Logging, Timestamps, and Conflict Resolution.
Table Values for the System Conflict Resolution Field
| Value | Description |
|---|---|
Server Wins |
The value in the server database overrides the value in the local database. Server Wins is the default value. It is strongly recommended to resolve such conflicts because modifications converge more quickly. The Client Wins rule requires more time for data to converge. |
Client Wins |
The value in the local database overrides the value in the server database. |
If Siebel Remote rejects an update from a remote client, then the user can determine if an update conflict occurred. If the conflict resolution is not correct, then the user can manually reapply the modification to the local database. Siebel Remote sends it again to the Siebel Server during the next synchronization when the remote client sends database modifications to the server. If users have not made any other modifications to the data value since the last synchronization, then the modification does not conflict and it succeeds on the server.
Siebel Remote processes transactions in the order that the user synchronizes them. For the purposes of conflict resolution, any successful database update that a remote client sends to the Siebel Server becomes a server transaction.
Insert Conflict
An insert conflict is a type of conflict that occurs if a user adds a database row to a local database or to the server database, and this added or inserted transaction duplicates a new entry that exists in another database that resides elsewhere that the Siebel Server has not yet processed. If the user primary key of a new row matches the user primary key of an existing row, then Siebel Remote determines that an insert or duplicate conflict exists.
Siebel Remote cannot determine if the transaction is a true duplicate or simply an erroneous use of the same identifier for two different data entities. Siebel Remote cannot ignore the duplicate transaction. Instead, it adds the new row and sets the CONFLICT_ID column to the ROW_ID of the record. This configuration indicates that the row is a duplicate and makes sure the value for the _U1 index is unique. To determine if an insert conflict, also known as a duplicate conflict, has occurred, the user can examine the Remote Status view and determine if duplicates exist in a view that contains Siebel CRM data, such as the Accounts view or the Contacts view. For example, the user might modify the user primary key and resend the update. When the user resolves the conflict, Siebel Remote captures the local database update so that it can resynchronize this update with the Siebel Server during the next synchronization.
The user must monitor and resolve any conflict that the Siebel Server creates. The conflict is visible as duplicate records in a view that contains Siebel CRM data, such as the Accounts view or the Contacts view. To resolve an insert conflict, the user can use the Merge Record feature to merge the duplicate records. This feature is available only after the user chooses more than two records in the applet. To use it, the user chooses the Edit menu, and then the Merge Records menu item.
The user can also modify the user keys of one of the duplicate records to resolve the conflict.
The user must resolve conflicts before you can use EIM to merge records. If the user does not resolve conflicts, then the conflict flag in the interface table columns is not accurate.
The local database treats a null value as a unique value. If the user leaves a key field null for two or more records, then the local database allows duplicates.
Delete Conflict
A delete conflict is a type of conflict that occurs if a user deletes a row in the local database, and another user updates this same row in a different database. If Siebel Remote encounters a delete transaction, then it uses the following rule whether or not the transaction is in conflict with another update: Delete Always Wins.
If one transaction updates a database row and another transaction deletes this row, then Siebel Remote ignores the update and deletes the row.
The Delete Always Wins rule supersedes the System Conflict Resolution field of the Remote System Preferences form.
If the user synchronizes, and if the Merger Friendly Notification system preference is TRUE, then Siebel Remote displays deleted records in the Session Actions list of the Remote Status view of the User Preferences screen. For more information, see Process of Configuring System Preferences for the Siebel Server.
Merge Conflict
A merge conflict is a type of conflict that occurs if Siebel Remote merges records separately on the remote client and on the Siebel Server. The following example illustrates this problem:
Siebel Remote merges data from account A with data from account B on the remote client.
Siebel Remote merges data from account A with data from account B on the Siebel Server.
Delete transactions have the highest priority in Siebel Remote. The situation described in Step 1 and Step 2 can cause the following delete transactions:
One delete transaction exists from the remote client.
One delete transaction exists from the Siebel Server.
Siebel Remote deletes data from these accounts.
To avoid this problem, it is recommended that users do not merge data on remote clients.
How Siebel Remote Synchronizes 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 user synchronizes with the Siebel Server, then Siebel Remote copies the file to the Siebel File System that resides on the Siebel Server. It also copies the metadata to the server database.
If another user accesses the record where the file is attached, then Siebel Remote transfers the metadata for the file to the local database for this user the next time the user synchronizes. Siebel Remote does not transfer the file attachment to the local Siebel File System unless the user requests the file. Some types of file attachments include a Distribution Method setting. For example, a Literature item. If Siebel CRM sets the Distribution Method to Publish, then Siebel Remote automatically transfers the file to the user.
A user can click the attachment link in a Siebel application or choose the Request File check box for the attachment to request a file attachment. Siebel Remote then queues the request for the file. The user must synchronize again so that Siebel Remote can copy the file to the local Siebel File System. The user must click the link again to view the file after the synchronization finishes.
How Siebel Remote Manages the Amount of Data It Synchronizes
The following factors determine the size of the local database:
The position and responsibilities that the remote client requires. For more information, see How Positions, Organizations, and Responsibilities Affect Access.
The Data Routing Model. The Data Routing Model that Siebel Remote assigns to the remote client affects the amount of data that it stores in the local database.
The following benefits typically 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, you can review this guide for features that prevent Siebel Remote from synchronizing 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 Filters the Data It Synchronizes
Siebel Remote uses routing rules and routing models to filter the data that it synchronizes. For example, the data that a field sales representative requires might be different from the data that a field service representative requires. The sales representative might require detailed information about opportunities while the service representative requires detailed information about service requests. Routing rules provide the logic for the Database Extract and the Transaction Router server components. These rules reflect the data visibility and data access policies that exist in the Siebel application. For more information, see Controlling the Data That Siebel Remote Routes to Clients. See also Configuring Siebel Business Applications.
Dock Objects
A dock object is a logical grouping of tables that include schema structures that Siebel Remote uses to synchronize data between a server database and a local database. A routing rule belongs to a dock object.
The following table describes the types of dock objects that Siebel Remote uses.
Table Types of Dock Objects That Siebel Remote Uses
| Type | Description |
|---|---|
Enterprise |
Siebel Remote sends all the contents of the dock object to the remote client. An Enterprise dock object provides visibility to all users that exist in the Siebel application. Examples include currency and catalog. For more information, see About the Siebel Enterprise and the Siebel Enterprise Server. |
Limited |
Siebel Remote sends all the contents of the dock object to the remote client only if the instance is visible to the user. This data might or might not be visible to a user. Most user data is of the Limited type. A Limited dock object contains routing rules that determine the records that Siebel Remote routes to the user. |
Private |
Siebel Remote does not send any content from the dock object to the remote client. It does send data that a user creates on the remote client to the Siebel Server. It does not return updates to the remote client. For more information, see Controlling the Data That Siebel Remote Routes to Clients. |
Routing Rules
A routing rule is an SQL (Structured Query Language) statement that the Transaction Router and the Database Extract server components use to determine the records that Siebel Remote must route to each user. They provide the following benefits:
Protects data integrity
Allows the user to view the same data that the user can view when the user connects to the Siebel Server
Facilitates access control
Maintains application logic and functionality
A transaction in Siebel CRM is associated with a set of routing rules that might cause Siebel Remote to route the transaction to a user. A Siebel release can include more than a thousand active routing rules. For more information, see Modifying a Routing Model.
Routing Models
A routing model is a collection of routing rules. It identifies the data that Siebel Remote extracts to the user and the subsequent transactions that it routes to this user. You can associate a user with any routing model. Transaction routing behaves differently for each user depending on the routing model that you associate with the user. One of the following routing models is adequate for most users:
MOBILE CLIENT - STANDARD
MOBILE CLIENT - EXTRACT ONLY
Executive Management
You must carefully apply docking rules to reduce the size of the local database. A smaller local database can reduce synchronization times and transaction application times. Docking visibility rules identify the records that Siebel Remote synchronizes from the server database to each user. For more information, see Predefined Routing Models for Siebel Remote.
A routing model also affects the data that Siebel Remote extracts to regional servers and the subsequent transactions that it routes to regional nodes. For more information, see Comparison Between Siebel Remote and Siebel Replication Manager.
Displaying Views for Data That Routing Models Route
You can configure Siebel Remote so that a Siebel application displays only the views that display data that the routing model routes. You can use this configuration for a user who is assigned to one of the following predefined routing models:
Sales Rep Standard
Sales Mgr Standard
Field Technician
Analyst
Sr. Field Engineer
Field Engineer
Each user is associated with one routing model. The combination of the routing model and the routing rules determine if Siebel Remote routes a record to a remote client. For more information, see Predefined Routing Models for Siebel Remote.
Specialized Routing Models
It might be necessary to use a specialized routing model to help minimize the size of the local database. It is strongly recommended that you get help from Oracle before you deploy Siebel Remote with a specialized routing model. For more information, see Getting Help from Oracle.
Selective Retrieval Routing Model
The Selective Retrieval routing model can reduce the amount of data that Siebel Remote synchronizes, reduce synchronization time, and reduce the size of the local database. This routing model is appropriate for the user who uses connected and disconnected versions of a Siebel application. It might not be appropriate for a user who only uses the remote client or who requires access to some features, such as quotes or forecasting because Selective Retrieval limits the functionality of the Siebel application in some areas. Enabling records for synchronization also requires a direct connection to a Siebel Enterprise Server or to a regional server if the regional server contains the records that are enabled for synchronization. For more information, see Using Selective Retrieval to Route Data, and About the Siebel Enterprise and the Siebel Enterprise Server.
How Selective Retrieval Works
A user can enable or disable records for synchronization at any time. If you assign a user to the Selective Retrieval routing model, and if this user enables a record for synchronization, then Siebel Remote synchronizes this record to the remote client that is associated with the enabling User ID. It also synchronizes any records that are related to the enabled record to maintain data integrity. For example, if the user enables an account record, then Siebel Remote synchronizes the records for the contacts and addresses that are associated with this account.
If the user enables records for synchronization before Siebel Remote extracts the server database for the remote client, then the Transaction Router server component handles fewer items on the subsequent synchronization.
If you assign a user to the Selective Retrieval routing model, and if this user disables a record for synchronization, then Siebel Remote removes this record and any associated records from the local database during the next synchronization.
How Siebel Remote Validates and Authenticates Information
This topic describes the validation and authentication that Siebel Remote uses. It includes the following information:
For more information, see Siebel Security Guide.
How Siebel Remote Validates Synchronization
This topic describes the data that the Synchronization Manager server component validates when a remote client synchronizes with the Siebel Server. The Synchronization Manager authenticates incoming client requests to make sure that the remote client is valid.
Siebel Remote does not route the data that the Data Validation Manager uses. For help with Data Validation Manager, see Getting Help from Oracle.
Validating the Remote Client Name
The Synchronization Manager validates the name of the remote client with the list of valid clients that the server database contains. It validates that the effective end date for the client name is valid or is NULL.
Validating the Siebel Server
The App Server Name field identifies the name of the Siebel Server. It resides in the Mobile Clients view of the Administration - Siebel Remote screen. The DockConnString parameter identifies the local database. This parameter resides in the configuration file of the Siebel application on the remote client. For more information, see Modifying the Siebel Configuration File for Siebel Remote.
If the value of the App Server Name field does not equal the value of the DockConnString parameter, then the Synchronization Manager does the following work:
Reroutes the connection to the Siebel Server that the App Server Name field identifies
Sets the value of the DockConnString parameter to the value that the App Server Name field contains
Validating the User Credentials
If the Authentication Method parameter of the Synchronization Manager is not set to None, then the Synchronization Manager validates the authentication credentials for synchronization with the remote client. The authentication credentials that Siebel Remote uses depends on when the user attempts to synchronize:
User synchronizes before Siebel Remote initializes the local database. Siebel Remote uses the user ID and password that the user provides during the login.
User synchronizes after Siebel Remote initializes the local database. Siebel Remote uses the user ID and password from the DB Synchronization view of the User Preferences screen on the remote client.
The authentication method is a Synchronization Manager parameter that identifies the type of authentication that Siebel Remote uses during synchronization. For more information, see Parameters of the Synchronization Manager Server Component.
How Siebel Remote Uses Security Adapter Authentication
An authentication system is a data store that holds the information that allows the user to connect to a data source or to a server component. This information typically includes a database account and a Siebel user ID. The authentication system that Siebel Remote uses resides outside of the server database.
Guidelines for Using a Security Adapter
Siebel Remote can use a security adapter to authenticate a synchronization for a remote client. A security adapter is a plug-in to the Authentication Manager. To get the Siebel user ID, the security adapter uses credentials from a database account and, optionally, a set of roles from the authentication system. The user enters these credentials or an authentication service provides them. The Synchronization Manager server component accepts requests for synchronization and manages the synchronization. It delivers credentials to the security adapter and receives the server database credentials of the user from the security adapter.
If you configure Siebel Remote to use a security adapter, then consider the following guidelines:
You can use the following parameters:
Security Adapter Mode. Specifies the type of authentication that the security adapter uses.
Security Adapter Name. Specifies the name of the security adapter profile, which is the named subsystem.
You can set these parameters for a Siebel Enterprise, a Siebel Server, or for a server component. Any setting that you make at a lower level, such as at the component level, overrides any setting that you make at a higher level, such as at the enterprise level. If you must set these parameters at the component level for use with synchronization, then you set them in the Synchronization Manager server component. For more information, see About the Siebel Enterprise and the Siebel Enterprise Server.
You can use the same folder or different folders for synchronization authentication and for authentication with other data sources or server components.
You cannot configure Siebel Remote to use Web Single Sign On for synchronization.
For more information, see How Siebel Remote Validates Synchronization and Siebel Security Guide.
How Siebel Remote Authenticates Passwords
Siebel Remote authenticates the password before it connects to the local database. The remote client only supports database authentication through the security adapter on the remote client.
How Siebel Remote Sets the Local Database Password
You can set the password in the local database in one of the following ways:
The password that you assign during database initialization for the local database is the same as the password that you assign on the Siebel Server to synchronize with this local database.
The user can assign a different password for the local database.
Features You Can Use to Manage Remote Passwords
You can use the following features to manage the remote database password:
Application Lockout. You can specify the maximum number of consecutive, unsuccessful login attempts that the user can make. If the user unsuccessfully attempts to log in after exceeding the number of times that you specify, then Siebel Remote locks this user out of the Siebel application on the remote client for a time period that you can also specify. The user cannot synchronize the local database with the server database during this time period.
Password Expiration. You can configure a password for a remote database to expire automatically after a set interval. If you use this feature, then Siebel Remote examines the age of each remote database password when the user starts the remote client and when stand-alone synchronization starts. If the password expires, then Siebel Remote prompts the user to set a new password before this user can synchronize or log in to the Siebel application on the remote client.
Password Syntax Validation. You can require that a remote client password conform to format guidelines regarding the number and combination of alphabetic characters, numerals, or special characters that this password must contain. Format validation also examines any new password that the user enters to make sure that it does not duplicate any old passwords that this user used. You can specify the number of old passwords that Siebel Remote examines.
User Password Reset. You can use an administrator account to log in to the Siebel application on the remote client to reset a user password. You reset the user password so that it expires immediately. Siebel Remote then prompts the user to modify the password during the next login.
For more information about:
Application lockout, password expiration, and password format validation, see Process of Configuring System Preferences for the Siebel Server.
Resetting a password, see Resetting the Password of a Remote Client.
How Siebel Remote Encrypts Fields
Siebel Remote provides the following functionality for field encryption. For more information, see Process of Configuring Encryption and Authentication for the Remote Client and Siebel Security Guide:
If you extract a local database for a remote client, then the extract process detects encrypted fields and stores the unencrypted contents in a compressed binary DAT file. Siebel Remote uses the clear text value of the field to determine the hashed value of each encrypted field. This extract process does not modify the hashed value.
If the Transaction Router server component prepares modified data for a user, then it detects encrypted fields and stores the unencrypted contents in the compressed binary DX file. Siebel Remote uses the clear text value of the field to determine the hashed value of each encrypted field. The preparation of the DX file does not modify the hashed value. Some utilities can read data from a DX file. It is recommended that you prevent unnecessary user access to the following folders where DX files might exist:
TxnprocfolderInboxfolderOutboxfolder
If Siebel Remote synchronizes the server database with a local database, then data that it encrypts at the field level in the server database is decrypted in the local database.
If your Siebel implementation includes regional nodes, then it must meet the following requirements:
The regional nodes must use the same encryption as the Siebel Enterprise Server.
The keyfile.bin file on the regional server must be identical to the corresponding file on the Siebel Server of the headquarters node.
Data that passes between the server database and the local database for a regional node remains encrypted. For more information, see Overview of Siebel Replication Manager.
You can use the DockConnString parameter in the configuration file to specify how to encrypt the network traffic that occurs during a synchronization.
Other Considerations for Design and Development
This topic describes some of the other items that you can consider that this book does not describe elsewhere.
Modifying the S_DOCK_TXN_LOG Table
The Transaction Processor and the Transaction Router server components run on the Siebel Server and route transactions from the master transaction log to the outbox folder on the remote client. The Transaction Processor removes rows from the log after Siebel Remote writes transactions from the S_DOCK_TXN_LOG table to DX files in the docking\txnproc folder.
In a Microsoft SQL Server or DB2 environment, truncation of the S_DOCK_TXN_LOG table in a server database causes Siebel Remote to reset the txn_id values that it assigns to new transactions. Siebel Remote does not reset the corresponding txn_id values in the S_DOCK_STATUS table. In this situation, new transactions that Siebel Remote inserts in the S_DOCK_TXN_LOG table contain a txn_id mismatch when compared to the values that the S_DOCK_STATUS table contain. The Transaction Processor does not process these transactions. It removes them from the S_DOCK_TXN_LOG table.
If Siebel Remote truncates the S_DOCK_TXN_LOG table, then you must reextract all remote clients and delete all existing transactions and local databases before you reinitialize these clients. The reextract process resets the txn_id values in the S_DOCK_STATUS table so that the values correspond with the txn_id values that exist in the S_DOCK_TXN_LOG table. Deleting transactions and local databases is necessary to prevent mismatch errors between new S_DOC_STATUS txn_id values and older txn_id values that exist in the local databases.
Modifying Siebel Tables Directly Through SQL
Siebel CRM does not support modifying a Siebel table directly through SQL. Siebel CRM does not record SQL modifications in the Master Transaction Log (S_DOCK_TXN_LOG) for SQL modifications that run outside of the Siebel application. Siebel Remote does not route them to the remote client.
Using Oracle Real Application Clusters with Siebel Remote
As noted in 478215.1 (Article ID) on My Oracle Support, Siebel Remote supports Oracle Real Application Clusters (Oracle RAC).
Roadmap for Implementing Siebel Remote
To implement Siebel Remote, you do the following: