Bookshelf v7.5.2: Analyzing the Use of Routing Models

Siebel Remote and Replication Manager Administration Guide > Routing Models for Financial Services > Using Routing Models in Siebel Financial Services >

Analyzing the Use of Routing Models

Before using the specialized Siebel Routing Models, assess and consider the impact of the following:

Analyze the mobile users' usage patterns. Determine what data the users need and what they do not need when using Siebel Financial Services in the local mode.

Compare the usage pattern with the definition of each routing model. Each model was designed for a specific class of mobile users.

Perform a review of your Siebel installation and consider the following:

Did you modify any of the views assigned to the Siebel Responsibilities?

If an MVG field were added to an existing view, a mobile user could set the value of the MVG field to a "No Match" row-id by modifying any fields in the row or selecting the MVG field. The reason is that no data for the MVG was downloaded to mobile Web client. This action implicitly creates an update transaction to be replicated to the server during the next synchronization session. Database integrity is compromised when the transaction is applied on the server.

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

Generally, views that contain data from limited visibility objects should have routing rules to support them. If a view is added that does not have corresponding routing rules, then no data will be replicated for that specific view. If such a view was added to a Siebel Responsibility and the implementation uses Client Wins for update conflict resolution, the following undesirable situation could occur—this should be avoided.

A mobile user creates a new record using the newly added view on the mobile Web client.

The mobile user synchronizes with the server.

A Web client user makes changes to the same record on the server.

The mobile user synchronizes and does not see the updates by the Web client to the same record.

The mobile user makes changes to the record in the mobile Web client.

The mobile user synchronizes and overwrites the content of the record on the server.

In this manner, a mobile user could unintentionally overwrite updates made by another user to the same record.

Exposing a custom foreign key in a Siebel view and business component.

A custom foreign key may not have any Siebel Remote routing support, because routing rules were either deactivated out-of-the-box or no rule was created. As a result, no data will be routed to support the foreign key. If any base record containing this foreign key is touched or updated by a mobile user in their local database, it may inadvertently reset the reference to null and in turn, replicate this change to the server.

If the answer to any of the above questions was yes, do not use any of the specialized routing models in Table 34.

If the answer to all the above questions was no, conduct a field test with a small group of representative mobile users. Use the appropriate routing models and assess the impact of the specialized routing models on the Transaction Router. During the test, observe the following:

Local database size and the amount of data being replicated—should be reduced.

Mobile users can still perform business tasks—no data is missing that prevent the users from completing a critical business process.

Synchronization times—should be shorter.

Every server transaction should be routed to the mobile Web client except for those explicitly excluded in the routing models—if not, the users responsibilities may not match the routing model.

Every view that has data on the server should show the same data on the mobile client—if not, there is a strong possibility the wrong views were included in the users' responsibilities.

If you have acceptable results from the field test, you are ready to deploy the routing models to the appropriate mobile users.