Dinesh Wp Configuring Siebel Front End For Optimal Performance

BEST PRACTICES

R
Siebel Enterprise Applications – Configuring the Front-End for Optimal Performance

E
Q
U
I
R
SIEBEL BEST PRACTICES
E
M
Topic: Configuring the Front-End for Optimal
Performance
E
N
T
S
D
E
Created: Dinesh Chandrasekar Page 1 of 19
F Sierra Atlantic Proprietary &

I
Confidential

N

BEST PRACTICES

R

E
OVERVIEW .................................................................................................................3
D ISCUSSING P I
ERFORMANCE SSUES WITH THE C LIENT ........................................4
T P
OP RIORITYC ONSIDERATIONS Q
...........................................................................5
Using a Sort Specification on a Non-Indexed Column ............................................................... 5

U
Using a Search Specification on a Non-Indexed Column ........................................................... 5
Using a Search Specification on a Calculated Field .................................................................... 5
List Applets Containing Multi Value Links That Do Not Have A Primary Id Field ................ 5

S
List Applets Containing Multi Value Links That Have “Check No Match” Set to “TRUE” ... 6
ECOND P RIORITY C ONSIDERATIONS
I
....................................................................8
Number of Business Components Per View ............................................................................... 8
Form Applets Containing Multi Value Links That Do Not Have A Primary Id Field ............. 8
Form Applets Containing MVLs That Have “Check No Match” Set to “TRUE” .................... 8
R
Number of Joins, Extension Tables, and Primary MVLs per Business Component .................. 8
T HIRD P RIORITYC ONSIDERATIONS E
.......................................................................9
Number of Fields Used per Business Component ....................................................................... 9

B EST P RACTICES
M
Joins that can be Inner Joins Instead of Outer Joins ................................................................... 9
.....................................................................................................11
Analyzing SQL Statements ...................................................................................................... 11
E
Comparison with Vanilla Siebel................................................................................................ 15
Coaxing the Optimizer into Using the Best Indices ................................................................. 15
Removing Sort Specifications ................................................................................................... 16
Search Specifications and Sort Specifications Using the Same Index ...................................... 16 N
Enforcing Case Sensitivity ........................................................................................................ 16
Adding Indices .......................................................................................................................... 17
Search Specifications in Business Components Instead of in Applets or in Pick Lists ............ 17
Putting Sort Specifications in Business Components Instead of in Pick Lists ......................... 18
T
Using a New View in Place of an MVG ................................................................................... 18
Deciding Between Extension Columns and Extension Tables ................................................. 18 S
Avoiding Automatically Displayed Totals ............................................................................... 18
Queries in Siebel Visual Basic .................................................................................................. 18
Using the Cache Data Property on a Business Component ..................................................... 18
D
Setting the Long List Property on a Pick List ........................................................................... 19

E

I
Confidential

N

BEST PRACTICES

R

OVERVIEW
E
Q
This document contains Sierra‟s Best Practices for Configuring the Front-End for Optimal
Performance for Siebel Enterprise Applications. It assumes that the reader has a general
knowledge of front-end configuration principles and of database theory.For the most part, this
document does not contain information already contained in Siebel documentation unless it is
U
among the more important practices. It does include research from Sierra implementations,
competitor implementations, and from Siebel‟s Support Web Site.
The issues contained in this document are organized by priority. The higher priority
I
considerations have a higher probability of causing performance problems, and are also
associated with more severe problems.

R
E
M
E
N
T
S
D
E

I
Confidential

N

BEST PRACTICES

R

DISCUSSING PERFORMANCE ISSUES WITH THE CLIENT
E
Q
This document will help developers identify potential performance issues with configuration
requests. We must be careful to handle these issues properly with the client. Our clients must
not get the impression that Siebel is a slow system – it‟s not. At the same time, we must ensure
that clients are aware of any issues that may arise. It can be very difficult to balance these two
U
maxims. Let us take an example of a client who wishes to have seven MVGs on a list applet.
This means that Siebel must execute up to eight separate SQL statements to display a record in
the list applet (one for the applet itself and one for each of the seven MVGs to display the initial
I
value). It would be inappropriate to simply say to the client that performance will be poor.
First, this may lead the client to think that Siebel is a slow system. Second, performance is a
result of several factors, such as network speed, database configuration, and processing speed.

R
A list applet with seven MVGs may not exhibit poor performance depending on these and other
factors. However, the client should be made aware in advance that performance issues might
arise. This is not a result of anything specific to Siebel, it is simply the result of a large amount

E
of SQL hitting the database. A good way to approach this with a client is as follows: “As I‟ve
been reviewing our design, I‟ve noticed that this applet is going to be displaying a lot of
information from a lot of different tables. As with any application, the more tables that have to

M
be accessed, the more time it takes to retrieve the information from these tables. Sometimes,
this can result in slow performance. This isn‟t because of Siebel; we could run the SQL directly
against the database and it wouldn‟t go much faster. It‟s just a result of the fact that it‟s a

E
complex SQL statement. We‟ll make sure to carefully monitor this as we get closer to
production, but I wanted you to be aware of this possibility in advance. It may mean that we‟ll
redesign the screens for better performance.” This way, the client is aware of the issue but is
not concerned that they made the wrong choice by purchasing Siebel. Sierra has routinely
N
generated a high customer satisfaction rating for Siebel‟s clients. As Premier Partners, we must
continue to deliver this level of satisfaction and promote the high quality of the Siebel software.

T
S
D
E

I
Confidential

N

BEST PRACTICES

R

TOP PRIORITY CONSIDERATIONS
E
Using a Sort Specification on a Non-Indexed Column Q
If a sort is performed on a non-indexed column, Siebel performs a full table scan to retrieve the

U
data. The data are also sorted in a temporary table that must be created to perform the sort. For
tables containing many records, this can be a very time-consuming process. As an example, an
implementation had a Sort Specification on a non-indexed column in the Account table. With
100,000 Accounts, it took seven minutes between the time a user clicked to open the Account
I
Pick List and the time that the Pick List actually opened. Once the Sort Specification was
removed, the Pick List appeared in three seconds. Unindexed Sort Specifications should never
be used on tables containing a large number of records.
R
As a note, people often respond to this statement by asking, “How many records is a large
number?” The answer is that it depends on several factors. Since there is no hard-and-fast rule,
it is best just to be aware of this consideration if performance issues arise.
E
Using a Search Specification on a Non-Indexed Column

M
If a Search Specification is applied to a non-indexed column, Siebel may perform a full table
scan to retrieve the data. For tables containing many records, this can be a very time-consuming
process. For these tables, Search Specifications should always be performed on indexed
columns.
E
Using a Search Specification on a Calculated Field

N
If a Search Specification is applied to a calculated field, Siebel performs a full table scan to
retrieve the data. For tables containing many records, this can be a very time-consuming
process. For these tables, Search Specifications should never be performed on calculated fields.

T
List Applets Containing Multi Value Links That Do Not Have A Primary Id Field
Siebel always displays a value in a multi-value field if that MVG has child records. For
S
example, in the Account List Applet one of the Account‟s addresses is displayed when the
Account List Applet is populated. The remaining addresses are displayed when the Address
MVG is opened. The point here is that, if the Account has one or more addresses, Siebel will

D
display one in the MVG. To rephrase in generic terms, if a record has an MVG that has one or
more child records, Siebel will display one of the child records in the MVG.
The Primary Id Field property of a Multi Value Link specifies the field that holds the ROW_ID

E
of the one primary child record. When Siebel needs to display one of the child records in an
MVG, if the corresponding MVL has a Primary Id Field and has the Use Primary Join property
set to “TRUE” then Siebel will use that field to join directly to the primary child record and

F
display it in the MVG. If there is no Primary Id Field on the MVF, Siebel will execute a second

Sierra Atlantic Proprietary &

I
Confidential

N

BEST PRACTICES

R

E
query against the child Business Component to retrieve all child records; one will be displayed
in the MVG. Since this second query is performed for each parent record, this can cause poor
performance in list applets. Let us take the example of a list applet that has an MVG that does
Q
not have a Primary Id Field. If the list applet displays fifteen records, Siebel will need to
execute sixteen separate SQL statements to display the list applet (one for the list applet itself
and one for the MVG for each of the fifteen records to display the initial value in the MVG). List

U
applets should never contain MVGs that do not have a Primary Id Field.
As a design note, many MVG Applets have a “Primary” field that places a checkmark next to
the primary child record. It is not necessary to display this “Primary” field in the MVG Applet
I
to obtain the performance benefits. It is only important that the underlying database contain
this value.

List Applets Containing Multi Value Links That Have “Check No R
Match” Set to
“TRUE”

E
The Check No Match property tells Siebel that if no record is found while trying to execute a
Primary Join to a child record then Siebel should execute a second query to retrieve all child
records. Setting this property to “TRUE” can cause poor performance unless nearly all parent
records have child records through the MVG. For the most part, the only MVLs that have the
M
Check No Match property set to “TRUE” are the Address MVLs. This is because a) most
records that can have addresses (such as Accounts, Opportunities and Contacts) do have
addresses, and b) the address functionality is critical to much of the other functionality in Siebel
E
such as Territory Assignment. MVLs that match these criteria are the only MVLs that should
have the Check No Match property set to “TRUE”. Otherwise, similar to the case of MVLs that
do not have a Primary Id Field, a second query will be executed for each record in the list
applet.
N
Exhibit 1 contains information about the relationship between the Primary Id Field property
and the Check No Match property.
T
S
D
E

I
Confidential

N

BEST PRACTICES

R

E
Does MVL Have a Primary Check No Match Results
Id Field?
No TRUE
Q
Siebel will always execute a
second query for each record

No FALSE
U
in the parent applet.
Siebel will always execute a
second query for each record
I
in the parent applet.
Yes TRUE Siebel will execute a second

R
query for each record in the
parent applet if that record
either does not have a value in

E
the Primary Id Field or if a
match cannot be found
between the Primary Id Field
and a ROW_ID in the child
table. M
Yes FALSE This generates the best

E
performance. Siebel will not
perform the second query for
the child records until and

N
unless the MVG is opened.
Exhibit 1: Relationship Between the Primary Id Field Property and the Check No Match Property

T
As a reminder, the Use Primary Join property must be set to “TRUE” for the Primary Id Field to
be used. Even if there is a Primary Id Field, Siebel will not perform the join unless the Use
Primary Join property is set to “TRUE”.

S
D
E

I
Confidential

N

BEST PRACTICES

R

SECOND PRIORITY CONSIDERATIONS
E
Number of Business Components Per View Q
Siebel must execute a separate SQL statement for each Business Component that appears in the

U
applets in a view. If the client‟s business requirements allow, it is best to minimize the number
of Business Components in a view. For example, instead of creating an Account view that
displays Accounts in one applets, Contacts for the Account in another, and Opportunities for
the Account in another, it is best to split this into two views. One should contain the Account
I
and its Contacts, the other should contain the Account and its Opportunities.

R
Form Applets Containing Multi Value Links That Do Not Have A Primary Id Field
The functional issue here is the same as with list applets. However, because form applets only
display one record at a time, only one additional query will be executed for each MVG. This is

E
the reason that this is a second priority issue.

Form Applets Containing MVLs That Have “Check No Match” Set to “TRUE”

M
The functional issue here is the same as with list applets. However, because form applets only
display one record at a time, only one additional query will be executed for each MVG. This is
the reason that this is a second priority issue.

E
Number of Joins, Extension Tables, and Primary MVLs per Business Component
There are three items in a Business Component that can cause a join to be executed. The first is
N
an explicitly defined join. The second is if Siebel needs a field in an extension table for a
Business Component. Siebel needs to perform a join to get to the extension table. (As a note,
such joins do not need to be explicitly defined. When an extension table is created, a join is
T
implicitly defined.) Third is a Multi Value Link that has a Primary Id Field and has Use
Primary Join set to “TRUE”. This type of join is defined elsewhere in this document.
Performance issues are not a result of simply having joins, extension tables, and MVLs in a
S
Business Component. The potential issues revolve around the number of these that are used by
Siebel at any one time.

D
E

I
Confidential

N

BEST PRACTICES

R

THIRD PRIORITY CONSIDERATIONS
E
Number of Fields Used per Business Component Q
Siebel will only execute SQL that is necessary for it to retrieve data from the necessary columns

U
in the database. A database column is considered necessary if a) the values in that column will
be displayed in an applet in the current view, b) the Force Active property for the Business
Component Field is set to “TRUE”, or c) the Link Spec property for the Business Component
Field is set to “TRUE”. Let us take the example of a Contact applet that displays the name of the
I
Contact‟s Account. In this case, Siebel will perform a join to get to the NAME field in the
Account table. Let us take another example of a Contact applet that does not display the name
of the Contact‟s Account. Assuming the field in the Contact Business Component that contains
R
the Account name is not forced active, Siebel will not perform a join to get to the NAME field in
the Account table.
The Force Active property tells Siebel to always retrieve the data for the field regardless of
E
whether it will be displayed in an applet. This is often used for Search Specifications when the
field used in the Search Specification is not displayed to the user. The field must be forced
active so that Siebel will retrieve the data and can perform the search.
M
The Link Specification property is set to “TRUE” to make the value in the field available to
“Parent:” default values in child Business Components. For example, the Action Business

E
Component (used by Activities and the Calendar) has a field that stores a Contact‟s Job Title.
The Pre Default Value for this field is “Parent: 'Contact.Job Title'”. This means that when an
activity is created with the Contact Business Component as Parent and the Action Business
Component as child, the Contact Job Title field in the Action Business Component will pre
N
default to the value of the Job Title field in the Contact Business Component. For this to work,
the Job Title field in the Contact Business Component must have the Link Specification property
set to “TRUE”.

Joins that can be Inner Joins Instead of Outer Joins
T
S
Siebel can perform two different types of joins when joining one table (the source table) to
another (the target table). This is specified by the Outer Join property of a Join. An outer join
retrieves all records in the source table and all values in the target table where the joined
columns are equal (technically, this is actually a left outer join – Siebel cannot perform right

D
outer joins). As an example, the join from the Contact Business Component to the Account table
is an outer join. The Contact Business Component will retrieve all Contacts, and will retrieve
the information from the Account table if the Contact has a foreign key to an Account. An inner

E
join retrieves only those records in the source table where there is a foreign key to an Account.
If the above join were an inner join, Siebel will only retrieve those Contacts that have Accounts.
Therefore, this join must be an outer join since some Contacts do not have an Account.


I
Confidential

N

BEST PRACTICES

R

E
When all records in the source table will have a corresponding record in the target table, an
inner join can be used. Inner joins generate faster performance than outer joins. As an example,
the Opportunity Product Business Component uses an inner join to join to the product. This is
Q
because this Business Component is based off of the S_OPTY_PROD table. This table requires
that all records have a foreign key to the product table. There can never be a record in this
Business Component that does not have a corresponding product. Therefore, an inner join can
be used.
U
I
R
E
M
E
N
T
S
D
E

I
Confidential

N

BEST PRACTICES

R

BEST PRACTICES
E
Analyzing SQL Statements Q
Siebel can be set to spool out the SQL that it generates while running. To do this, right-click on

U
the Siebel icon on your desktop. Click on Properties. Click on the Shortcut tab. To the existing
information in the Target section, add “/s c:siebelbinXXXXXX.sql” where “XXXXXX”
represents the file name of your choice. This is illustrated in Exhibit 2.

I
R
E
M
E
N
T
Exhibit 2: Setting Siebel to Spool SQL Statements S
D
Siebel will copy all SQL statements to this file. The file can then be opened with WordPad and
reviewed. Notepad should not be used since the formatting will be lost.
Siebel sends each and every SQL statement to this file as it is executed. This brings up two

E
considerations. First, when analyzing the SQL from a particular view or applet, it is best to go
into Siebel, go directly to the view or applet, and close Siebel as soon as the query is complete.
This file can become very large very fast as a user spends much time in Siebel. Second, it is best
to start looking for your SQL statement at the bottom of the file. Siebel generates a number of

F
SQL statements during startup before the application even appears. These are related to tasks

I
Confidential

N

BEST PRACTICES

R

E
such as verifying the user‟s login information, retrieving system preferences from the database,
checking the user‟s Responsibilities and Views, and retrieving today‟s appointments from the
Activity table. These statements will appear at the beginning of the file.
Q
Analysis of these SQL statements can provide ideas for improving performance. Exhibit 3
provides an example of an SQL statement from the “My Accounts” view that will be briefly

U
analyzed for performance.
SELECT
T1.ROW_ID,
T1.MODIFICATION_NUM,

I
T1.CREATED_BY,
T1.LAST_UPD_BY,
T1.CREATED,
T1.LAST_UPD,
T1.CONFLICT_ID,
T1.PAR_OU_ID,
T2.LOC,
T2.NAME,
T3.NAME,
R
T1.CURR_PRI_LST_ID,
T1.PR_ADDR_ID,
T1.PR_REP_ASGN_TYPE,
T1.PR_BL_ADDR_ID,
E
T1.PR_BL_PER_ID,

M
T1.PR_INDUST_ID,
T1.PR_POSTN_ID,
T1.PR_SRV_AGREE_ID,
T1.PR_SHIP_ADDR_ID,
T1.PR_SHIP_PER_ID,

E
T1.PR_SYN_ID,
T1.PR_TERR_ID,
T1.PR_OU_TYPE_ID,
T1.REGION,
T1.OU_TYPE_CD,
T1.CUST_STAT_CD,
T1.ASGN_PH_AC,
T1.ASGN_PH_CC,
T1.ASGN_USR_EXCLD_FLG,
N
T1.CMPT_FLG,
T1.BASE_CURCY_CD,
T1.DIVISION,
T1.URL,
T
T1.LOC,

S
T1.LOCATION_LEVEL,
T1.MAIN_FAX_PH_NUM,
T1.MAIN_PH_NUM,
T1.NAME,
T4.NAME,

D
T5.NAME,
T6.ZIPCODE,
T6.STATE,
T6.ADDR,
T6.CITY,
T6.COUNTRY,
T7.NAME,
T9.NAME,
T9.ROW_ID,
T8.ROW_STATUS,
E
F
T9.PR_EMP_ID,
T10.LOGIN,
T8.ASGN_TYPE,
Created: Dinesh Chandrasekar Page 12 of 19 Sierra Atlantic Proprietary &

I
Confidential

N

BEST PRACTICES

R
T8.ACCNT_LOC,
T8.ACCNT_NAME,
T8.POSITION_ID,
E
T4.ROW_ID,
T5.ROW_ID,
T6.ROW_ID,
T7.ROW_ID,
T9.ROW_ID,
Q
T8.ROW_ID
FROM
U
SIEBEL.S_ORG_EXT T1 LEFT OUTER JOIN SIEBEL.S_ORG_EXT T2 ON T1.PAR_OU_ID = T2.ROW_ID,
SIEBEL.S_ORG_EXT T1 LEFT OUTER JOIN SIEBEL.S_PRI_LST T3 ON T1.CURR_PRI_LST_ID =
T3.ROW_ID,

I
SIEBEL.S_ORG_EXT T1 LEFT OUTER JOIN SIEBEL.S_INDUST T4 ON T1.PR_INDUST_ID = T4.ROW_ID,
SIEBEL.S_ORG_EXT T1 LEFT OUTER JOIN SIEBEL.S_ORG_SYN T5 ON T1.PR_SYN_ID = T5.ROW_ID,
SIEBEL.S_ORG_EXT T1 LEFT OUTER JOIN SIEBEL.S_ADDR_ORG T6 ON T1.PR_ADDR_ID = T6.ROW_ID,
SIEBEL.S_ORG_EXT T1 LEFT OUTER JOIN SIEBEL.S_TERR T7 ON T1.PR_TERR_ID = T7.ROW_ID,
SIEBEL.S_ACCNT_POSTN T8 JOIN SIEBEL.S_POSTN T9 ON (T9.ROW_ID = T8.POSITION_ID, 1),

T8.OU_EXT_ID,
R
SIEBEL.S_ORG_EXT T1 JOIN SIEBEL.S_ACCNT_POSTN T8 ON T8.POSITION_ID = ? AND T1.ROW_ID =

SIEBEL.S_POSTN T9 LEFT OUTER JOIN SIEBEL.S_EMPLOYEE T10 ON T9.PR_EMP_ID = T10.ROW_ID
WHERE

E
(T1.OU_TYPE_CD = ?)
ORDER BY
T8.POSITION_ID, T8.ACCNT_NAME, T8.ACCNT_LOC

M
Bind variable 1: 0-5220
Bind variable 2: Commercial

***** SQL Statement Execute Time: 0.050 seconds *****
Exhibit 3: Sample SQL From the “My Account” View
E
We will look at three examples from this SQL statement. First, look at the bold and shaded

N
“S_PRI_LST” in the FROM clause. This indicates that Siebel is looking for the Account‟s Price
Lists. If your client does not need to have the Price Lists displayed in the “My Account” view,
you can remove these fields from the applets. Then, Siebel will not join to this table to get Price
Lists. This will remove this join from the FROM clause in this SQL statement.
T
Second, look at the bold and shaded WHERE clause and the bold and shaded bind variable.
This is not the forum for a detailed explanation of bind variables, but a brief and moderately

S
accurate explanation is required for those readers who may not be familiar with them. The
WHERE clause contains a question mark. At runtime, Siebel inserts the bind variable into the
SQL statement to replace these question marks. Bind variable 1 will be inserted into the second-

D
to-last line of the FROM clause for the POSITION_ID. Bind variable 2 will be inserted into the
WHERE clause. This indicates that Siebel is looking for Accounts where the value of the
OU_TYPE_CD column is “Commercial”. Apparently, this Business Component was designed
to display only commercial Accounts since WHERE clauses are the result of Search
E
Specifications. Looking in Siebel Tools at the indices on the Account table, we can see that there
is no index on this field. These can be found in the Table Folder under Index -> Index Column.
None of the indices in the S_ORG_EXT table have OU_TYPE_CD as an Index Column. To

F
improve performance, either a) a different field that has an index should be used to store this


I
Confidential

N

BEST PRACTICES

R

E
information, or b) your Technical Account Manager can investigate the possibility of creating an
index on this field. These options are all discussed in greater detail in the Best Practices
Examples section of this document.
Q
Third, look at the bold and shaded ORDER BY clause. ORDER BY clauses are either the result
of a Sort Specification or of the automatic use of an index. If there is no Sort Specification on a

U
Business Component, Siebel will automatically sort by using an index. Look at the “T8” in the
ORDER BY clause. This is an alias for one of the tables in the FROM clause. These aliases are
used throughout the SQL statement, making the statement easier to read. The bold and
highlighted “S_ACCNT_POSTN T8” in the FROM clause indicates that T8 is the alias for the
I
S_ACCNT_POSTN table. Looking at the indices for this table, we see that there is an index that
uses the columns in the ORDER BY clause in the same order. It is the S_ACCNT_POSTN_M1

R
E
M
E
N
T
S
D
E
index and is shown in Exhibit 4.
Exhibit 4: Examining the Columns in the S_ACCNT_POSTN_M1 Index.

F
Since the columns in the SQL statement correspond to the columns in the index, we can focus
on performance improvement opportunities other than the ORDER BY clause.

I
Confidential

N

BEST PRACTICES

R

E
To summarize, the FROM clause is a result of the joins that are used. The WHERE clause is a
result of the Search Specification. The ORDER BY clause is either the result of a Sort
Specification or of the automatic use of an index.
Q
As a note, “All” views automatically ignore a configured Sort Specification and use all or part of
the U1 index for the table on which the Business Component is based. Developers should be

U
aware of this when reviewing spooled SQL so that they do not misinterpret this as a bug.

Comparison with Vanilla Siebel

I
Since performance is a result of several factors, it is best to compare the performance of a
configured version of a view with the performance of the Vanilla version of the view if
applicable. If the Vanilla view performs poorly, the performance issues may be the result of
network or database issues instead of front-end configuration.
R
Coaxing the Optimizer into Using the Best Indices

E
Accounts, Opportunities, and Contacts are the main tables off of which Siebel is based. The
“My Accounts”, “My Opportunities”, and “My Contacts” views are those records of which the
user is part of the Account Team, Sales Team, and Access List accordingly. Team memberships

M
are stored in respective intersection tables with the Position table. These intersection tables are
the S_ACCNT_POSTN, S_OPTY_POSTN, and S_POSTN_CON tables respectively. Generally,
the best indices for the “My” views are on these tables. This is because the best way to perform

E
a query is to first execute those parts of the query that most quickly reduce the number of
records that are retrieved. As an extreme example, let us say that only one out of the 100,000
Accounts in the database is not a commercial Account. It would be much better for Siebel to

N
first narrow down the list of Accounts to those where the user is a member of the team and then
filter for those that are commercial, rather than first retrieving the 99,999 commercial Accounts
and then examining the teams.

T
Siebel is best run on a rule-based optimizer as opposed to a cost-based optimizer. An optimizer
is a component of the database that determines the best way to run a query. However,
optimizers do not always succeed in determining the best way to run a query. Let us return to

S
the SQL in Exhibit 3. The WHERE clause may cause Siebel to first filter the Account table for
commercial Accounts and then look for Accounts where the user is part of the team. It would
be better if Siebel would first look in the S_ACCNT_POSTN table. (Note: your database

D
administrator can use RDBMS tools to analyze the query to see how it is being performed.)
Sometimes the optimizer can be coaxed into using the best indices by modifying the Search
Specification. Looking in the Account Business Component, we see that the Assignment Type
field is using the Position MVL to get to the S_ACCNT_POSTN table. Changing the Search
E
Specification from „[Type]="Commercial"‟ to „[Assignment Type]=”*”, [Type]="Commercial"‟
can coax the optimizer into going to the S_ACCNT_POSTN table first. Notice that the asterisk
is the wildcard character for searches. This means that Siebel will retrieve all Accounts

F
regardless of the Assignment Type. This is the intention. We do not want to change the results

I
Confidential

N

BEST PRACTICES

R

E
of the query, we just want it to perform better. This Search Specification can sometimes cause
the optimizer to use the S_ACCNT_POSTN table and its indices first rather than first looking
through the Account Type field. Your database administrator can analyze the results of the
query to determine if an improvement was made. Performance improvements may also be
readily apparent simply from running the application.
Q
U
The best way to implement this technique is to expose a multi value field in the Business
Component that maps to the POSITION_ID column in the intersection table. This is the field
that should be used in the Search Specification. This will, if successful, coax the optimizer into
using an index in the intersection table that starts with the POSITION_ID column. These are
always the best indices in the intersection tables. I
Removing Sort Specifications
R
Sort Specifications can often be removed without adversely affecting usage of the system.
When there are more than a few hundred records in a table, it is often faster for users to

E
perform a query rather than scrolling to the record for which they are looking. As an example,
if there are 100,000 Accounts in the system, users will never open the Account Pick List and
scroll through 100,000 Accounts to find the record for which they are looking. Instead, they
should be trained to perform a query in the Pick List to find the record.
M
Search Specifications and Sort Specifications Using the Same Index

E
When possible, Search Specifications and Sort Specification for a Business Component should
use the same index. Let us take an example of a Contact Affiliation Business Component that is
based off of the S_CONTACT_XM table. Let us also assume there is another Business

N
Component based off of this table that is storing other types of records. TYPE is a required
column, so it will likely be predefaulted with some standard value such as “AFFILIATION”.
NAME is a required column, and will contain the name of the affiliation (e.g. “Rotary Club”,
“Toastmasters”). Users may want to see these affiliations listed in alphabetical order. The
Contact Affiliation Business Component will need a Search Specification of T
„[Type]=”AFFILIATION”‟ to avoid retrieving the records in the other Business Component.
This will cause Siebel to use the S_CONTACT_XM_M1 index since TYPE is the first column in
S
the index. If the Sort Specification sorted by the NAME field, Siebel would have to perform a
scan because there is no index that has NAME as the first column. However, if the Sort
Specification was „TYPE, NAME‟, Siebel could still use the S_CONTACT_XM_M1 index that it

D
had already used, because these two columns in this order comprise the index. The result will
be the same, but performance will be better. Since the Search Specification and the Sort
Specification are using the same index, the query will be performed faster.

Enforcing Case Sensitivity E
Case sensitive queries are faster than case insensitive queries. Forcing the application to be case
sensitive can be handled with four techniques.


I
Confidential

N

BEST PRACTICES

R

E
First, application-wide case sensitivity is specified in the datasource sections of the CFG file.
Look in your CFG file in the [Local] datasource for the CaseInsensitivity parameter. This
should be set to “FALSE”. This tells Siebel that, throughout the application, all interaction with
the database should be on a case sensitive basis.
Q
Second, Search Specifications can contain a tilde (~) to indicate that this specific part of the

U
query should use the opposite sensitivity setting as in the CFG file. Let us take an example of a
Search Specification on the Contact Business Component where „[Alias]=”Personal”‟ and
CaseInsensitivity=”FALSE” in the CFG. Siebel will perform a case sensitive search on this field.
If the Search Specification was changed to „[Alias]~=”Personal”‟, Siebel would perform a case
insensitive search on this field. I
Third, Predefined Queries can also contain a tilde to indicate that this specific part of the query

R
should use the opposite sensitivity setting as in the CFG file.
Fourth, the Use Default Sensitivity property of a Field in a Business Component indicates
whether queries on that field should, by default, use or not use the sensitivity specified in the

E
CFG. If Use Default Sensitivity is set to “TRUE”, Siebel will use whatever is specified in the
CFG. If Use Default Sensitivity is set to “FALSE”, Siebel will use the opposite of whatever is
specified in the CFG. This property can be overridden with a tilde in a Search Specification or
in a Pre Defined Query.
M
The best approach for optimizing performance is to have CaseInsensitivity=”FALSE” for all
datasources in the CFG file, not to use tildes in Search Specifications or in Predefined Queries,

E
and to set Use Default Sensitivity to “TRUE” for all Fields in all Business Components. If the
client‟s business processes require a case insensitive search on a specific field, the best approach
is to have CaseInsensitivity=”FALSE” for all datasources in the CFG file, not to use tildes in

N
Search Specifications or in Predefined Queries, and to set Use Default Sensitivity to “TRUE” for
all Fields in all Business Components except those that need to be case insensitive.

Adding Indices
T
If necessary, custom indices can be created on a table to help performance. Your Technical
Account Manager should be consulted before creating a new index to ensure there are no

S
adverse effects. New indices can cause poor performance in other areas of the application.

Search Specifications in Business Components Instead of in Applets or in Pick Lists

D
Applets and Pick Lists can also have Search Specifications. However, data are retrieved into the
Business Component first. This means that a separate SQL statement will be issued if there is a
Search Specification in the Applet or Pick List. If such an Applet or Pick List is exhibiting poor

E
performance, it may be better to create a new Business Component with the proper Search
Specification, remove the Search Specification from the Applet or Pick List, and base the Applet
or Pick List off of the new Business Component. New Business Components should not be

F
created in these cases simply as a rule of thumb, but instead should be created only if no other
performance improvement techniques have worked.

I
Confidential

N

BEST PRACTICES

R

Putting Sort Specifications in Business Components Instead of in Pick Lists E
Pick Lists can also have a Sort Specification. However, data are retrieved into the Business

Q
Component first. This means that a separate SQL statement will be issued if there is a Sort
Specification in the Pick List. If such a Pick List is exhibiting poor performance, it may be better
to create a new Business Component with the proper Sort Specification, remove the Sort
Specification from the Pick List, and base the Pick List off of the new Business Component.
U
New Business Components should not be created in these cases simply as a rule of thumb, but
instead should be created only if no other performance improvement techniques have worked.

Using a New View in Place of an MVG I
Where possible, parent-child relationships can be represented by creating a new view rather

R
than creating an MVG. Let us take the earlier example of creating a Contact Affiliations
Business Component. It would be better to display these affiliations by creating a Contact
Affiliations View instead of putting an Affiliations MVG in an existing applet. This will reduce
the number of joins or additional queries that are executed per view. The new view would have
Contacts in the top Applet and Affiliations in the bottom Applet. E
M
Deciding Between Extension Columns and Extension Tables
For additional fields that will always be displayed in the Business Component, it is best to
create extension columns on the base table to avoid the extra join associated with the extension

E
table. For additional fields that will be displayed on only one or a few views, it is best to create
an extension table. Most database platforms have a limit to the number of columns that can
exist in any one table. Also, a large number of columns in one table can exceed the page size of

N
the database.

Avoiding Automatically Displayed Totals

T
For list applets that can display totals, performance can be improved by setting the Total
Displayed property of the List object to “FALSE”. With this setting, users will only see totals if
they explicitly select Show Totals from the Edit menu. The view will initially appear faster, and
users can incur the extra time only if they wish to see totals.
S
Queries in Siebel Visual Basic

D
Developers should keep the concepts described in this document in mind when writing VB that
performs queries. These queries are subject to the same performance issues as queries that are
executed directly from Applets or Business Components.

Using the Cache Data Property on a Business Component E
If the Cache Data property is set to “TRUE” for a Business Component, the data are read once

F
from the database and cached. If the property is set to “FALSE”, the data are retrieved every


I
Confidential

N

BEST PRACTICES

R

E
time they are requested for display in the user interface. Although setting this property to
“TRUE” can improve performance, it should only be set to “TRUE” for Business Components
that contain data that will not change often. As examples, the Pick List Generic Business
Q
Component, which displays List of Values data, has Cache Data set to “TRUE”. The Account
Business Component does not have Cache Data set to “TRUE” because Account data changes
frequently.

Setting the Long List Property on a Pick List
U
I
If the Long List property on a Pick List is set to “FALSE”, Siebel will try to position the cursor
on the current value of the field in the Pick List. Let us take the example of the Account Type
Pick List, which has Long List set to “FALSE”. Assume an existing Account has an Account
Type of “OEM”. When the user clicks on the Account Type Pick List for this Account, Siebel
R
will scroll the list in the Pick List to “OEM” and highlight this selection. This is the default
setting for a Pick List.

E
If there is going to be a long list of records in a Pick List, this functionality can be time
consuming. Because of this, Pick Lists that will display a long list of records have the Long List
property set to “TRUE”. This tells Siebel not to spend the time trying to scroll the list to the
current value. As an example, Pick Lists for Opportunities have the Long List property set to
“TRUE”. M
Please feel free to post your queries and Clarifications to
Siebel. Competency@ SierraAtlantic.com
E
N
T
S
D
E

I
Confidential

N

Dinesh Wp Configuring Siebel Front End For Optimal Performance

Recommandé

Recommandé

Contenu connexe

Similaire à Dinesh Wp Configuring Siebel Front End For Optimal Performance

Similaire à Dinesh Wp Configuring Siebel Front End For Optimal Performance (20)

Plus de Dr.Dinesh Chandrasekar PhD(hc)

Plus de Dr.Dinesh Chandrasekar PhD(hc) (20)

Dernier

Dernier (20)

Dinesh Wp Configuring Siebel Front End For Optimal Performance