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

Deciding When to Reuse Objects

In general, use the out-of-the-box objects whenever possible. However, there will be cases when it will be difficult to determine whether to reuse an existing component or to create a new one. This will happen when you have requirements that do not fit within the components that are provided with Siebel out-of-the-box functionality and configuration.

When deciding whether to use an existing Siebel object or to create a new one, you need to determine how suitable the object is for its intended use. The developer should examine both the functional and technical fit of the proposed object. Where the fit is appropriate, then that object should be used. Where it is not, there may be a case for the creation of a new object.

An object should not be reused merely because it is not used by existing Siebel configurations or currently used by the customer. The object needs to also be suitable.

If no object is suitable, you should consider using database extensibility to extend the Siebel application. For more information about extending the database, see About Database Extension Options.

Determining Functional Fit

To determine if an object is a functional fit to your business requirement, you typically examine the table or business component you intend to use and consider the following criteria:

• The nature and purpose of the Siebel object in its native state should be compatible with your proposed usage. For example, storing Customer Complaints is compatible with the Service Request business component, but not for storing Financial Transactions.
• The relationships to other objects and their compatibility with your requirements. However, this should not be the only determining factor. The fact that an object contains the correct relationships is not enough to suggest it is a good candidate for reuse. For example, you should not use the S_EVT_ACT table as an intersection table simply because it contains two of the foreign keys that you require. Doing so causes an overloading of the table that may result in performance degradation.
• The visibility properties of the object and whether they are compatible with your requirements.

If the object is not a good functional fit, then reusing the object for that purpose may be inappropriate. Some examples of improper use include:

• Using the S_PARTY table for storing non-party entities.
• Using unused tables for custom business components where the table has no relationship to the intended usage of the business component.
• Use of unused table columns or business component fields that have no relationship to the intended usage of the field.

One way of improving the functional fit of a Siebel component or object is to modify your business processes to suit out-of-the-box Siebel functionality.

Determining Technical Fit

To determine if an object is a technical fit to your business requirement, examine technical factors, such as:

• Table schema
• Foreign key relationships
• Effect on Siebel Remote
• Performance Factors
• Size and type of columns and fields

When deciding to reuse an unused Siebel table, you need to examine the schema. Some factors include:

• The required columns that need to be defaulted to a particular value.
• The user key and unique index columns that also need to be populated.

If large amounts of customization need to be performed to be able to use an unused table, then technical fit diminishes.

Also, does the table contain the necessary foreign key relationships for your requirements? Again, this is not a sole-determining factor as you should not be simply reusing a table just because it contains the necessary foreign key relationships. It is also possible that Database Extensibility can be used to add the necessary foreign key columns and the Docking and EIM Wizards used if required.

NOTE:  Foreign key relationships and Siebel Remote are closely interrelated. Simply using the correct foreign key may not guarantee that the data will be downloaded to the remote client. It is necessary to understand the dock objects and its rules that the foreign keys are subjected to in order to determine if use of the object is appropriate.

Many columns that are not foreign keys have some impact on visibility. For example, S_PROD_INT.ENTERPRISE_FLG with a value of 'Y' confers partial docking visibility to the product record. Misusing columns such as these can have a significant impact on Siebel Remote.