Bookshelf Home | Contents | Index | Search | PDF

Configuration Guidelines > Creating and Modifying Objects >

Copying Versus Modifying Object Definitions

---

The supported practice for creating new business components and applets is to reuse and modify standard object definitions. If, instead of using this supported method, you use the Copy Record option to copy standard business components and applets, you run the risk of causing problems during subsequent upgrades of Siebel applications. Some of the reasons why copying can cause problems include:

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 results in problems following the upgrade, and these are 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 creates redundancy.

Creating new copies of business components and applets results 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 increases, not reduces, difficulties.

Developers sometimes 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 possibly 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.

In short, modify existing object definitions wherever possible, and avoid using the Copy Record option except when it is truly needed.

However, there are a few special situations in which you should legitimately make a copy of an existing object definition. Some of these situations are described in detail in the subsections below. As a general rule, unless you are certain that you need to make a copy of an object definition, modify rather than copy an existing object definition.

Bookshelf Home | Contents | Index | Search | PDF