Configuring Siebel eBusiness Applications > Overview of Configuring Siebel Applications >

About Object Reuse


In general, reusing existing objects is the recommended approach for configuring a Siebel application to your meet business requirements. However, there are cases when reusing existing objects is not appropriate and can cause problems. This section provides guidelines about when to reuse and when not to reuse existing Siebel objects.

Customizing Siebel Applications

Avoid significantly customizing Siebel applications. Customization refers to large-scale changes to the base product, such as:

  • Creation of new modules that do not exist within the Siebel application, usually involving use of database extensibility, many new business components, and many new business objects.
  • Significant modification to existing objects.
  • Significant changes to out-of-the-box behavior, such as visibility, and changes to framework objects such as JavaScript files.
  • Use of scripting.

Inappropriate customization of the Siebel application can cause the following issues:

  • Decreased maintainability and therefore increased cost of ownership.
  • Potential for decreased in performance.
  • Potential impacts with future upgrades.
  • Increased testing effort.

Developers should avoid significant customization of the Siebel application, and attempt to reuse and extend existing objects where possible. However, there are cases where reuse is inappropriate.

Why Reusing Objects is Important

Reuse in software development involves the building of components that can be reused and extended. Reuse allows you to limit the amount of customization in your deployment. Any changes to the out-of-the-box configurations should maximize reuse and allow for easy extensibility.

Reuse is important for the following reasons:

  • It optimizes the performance of Siebel applications. Out-of-the-box Siebel configurations have been tuned for performance.
  • Provides for easier maintainability and reduced cost of ownership.
  • Facilitates future upgrades.
  • Consistency in application behavior.

There are several ways to reuse components in Siebel applications, for example:

  • Use Siebel out-of-the-box functionality and modules without substantial modification.
  • Use out-of-the-box configuration objects such as business components, business objects, links, applets, views and so on.

    NOTE:  In general, avoid copying objects. See About Copying Objects.

  • Use declarative techniques to translate business requirements into application behavior, such as configuration in Siebel Tools, Workflow, Personalization, Runtime Events, and State Model.

Reusing Objects Inappropriately

While reusing Siebel objects is generally the recommended approach for configuring Siebel applications to your business requirements, reusing Siebel modules or repository objects in ways that do not suit their original purpose can cause a number of problems.

  • The performance of the component or object has been tuned by Siebel Engineers with a specific purpose in mind. Using it for a different purpose may result in performance degradation.
  • Using a repository object for the incorrect purpose may limit your ability to use that object for its intended purpose in the future. For example, you may choose to use the Service Request business component for a custom purpose. Doing so limits your ability to use this business component for its correct purpose in the future, which is to store a service interaction with a customer.
  • Large amounts of customization may be required to make the improper use of an object function. For example, when reusing a table for an alternative purpose, it is necessary to populate all required columns as well as add a search specification to the business component. If a business component is used for an improper purpose, there may be specialized class behavior that affects your ability to properly use the business component. Additional customization may be required to make the business component function so that it meets your requirements.
  • Inappropriate reuse violates a principle of software development in that the purpose of components should be clear. When an object is improperly used, then the developer's intent is not clear to future developers. For example, if the table S_SRV_REQ is used to store financial transactions, the configuration is not clear to future developers as the table bears no relationship to financial transactions.
  • In general, reuse of Siebel repository objects should increase the upgradability of the repository. However, inappropriate reuse can decrease upgradability. Changes to objects during repository upgrades are based on the objects being used for their original purpose. The upgrade may change the table schema by adding or changing unique indexes as well as required columns. It may also change the behavior of specialized classes. Also, Siebel functionality such as access control, visibility, and the party data model may also be changed. Improper reuse of components may cause difficulties during upgrade, which in some cases may be difficult to debug and fix.
  • Misusing objects can result in reconfiguration work after an upgrade because the upgrade will revert the object to its original form.
  • You can misuse repository objects by reusing objects that are outside of your licensed configuration.
Related Topics

Deciding When to Reuse Objects

About Reusing Business Component Fields and Table Columns

About Reusing Business Components

About Reusing Tables

About Reusing Views

About Reusing Applets

Configuring Siebel eBusiness Applications