Configuring Siebel eBusiness Applications > Overview of Configuring Siebel Applications > About Configuring Siebel Applications >

About Copying Objects

Use caution when copying objects. Although there are cases when copying objects is appropriate, there are also a number of problems associated with copying objects.

Problems Caused by Copying Objects

Copying objects can result in the following problems:

• Copying can create upgrade problems that are difficult to debug.

  Functionality is often added to most of the standard business components during major releases. Very often this new functionality depends on the existence of new fields, joins, and so on, that are added to the standard business components. During the upgrade, these new fields are added only to the standard business components in your merged repository.

  Copying objects can result in problems following an upgrade. These problems can be difficult to locate and debug. The errors often occur because some C++ code for the business component or applet class is trying to find a field that does not exist in your custom copy of that business component or applet. The only way to debug the problem is to compare your custom business component with the standard business component and add any new fields and other child object definitions that may have been added in the new release. This may be a complex process, requiring detailed knowledge of what has changed in the new release.

• Copying objects creates redundancy.

  Creating new copies of business components and applets can result in considerable redundancy in your configuration. For example, if you were to create a copy of the Account business component called My Account, and use this on all of the account-based views, you would also have to create copies of every account-based applet and point each to the new My Account business component. You probably would also have to create a new business object, screen, and so on. It would result in considerable additional configuration with little or no benefit.

• Copying objects can increase complexity.

  Sometimes developers make copies of object definitions in the belief that doing so will reduce problems during an upgrade. The assumption is that if the business component is called My Account, the Application Upgrader will leave it alone during the upgrade, resulting in no problems after the upgrade.

  However, this assumption is misleading. The problems you will have with an upgraded configuration containing copied object definitions will be more complex to solve than the problems potentially caused by reusing standard object definitions. It is far easier to go through your application after an upgrade and remove various new controls and list columns from a standard applet than it is to go through each custom business component and applet and work out what fields, joins, multi-value links, and so on to add.

Copying User Interface Objects

Sometimes it is appropriate to copy user interface objects. For example, when business requirements call for significant changes to the look and feel of the object, copying the object (and setting the Upgrade Ancestor property) makes certain that the modified look and feel would be preserved following an upgrade. If only minor changes to the UI object are needed, it is better to use the out-of-the-box object because this eliminates time spent configuring and the continuing maintenance of the repository. Other appropriate reasons for copying UI objects are:

• When two different UI objects have to display different records (that is, different search specifications on applets).
• When different read/write properties between two objects are necessary (that is, one applet is read-only, and the other is editable) and if this could not be accomplished through the dynamic read-only business component user property.
• When different drilldowns are necessary for different applets, depending on the view that contains them (provided this could not be accomplished through a dynamic drilldown).

When copying an applet that uses a business component based on a specialized class, the following guidelines apply:

• The copied applet must be used with the original business component, not a copy of the original business component.
• If you want to use a copied applet with a copied business component, you need to change the class of the copied applet.

Copying Business Objects and Business Components

In general, avoid copying business objects and business components. However, copying may be appropriate when:

• A business component must appear twice in a business object; for example, when the Account business component and Sub Account business component both appear within the Account business object.
• Two business components contain different search specifications and predefault values for the Type field that differentiates the records of these two business components.