Thursday, Jan. 18, 2018

Siebel Configuration Best Practices

Written By:


January 6, 2013


Posted In:

In this article we’ll understand some standard best practices to be taken while starting and configuring a new Siebel project:

1)      Planning: The planning approach to be followed should be Top-Down approach, but while you make the actual changes, the approach to be followed should be Bottom-Up.

2)    Application Changes: When the standard Siebel applications are customized for an organization/business, the best thing is to make minimal changes. This will reduce the chance of getting unexpected error prompts. Because vanilla Siebel has so many flavours to support various business features. Most effective thing is to keep the existing Siebel object definition as it is whenever it is possible. Because, it gives chance to maintain and upgrade the application as and when required. The Thumb rule in Siebel Configuration is to make modifications in the existing Siebel repository objects or copying from the existing repository rather than creating new repository objects. The important point is, to avoid deleting or inactivating the existing Siebel object as they may be referred by other objects.

3)    Business Component: When the existing business components are copied/ cloned, then system fields on business components should not be defined. There should be a proper naming convention to name all the business objects and business components with a prefix that defines the project. Also the names provided to the business objects should be meaningful and descriptive in nature so as to be used for future enhancements and maintenance.

4)    Views: Similar to Business Components, Modifying or reusing the existing views would be the better option than creating new views or copying the existing views. New views can be created if there are no existing views available for reuse. A proper naming convention (meaningful descriptive name) should be used to identify the views. When a view is used within the application, then the view should be defined in the master reference data. Also there should be association of responsibilities to that view. Otherwise the view will be void.Views can be a problem towards application performance, so care should be taken about these views :
1)     Views that are known to have the biggest performance bottlenecks.
2)     Views that are accessed most frequently.
3)     Views that are the most highly configured (as compared to the standard Siebel application).

5)    Applets: Applets can be copied from the existing ones, only when there is a need to make major changes. But the best thing is to modify the existing applets. Reusing/modifying the existing applets is the best methodology when compared to copying the existing applets.

1) When the existing applets are reused or modified, the object definition will remain intact and chances for error prompts are less.
2) Limiting the number of applets used for the business Objects and Business Components will increase the application performance.

Cons :
1) When the existing applets are copied, the chances are very high for duplication. It     needs great deal of attention for updating the object definition.
2) Creation of new applets will result in maintenance overhead. It is hard to maintain and upgrade to future Siebel product releases as the newly created applets many not carry the standard Siebel Object definition.

6)    Scripting:

We have an entire article dedicated to Escript best practices :

E-Script Best Practices

7)  EIM :

We have an entire article dedicated to EIM best practices :

EIM Best Practices


Share This Article

About Author


Siebel Technical Consultant

Comments are closed.

Leave A Reply