Siebel Configuration Best Practices

1. Adding System Columns as BusComp Field Objects Definitions

System columns are exposed as BusComp fields. These columns can be exposed as controls or list columns on applets without explicitly defining them in the BusComp definition.

System Field	System Column Name	Description
Id	ROW_ID	Primary key for the table
Created	CREATED	Creation date and time of the row
Created By	CREATED_BY	User logon ID of the person who created the row
Updated	LAST_UPD	Date of last update of the row
Updated By	LAST_UPD_BY	User logon ID of the person who last updated the row

Consequence

The fields Id, Updated, Updated By, Created, and Created By are available system fields that can be exposed and presented in the user interface or used in script without explicitly defining them as BusComp fields.

This introduces a data integrity issue, if such a field is exposed in the UI and the user enters data into it, the data will not be saved to the database. The application will ignore the user’s data and use the system data. When a user enters a value in such a field and later accesses the same record, they will not see the value entered.

Recommendation

Do not create BusComp fields mapped to system columns, as they are available for use in configuration and scripting without being explicitly defined, and doing so may introduce the type of issues indicated above in the consequence section.

Where such fields have been created, remove them from the BusComp definition and remap any existing references, such as list columns, controls, joins, and so forth to the supplied system column. Do not forget to verify that any script that references the custom fields is also updated.

2. Join Specifications on S_PARTY Extension Tables

Join specification to Party extension table has been created with the destination column property set to ROW_ID.

Consequence

Only the PAR_ROW_ID column should be used as the destination column in join specifications to S_PARTY extension tables. This is because the PAR_ROW_ID column contains the proper foreign key relationship to S_PARTY.

Although ROW_ID and PAR_ROW_ID is equivalent in most cases for party extension tables, configuring a join in this manner is not recommended, and this unexpected behavior may not be the case in future releases and this accidental success may not be the case in future releases if the table structures change.

Recommendation

When creating joins to S_PARTY extension tables such as S_ORG_EXT, S_CONTACT, S_POSTN or S_USER make sure that the join specification has a destination column of PAR_ROW_ID. Perform a search in the Siebel Tools and look for the Base table property to identify the S_PARTY related tables. The screenshot below shows some of the S_PARTY tables in the customer repository.

3. Non-Indexed Search / Sort Specifications

Several search and sort specifications were identified as keying off non-indexed columns. When specifying search and sort specifications it is important to use fields mapped to indexed columns, whenever possible.

Sorting or searching on non-indexed fields can have detrimental effects on database performance, especially on large tables, as it will produce table scans and temporary tables in the SQL execution plan.

Keep in mind that pre-defined queries where the filter or sort is based on a non-indexed column will also result in a performance impact.