Bookshelf v7.5: Modifying Objects

Modifying Objects

There are many reasons to modify an existing object. For example:

Many existing objects have been configured for best performance; cloned objects may not automatically inherit this same ability.

Because you have an archived copy of the original object to revert back to (in the sample database), troubleshooting will be much easier. You can also use the comparison feature in Siebel Tools to determine what changes were made to the object that might be causing the problem.

Repository and application maintenance requires less time and fewer resources.

The SRF is smaller and compiles faster.

Eliminating unnecessary copies of objects reduces the amount of redundancy in the repository.

Because standard objects have already been thoroughly tested, less effort is required to test the application or resolve application errors.

By reducing the number of repository objects being evaluated or upgraded, there is less effort required when upgrading your application.

New functionality is often added to core business components during a major release. Typically, this new functionality depends on the existence of new fields or joins that have been added to existing business components. During the upgrade process, these new fields or joins will only be added to the standard business components (identified by name) or to copies that are directly related to a standard object. This is why you must specify the Upgrade Ancestry property for any cloned business components, applets, integration objects or reports.

By specifying the Upgrade Ancestry property, you can be sure that, during the upgrade process, all of your cloned business components will match the standard business components that were used as the basis for the cloned object. This helps reduce any difficulties after the upgrade, which are inherently hard to resolve. Many of these errors occur because some C++ code from the specialized class for the business component or applet is set to a field that does not exist in your custom copy of the specialized business component or applet. The only way to resolve the error is to compare your custom business component with the standard business component and manually add any necessary new fields.

NOTE: Clone an object only when you are customizing the application. Do not clone objects to maintain a pristine copy of the object definition. The Archive feature in Siebel Tools lets you archive one, multiple, or all objects within a project into an SIF file. You can reimport these archive files at any time, and by using a third-party source control program, you can use these archives to control the versions of your configuration changes.

Also, be aware of the following:

Creating a new object without specifying an Upgrade Ancestor property could add to your upgrade efforts, as custom objects will not be upgraded. Instead, they are copied to the new repository, but without changes.

Creating new copies of business components and applets may also create a significant amount of redundant configuration.