Bookshelf Home | Contents | Index | PDF | ![]() ![]() |
Siebel Database Upgrade Guide > Siebel Database Upgrade Planning > About the Siebel Repository MergeEnvironments: Development environment only. Platforms: Windows, UNIX, IBM z/OS. Repositories are located in tables in the Siebel database. These tables store the definitions of the objects used to build Siebel Business 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. The repository tables contain two types of records:
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 Siebel Repository is the deployed, active Siebel Tools repository. You use this repository to customize applications and to create SRF files for deployment. The development upgrep adds three additional repositories to the Siebel database, as shown in Table 10. These repositories are required for the repository merge. What Happens During a 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 ObjectsCustomer-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 in the Prior Siebel Repository, then it is customer-created. The merge process copies customer-created objects intact to the New Customer Repository. Customer-Deleted ObjectsCustomer-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, then 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, then 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, then the object will be present and inactive in the New Customer Repository. Customer-Modified ObjectsA customer-modified object has the following characteristics:
For customer-modified objects where no conflict exists, the merge process copies the modifications to the object to the New Customer Repository. If you modify a top-level object by deleting any of its child objects, then 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, then the merge process deletes these objects from the applet in the New Customer Repository: For example, if you delete a button from Applet-A in the Prior Customer Repository. The merge process deletes this button from Applet-A in the New Customer Repository. Table 11 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. Upgrade Ancestor PropertyYou 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. If you had not specified Applet-A as an upgrade ancestor of Applet-B, then Applet-B would not have received the new button. Postmerge UtilitiesThe 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 user interfaces after the merge. Incorporate Custom LayoutYou can choose Incorporate Custom Layout (ICL) when performing a repository merge. ICL is intended to reduce the postmerge user interface reconfiguration workload for customer-modified user interface objects. An ICL merge is a regular repository 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. Related Topics |
![]() ![]() |
Siebel Database Upgrade Guide | Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |