Siebel Database Upgrade Guide > How the Siebel Database Upgrade Works >

About the Siebel Repository Merge

Upgrades from: All Siebel releases.

Environments: Development environment only.

Platforms: MS 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 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:

• Object definitions used to create Siebel applications, such as business components, applets, controls, and the relationships between them.
• Definitions of the tables in the Siebel database (metadata). These records define the logical schema of the Siebel database. Later in the upgrade process, you will synchronize the physical schema of the Siebel database with the logical schema as defined by these 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 Tools repository. You use this repository to customize applications and create SRF files for deployment.

The development upgrep adds three additional repositories to the Siebel database, as shown in Table 26. 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 Objects

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

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.

Customer-Modified Objects

A customer-modified object has the following characteristics:

• It is a top-level object, such as screen, applet, or business component.
• The object exists in the Prior Siebel Repository and the Prior Customer Repository. (The object is not customer-created or customer-deleted)
• The properties of the object in the Prior Customer Repository and Prior Siebel Repository are not the same. (You have modified the object).

  If the object properties are also different between the Prior Siebel Repository and New Siebel Repository, the object has changed in the new release, and a conflict exists. The merge process logs the conflict and resolves it. After the merge, you must review how these conflicts were resolved and change the resolutions as desired.

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, 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:

• Control
• List Column
• Page Tab
• Chart
• Applet Web Template Item
• View Web Template Item

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 28 shows how a regular merge handles both customer-modified and customer-created objects. The columns list the status of a repository object:

• Standard. The object appears in the Prior Standard Repository, in the New Siebel Repository, and is not customer-modified.
• Deleted. You have deleted the object from the Prior Customer Repository (customer-deleted).
• Customized. You have modified the object in the Prior Customer Repository (customer-modified).
• Revised. The object has changed in the new release (New Siebel Repository).
• New. You have created the object in the Prior Customer Repository (customer-created), or the object is new in the new release (New Siebel Repository).
• Inactive. The object is present in the New Siebel Repository and New Customer Repository but is inactive and not used in the new release. The object is obsolete.

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 Property

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:

• Applets
• Business Components
• Integration Objects
• Reports

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, Applet-B would not have received the new button.

Postmerge Utilities

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.

Incorporate Custom Layout

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.

Additional Merge Steps if You Are Upgrading from Siebel 6.x

For upgrades from Siebel 6.x, the repository merge process includes several additional steps. These steps convert the Windows-based UI to HTML and transition scripts to the Siebel 7.x architecture:

1. Prepare the Prior Customer Repository. A wizard does the following:
   • Migrates strings from S_MSG to locale tables.
   • Merges labels and fields. In Siebel 7.x, labels are a caption property of controls.
   • Merges Web templates. Siebel 7.x uses a revised method for providing base, edit, query, and new record functionality in applet Web templates. The wizard revises applet templates to use the new method.
2. Run the repository merge and postmerge utilities.
3. Run the Web Client Migration Wizard. This merges applets and views that you have customized or created into the New Customer Repository. You do this by assigning model applets and model views to them.
4. Manually, revise and reassign server and browser scripts.
5. Manually, revise any integrations with third-party products.

Related Topics

About the Siebel Incorporate Custom Layout (ICL) Upgrade Option

About Inheriting Upgrade Behavior in a Siebel UpgradeAbout the Siebel Postmerge Utilities

Reviewing Siebel Repository Object Property Conflicts