Bookshelf v7.7: About Reusing Business Component Fields and Table Columns

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

About Reusing Business Component Fields and Table Columns

In general, you should reuse an existing suitable field or column rather than create new ones. However, when deciding whether to use a previously unused field on a business component or an unused column on a table, you need to decide whether that field or column is a good functional or technical fit for your business requirements.

Examples (good and poor) of reusing columns and fields are:

You can use the Last Name or First Name fields on the Contact business component to store the names of the contact.
You could use the unused WEIGHT column on S_CONTACT to store the weight of the contact. It should not be used to store other types of information unrelated to the weight of the contact.
On the Campaign business component, you should not use the field Route Prospects to store information other than indicating that campaign contacts should be routed to the remote client. Storing other information can compromise Siebel Remote performance.
On the Order Entry business component, you should not use the field Revision to store anything other than the revision number. This field is controlled by specialized behavior.
On the Account business component, instead of creating a custom extension column for a new field to store an email address, use the unused column S_ORG_EXT.EMAIL_ADDR.

NOTE: The Comment property of the column object type often describes the column's intended purpose. Use comments to help you decide when to reuse a column.

Reusing fields or columns when there is not a good technical or functional fit can have poor results. In these cases, it would be better to create a new field and/or column. Examples of creating and reusing different types of columns and fields are:

Duplicate columns. When deciding to reuse an unused column for a new field on a business component, you need to verify whether the column is not already being used by another field on the same business component. If more than one field maps to the same table column, you may encounter "duplicate column" insert errors during copy operations. In this case, you should try to use the original Siebel field that maps to the desired column if it is suitable. Otherwise, use another appropriate column, such as custom extension column or unused ATTRIB column.
Column type and size. When reusing an unused column, one technical factor is its type and size. Developers are not normally allowed to change either the type or size of the column. An exception is DB2 UDB for OS/390 and z/OS platforms, since the maximum size of VARCHAR columns is stored in indexes.
For more information, see Implementing Siebel eBusiness Applications on DB2 UDB for z/OS and OS/390.
Fields use by Siebel Remote. Do not misuse fields or columns that control Siebel Remote behavior. Usually, the column ENTERPRISE_FLG is used to implement enterprise visibility on records that have normal visibility constraints. Also, other columns may also be used to control routing behavior, such as the RTE_CONTACTS_FLG or RTE_PRSP_CONS_FLG column on S_SRC.
You can determine if a column is subject to a dock object visibility rule by query in the flat tab view in Siebel Tools in two ways. Query on the Dock Object Visibility Rule object against the SQL Statement and DBX SQL Statement fields. Or query on the Dock Object Table object against the Filter SQL Statement. If you are in doubt about the nature of a particular column and how it may impact Siebel Remote you should contact Siebel Technical Support.

For more information about Siebel Remote, see Siebel Remote and Replication Manager Administration Guide.
Foreign key columns. If you need to add a new foreign key to a table, when possible reuse a column that exhibits the correct foreign key relationships. This is determined by the Foreign Key Table property of the column object. If the column is already used by a field on the business component, then that field should be reused rather than creating a new field. The original purpose of the unused foreign key field or column should match your intended use.
You should not use a foreign key column that does not exhibit the correct foreign key relationships, nor should you use an out-of-the-box column that is not a foreign key, to store a custom foreign key. Doing so can impact Siebel Remote and EIM. If no suitable field or column exists, then use Database Extensibility to create a new column and invoke the Siebel Dock Object and EIM Table Mapping Wizards if desired.

Creating custom foreign keys can cause problems when generating EIM mappings and when routing data to remote users.
Primary Id fields. In certain cases, you can configure primary Id fields for MVLs to improve performance. For a custom MVL, you should attempt to reuse an unused primary Id field or column before deciding to create a new custom extension column.
The out-of-the-box field's unused column should have the Foreign Key Table property pointing to the table used by the MVL's business component. Also, the Primary Child Col property should be set to TRUE and the Primary Child Table, Primary Child Join Column, and Primary Join Column Name properties should be set with an appropriate value. For many-to-many (M:M) relationships, the Primary Inter Table Name should point to the intersection table. You cannot set these values for out-of-the-box base table columns, so you are simply making sure that the unused field or column is an appropriate primary Id field.

If an appropriate unused primary field or column is found, you need to verify that it is not already being used by another MVL. Sharing primaries for MVLs that return different result sets is not recommended as it can lead to corruption of the primary. For example, you may have two MVLs to business components against the same table with different search specifications. Sharing a primary Id field for the two MVLs will cause the primary Id field to be populated with the value of "No Match Row Id," since the value of the primary Id field may point to a record not returned by one of the MVLs.

If no suitable unused primary Id field or column is found, then you should extend the base table and create a custom field. Note that the EIM Table Mapping Wizard does not automatically create EIM Explicit Primary Mapping objects for custom primary Id fields.

For more information about Primary Id Fields, see Configuring the Primary ID Field.
Use of 1:1 ATTRIB columns. Siebel Systems provides a number of 1:1 tables (for example S_CONTACT_X, S_ORG_EXT_X) which contain generic ATTRIB columns that can be used when no other suitable field or column exists. In certain cases, when a new attribute is required, you should consider using these ATTRIB columns instead. However, there are cases when you should extend a base table with a custom extension column instead:
- For foreign keys and primary Id fields, the base table should always be extended to aid performance.
- Columns that are frequently queried or are always present in the result set. For example, fields that are in the initial list views of a screen or fields that have their force active or link specification properties set to TRUE.
  NOTE: When reusing an existing ATTRIB column, make sure that it is not used by another field. If it is, choose another unused ATTRIB column.
  
  For more information about 1:1 extension tables, see Using Static 1:1 Extension Tables.
User key columns or fields. Fields or columns that are part of the user key of a table should not be used for the purposes other than which they were intended. Doing so could result in performance degradation.
For more information about performance, see Performance Tuning Guide.

In addition, if the user key column is a foreign key to a table, and you are misusing it by populating a non-foreign key value or a foreign key to a different table, then this may cause issues with EIM. EIM relies on the user key to identify a unique record, and inappropriately populating a user key column based on a foreign key will prevent its effective operation.
Bounded LOV Columns. When columns have the LOV Bounded property set to TRUE, EIM populates the column only if the corresponding LOV type and value exist in the S_LST_OF_VAL table. To reuse a field or column based on an LOV bounded column and to populate it using EIM, make sure that you use a bounded picklist that uses the same LOV type as the column object.
Inactivated fields. You should not reactivate fields that are currently inactivated in standard Siebel configuration. These fields may be obsolete and be deleted in future releases, or they may be part of future functionality that has not been completed by Siebel Engineering.
Obsolete columns. When deciding to reuse an unused column, you should check the Comments property of the column object to determine if the column is obsolete or not. Using such columns should be avoided as they may be deleted in a future release.
Fields on specialized business components. Fields on specialized business components should only be used for the purposes for which they were intended. Specialized behavior may impact on unintended uses of such fields.

About Reusing Business Component Fields and Table Columns

Related topics