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 on, that Siebel CRM adds to a predefined business component. During the upgrade, Siebel CRM adds these new fields only to the predefined business components that reside 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 Siebel CRM modified 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 define copies of every applet that references accounts, and you must make sure each of these copies references the new My Account business component. It might be necessary for you to create a new business object, screen, and so on.

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. 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 that reusing a predefined object causes. 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 identify the fields, joins, multi-value links, and so on, 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. Oracle tunes the performance of the component or object 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 modify 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 work correctly. For example, if you reuse a table for an alternative purpose, then you must configure Siebel CRM so that it updates all required columns and adds a search specification to the business component. If you use a predefined business component for a purpose other than the original design intent, then specialized class behavior might exist 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 work so that it meets your requirements. For more information, see Options to Filter Data That Siebel CRM Displays In an Applet and Caution About Using Specialized Classes.
• 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, then this 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. Modifications that Siebel CRM makes to objects during a repository upgrade depends on Siebel CRM using objects for their original purpose. An upgrade might include any of the following modifications:
  • Modify the table schema by adding or modifying unique indexes or required columns.
  • Modify the behavior of specialized classes.
  • Modify functionality. For example, access control, visibility, and so on.
  • Modify the party model.
• Objects that Siebel CRM does not include in your licensed configuration might be included in your deployment.