Configuring Siebel Business Applications > Reusing Predefined Objects > Guidelines for Reusing a Predefined Object >

Reasons Not to Reuse a Predefined Object

Reusing an object can result in problems.

Copying a Predefined Object Can Cause an Upgrade Problem

Copying an object can cause an upgrade problem that is difficult to debug. Functionality is often added to most of the predefined business components during major releases. This new functionality often depends on new fields, joins, and so forth, that are added to a predefined business component. During the upgrade, these new fields are added only to the predefined business components in your merged repository.

Copying an object 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 attempts 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 predefined business component, and to add any new fields and other child object definitions that Siebel CRM added in the new release. This work can be complex, requiring detailed knowledge of what changed in the new release.

Copying a Predefined Object Can Cause Redundancy

Creating a new copy of a business component or applet can result in redundancy in your configuration. For example, if you create a copy of the Account business component and name it My Account, and use this copy on all of the views that reference accounts, then you must also define copies of every applet that references accounts and make sure each of these copies references the new My Account business component. It also might be necessary for you to create a new business object, screen, and so forth.

Copying a Predefined Object Can Increase Complexity

You might make a copy of an object in the belief that doing so will reduce problems during an upgrade. The assumption is that if the business component is named My Account, then 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 might encounter with an upgraded configuration that contains a copied object might be more complex to solve than the problems caused by reusing a predefined object. It is easier to examine your Siebel application after an upgrade and remove various new controls and list columns from a predefined applet than it is to examine each custom business component and applet to determine which fields, joins, multi-value links, and so forth that you must troubleshoot.

Results of Reusing An Object Inappropriately

Reusing a Siebel module or repository object in a way that does not meet the original purpose of the object can cause the following problems:

• Performance might be degraded. The performance of the component or object is tuned by Oracle for a specific purpose.
• Future use of the object might be limited. For example, the Service Request business component stores a service interaction with a customer. If you change this usage, you might limit your ability to use this business component for the original purpose in a future release.
• Large amounts of customization might be required to make the improper use of an object function correctly. For example, if you reuse a table for an alternative purpose, then you must configure Siebel CRM to update all required columns and add a search specification to the business component. If you use a predefined business component for a purpose other than the original design intent, then there might be specialized class behavior that affects your ability to properly use the business component. It might be necessary for you to perform more customization to make the business component function so that it meets your requirements. For more information, see Options to Filter Data Displayed in an Applet.
• The intended purpose of the reused object might not be clear to future developers. For example, if you use the S_SRV_REQ table to store financial transactions, the configuration is not clear to future developers because the table bears no relationship to financial transactions.
• Upgradability might be decreased. Troubleshooting and reconfiguration might be required after an upgrade because the upgrade might revert an object to the original form. Changes that Siebel CRM makes to objects during a repository upgrade are dependent on objects being used for their original purpose. An upgrade might incorporate any of the following changes:
  • Change the table schema by adding or changing unique indexes or required columns.
  • Change the behavior of specialized classes.
  • Change functionality. For example, access control, visibility, and so forth.
  • Change the party model.
• Objects that are not included in your licensed configuration might be included in your deployment.