Siebel Remote and Replication Manager Administration Guide > Synchronizing the Remote Client > Options for Synchronizing and Starting the Remote Client >

Deploying a Predefined Routing Model

You must determine if it is feasible to deploy the predefined routing models that are described in Predefined Routing Models.

To deploy a predefined routing model

1. Analyze the usage patterns for the user.

   Identify the data that the user requires and does not require when using Siebel Remote locally.

2. Compare the usage pattern with the definition of each routing model.

   Each routing model meets the requirements for a usage pattern.

3. Examine your Siebel installation and consider the following:
   1. Did you modify any of the views that are assigned to the Siebel Responsibilities?

      For more information, see Example of How Modifying a View Might Compromise Data Integrity.

   2. Did you modify any of the Siebel Responsibilities by adding new views that are accessible in local mode?

      For more information, see What Happens If a View Does Not Reference a Routing Rule.

   3. Has a custom foreign key been exposed in a Siebel view and business component?

      Siebel Remote might not support a custom foreign key. As a result, it does not route data to support the foreign key. If the user modifies or even views any base record that contains this foreign key in the local database, then Siebel Remote might inadvertently reset the reference to null, and then synchronize this modificaiton to the Siebel Server.

4. If the answer to any question in Step 3 is yes, then you do not use the predefined routing models.
5. If the answer to the questions in Step 3 is no, then you can conduct a field test with a small group of representative users:
   1. Use predefined routing models.

      For more information, see Predefined Routing Models.

   2. Assess how the predefined routing models affect the Transaction Router server component.

      For more information, see Expected Results from the Field Test of a Predefined Routing Model.

6. If the results from the field test are acceptable, then you can deploy the routing models to users.

Example of How Modifying a View Might Compromise Data Integrity

If you add an MVG field to an existing view, and if the user modifies any fields in the row or even chooses the MVG field, then Siebel Remote might set the value of that MVG field to a No Match row id. This situation exists because Siebel Remote does not synchronize any data for the MVG to the remote client. This action implicitly creates an update transaction that Siebel Remote synchronizes to the Siebel Server during the next synchronization. If Siebel Remote synchronizes this transaction on the server, then it compromises database integrity.

What Happens If a View Does Not Reference a Routing Rule

A view typically references a routing rule that supports an object that possesses limited visibility. If you add view that does not reference a corresponding routing rule, then Siebel Remote does not synchronize any data for that view. If you add this view to a responsibility, and if your implementation uses Client Wins to resolve an update conflict, then the following undesirable situation might occur:

1. A user uses the new view on the remote client to create a new record.
2. The user synchronizes with the Siebel Server.
3. The user of a Web client modifies the same record on the Siebel Server.
4. The user synchronizes but does not see the updates that the user of the Web client made to the record.
5. The user modifies the record in the remote client.
6. The user synchronizes and overwrites the content of the record that resides on the Siebel Server.

   In this situation, the user unintentionally overwrites the updates that another user makes to a same record.

Expected Results from the Field Test of a Predefined Routing Model

Table 17 describes the results that you can expect from a successful field test.