|Bookshelf Home | Contents | Index | PDF|
Repositories are located in tables in the Siebel Database. These tables store the definitions of the objects used to build Siebel Applications. These tables also store Siebel schema definitions. When you display objects in the Siebel Tools Object List Explorer, you are displaying records from these tables.
Repository records include a repository ID that identifies the repository to which the record belongs. The repository ID forms part of the user index for records and allows several repositories to be stored in the same set of tables.
The development upgrep adds three additional repositories to the Siebel Database, as shown in Table 13. These repositories are required for the repository merge.
The repository merge process identifies differences between the repository in your old release (Prior Customer Repository) and the repository in the new release (New Siebel Repository). The merge process then merges these differences into the New Customer Repository. The merge process searches for the following types of objects in the Prior Customer Repository: customer-created, customer-deleted, and customer-modified.
Customer-Created objects are top-level objects, such as screens, applets, and business components, that you have created in the Prior Customer Repository. If an object is present in the Prior Customer Repository but not the Prior Siebel Repository, it is customer-created. The merge process copies customer-created objects intact to the New Customer Repository.
Customer-Deleted objects are top-level objects you have deleted in the Prior Customer Repository. If an object is absent in the Prior Customer Repository but present in the Prior Siebel Repository, it is customer-deleted.
If you delete a top-level object in the Prior Customer Repository and it is present in the New Customer Repository, the merge process does not delete the object from the New Customer Repository. After the merge, you must review these objects and remove them as desired.
If you delete a top-level object from the Prior Customer Repository, and it is obsolete (inactive) in the New Customer Repository, the object will be present and inactive in the New Customer Repository.
If you modify a top-level object by deleting any of its child objects, the merge process does not delete these child objects in the New Customer Repository. After the merge, you must review child objects and remove them as desired.
Some of the child objects of Applet are an exception. If you delete the following child objects of Applet from the Prior Customer Repository, the merge process deletes these objects from the applet in the New Customer Repository:
Table 14 shows how a regular merge handles both customer-modified and customer-created objects. The columns list the status of a repository object:
The first three columns list the status of the object in the three repositories that the merge process compares during the merge. The last column, Merged New Customer Repository, lists the status of all top-level repository object types after the repository merge is complete and the postmerge utilities have run.
You can link repository objects together so that one object inherits the upgrade behavior of another. You do this by specifying an upgrade ancestor for an object. You can specify upgrade ancestors for the following object types:
For example, you create Applet-B by copying Oracle standard Applet-A. In Applet-B you specify Applet-A as the upgrade ancestor. In the New Siebel Repository, Applet-A has a new button. Because Applet-B is a descendant of Applet-A, the merge process adds the new button to both Applet-A and Applet-B.
The postmerge utilities run after the repository merge completes. The utilities make changes to objects in the New Customer Repository. The purpose of the postmerge utilities is to reduce the configuration changes required as part of reviewing applications and UI after the merge.
If you are upgrading from Siebel 7.x or later, you can choose Incorporate Custom Layout (ICL) when performing a repository merge. ICL is intended to reduce postmerge UI reconfiguration workload for customer-modified UI objects.
An ICL merge is a regular merge that contains two extra steps. The first step occurs at the end of the merge and applies special handling to screens, views, and applets. The second step is part of the postmerge utilities and provides specialized web template files similar to the release you are upgrading from.
|Siebel Database Upgrade Guide||Copyright © 2008, Oracle. All rights reserved.|