Tuesday, December 7, 2010

Siebel Configuration Best Practices

Sort Specification

All the indices in the Siebel data model are implemented in ascending ( ASC ) Order.
Business Components & Pre-defined queries should never be configured for descending order.

Make sure the sort order sequence on the Business components as well as Pre-defined queries is same
as the indices

Non-Indexed Search / Sort Specifications

  • Use fields mapped to index columns only

  • Similarly Pre-defined queries filter or sort should not be based on non-indexed columns

  • Exact index sequence

  • Search affects WHERE and sort affects ORDER BY clause of the SQL

 Force Active & Link Specification

Always set them to FALSE unless the field is used in Script or Workflow or EAI and the field is not
present on UI

In case the field needs to be used in script we donot need to make the force active true , we can use the ActivateMethod instead

Multi-Value Link

Primary Id field

Always identify a Primary Id field and set the Use Primary Join Property to TRUE

Do not set No Delete , No Insert , No Update Properties at BC Level

Defining Ancestory of Custom Objects

Cloned Object should have their "Upgrade Ancestor" property set to gain the benefit of new functionality
that may be applied to original object from which it was cloned during Siebel Application Upgrade

Required Property

Set Required Property to TRUE for the required fields instead of writing code

Creating Extended Columns

Always try to create extension columns on base table

Never create extention columns on extended tables ( S_CONTACT_X.X_ACTIVITY_STATUS) ,
instead use ATTRIB fields which are not reserved for upgrade purpose by Siebel

Comment Configuration Changes

Usage of Count & Sum must be limited

Count & Sum functions should not be in calculated fields to determine the number of child records.
This will increase the network traffic too.These fields degrade the performance , as a seperate SQL is being fired for each parent record to get the number / sum of children record set.

Using Pre-Default Value

Most of the times developers with Programming background write code for example in the Business service
PreInsert event to initialize some of the fields on the business component.This functionality can be achieved by defining Pre-defualt Value on the Business Component field

Using Post-Default Value & User Properties

Most of the times developers with Programming Background write code for example in the
PreWriteRcord event to populate these fields.This functionality can be achieved by defining Post default value for the field on the Business Component.This can also be achieved by defining a user property "On
Field Update Set" on the field without the need to write the script.

Using ForceCase Property

It has been noticed that sometimes developers in some of the BusComp_PreQuery event , a translation
is being carried out to force the search specification to upper case.Set ForceCase property of the corresponding field to UPPER to get the same functionality

Reduce the number of applets

There has been many instances found in several siebel projects where there are more than 5 applets
per view.Siebel recommends the number of applets to be 2 per view.

Configuration Naming Standards

Standard naming convention for configuration must be followed.This will greatly simplify maintenance
and troubleshooting efforts.

Custom Business Components for smaller applets

Sometimes we have requirements for creating applets with only 4-6 fields and displaying them.It may be worthwhile moving the applet to a Custom BC with only fields necessary to be shown on the applet.This will reduce the size of the SQL between the client and the server and reduce the network traffic.

Do not have Hard Coded Values

Calculated fields , Search specs and Business Component User Properties must not have Hard coded values.

For Example :- IIf ( Deal Type ='PIC',"Y","N") must be formatted as

IIf ( [Deal Type] = Loopup("SUBMITTAL_TYPE","PIC"),"Y","N")

Make minimal changes to standard siebel application

It is usally best to make minimal changes to the standard siebel application;this will reduce the possibility of unexpected errors etc.You should use existing Siebel Object definitions wherever possible.This will make the application easier to maintain and upgrade.General rule of thumb is to modify existing siebel repository objects or copy existing repository objects rather than create new objects.Also donot delete / inactivate existing Siebel Objects as they may be referenced by other objects.

No comments:

Post a Comment