Upgrade Guide for Microsoft Windows > Upgrading the Siebel eBusiness Application > Preparing the Prior Customer Repository for the Merge >

Automatic Upgrade of Copied Objects


CAUTION:  The repository merge procedures only apply to development environment upgrades. If you are performing a production environment upgrade, skip to Upgrading the Custom Database Schema.

Siebel Tools allows copied objects to inherit some of the behavior of their ancestors, which makes it easier to upgrade Siebel applications, reduces the time and cost of adjusting an application after an upgrade, and also supports parallel development by allowing some frequently used objects to be copied.

Certain repository objects that are copied during configuration can be upgraded with a new property called Upgrade Ancestor that stores the name of the ancestor object. This allows copied objects to be upgraded in the same way as the ancestor objects from which they were copied. Thus when you copy an existing object, you can specify its upgrade ancestor; during an upgrade the copied object is upgraded the same way as the original. This feature is available only for objects of type Applet, Business Component, Report, and Integration Object.

NOTE:  Use of the Upgrade Inheritance feature slows the performance of the repository merge.

Upgrade Inheritance functionality:

Upgrade Inheritance Scenario

For example, you may want to make a copy of the Account List Applet and call it the Premium Account List Applet. This new applet may differ from the original one in that it has a special search specification that is displayed only in those accounts that are considered premium accounts. In a subsequent release, Siebel eBusiness Applications may include additional standard list columns to the Account List Applet. During an application upgrade, your Account List applet and the Premium Account List Applet retains the configuration changes you made. However, both applets receive the new standard list columns added in the new version because of Upgrade Inheritance functionality. Without this new feature, the copied applet would not receive the new list columns during the upgrade process.

How Enhancements Are Applied During an Upgrade

During upgrades, it is very common that objects in the repository are changed. For example, an applet might have a few list columns added or a business component might have some fields and a multi-value link added. To do this, the objects that need to be changed during the upgrade are recognized by their Name property. For example, you would query the repository for the Account BC and add the necessary new items to it. If you did not have the Upgrade Inheritance feature and the Account BC had been copied as Acme Account, you would not recognize the new BC as a copy of the Account BC and would not add the required changes to the copy during the upgrade. These additions might be minor, but often these omissions can cause numerous application errors after the upgrade and can be time consuming to detect and correct.

During an upgrade, the Upgrade Inheritance feature makes sure that copied objects receive the same changes that are applied to the object from which they were copied. This is done automatically by the upgrade utility, and there is no manual step involved except for specifying the property.

NOTE:  This functionality is applied only to the following object types: business component, applet, integration object, and report.

Choosing an Upgrade Ancestor

When choosing an upgrade ancestor for an object, the picklist of objects displayed from which you can choose varies depending on the object type. The picklist has the following constraints for each object type:

The constraint requires that these picklists show only standard objects; this can be relaxed by setting a flag found in View > Options > General. This may be appropriate for customers that use the inheritance feature to support distributed development. Relaxing this constraint does not change the fact that ancestor objects must be found in the New Standard repository in order to be applied to their descendants during a merge.

NOTE:  If an object that does not exist in the 7.5 New Standard repository is specified as an ancestor object, error messages appear during the repository merge process in the merge.txt file. These errors are acceptable. However, you may want to manually update the descendant objects of the ancestor object, because these objects were not updated with the characteristics of the ancestor object during the merge.

Repository Location of the Upgrade Ancestor

During the application upgrade, the contents of three repositories are compared to produce the final, postupgrade repository which contains both the customizations made by the customer as well as any enhancements added in this release during the upgrade. The three repositories compared are the following:

The Upgrade Ancestor object of a copied object must exist in the New Standard repository in order for any enhancements to be applied to descendants during the merge.

The outcome of the upgrade ancestor only affects the New Customer Repository.


 Upgrade Guide for Microsoft Windows
 Published: 20 October 2003