Guidelines for Business Objects Layer

This topic describes guidelines for configuring selected elements in the business objects layer for optimal performance. It contains the following information:

• "Using the Cache Data Property to Improve Business Component Performance"

• "Limiting the Number of Active Fields"

• "Guidelines for Using Calculated Fields"

• "Using Properties to Improve Picklist Performance"

• "Using Primary ID Fields to Improve Performance"

• "How the Check No Match Property Impacts Performance"

Using the Cache Data Property to Improve Business Component Performance

This topic is part of "Guidelines for Business Objects Layer".

To cache on the Siebel Application Object Manager the content of a business component for subsequent use in the same user session (given the same query and search specification), the property Cache Data property must be set to TRUE for the business component. Setting Cache Data to TRUE is appropriate for semi-static data that might be subject to repetitive queries, but that is unlikely to change during the user session.

For some business components, Cache Data is set to TRUE by default. This is done, for example, for the Internal Product business component.

Cache Data must be FALSE for business components that represent transactional data that might change within a user session.

Note: It is recommended that you do not set the Cache Data property of a business component to TRUE and also set the Use Primary Join property of a multi-value link to TRUE. If Siebel CRM modifies the primary record of a multi-value group business component in this situation, then it might not update data for the cached parent.

See also "Using Properties to Improve Picklist Performance".

Limiting the Number of Active Fields

This topic is part of "Guidelines for Business Objects Layer".

Field object definitions are instantiated for each business component when the business component is instantiated, such as by a user navigating to a view containing an applet based on the business component. All such instantiated fields are included in the SELECT statements in generated SQL that is issued to the Siebel database, even fields that are not represented in the user interface with a corresponding list column or other field control.

The set of fields that is instantiated includes those for which the Force Active property is set to TRUE. The Force Active setting of TRUE indicates to the system that it must obtain data for the field every time the business component is accessed, even if the field is not displayed in the current applet; this adds the field to the SQL query each time.

When Force Active is set to TRUE, there is an associated performance cost. Force Active affects performance more significantly when fields are based upon MVLs or joins, because the Siebel application has to create the relationships in the SQL query to retrieve data for these columns.

In most cases, the Force Active property is not required. In general, do not set Force Active to TRUE unless strictly necessary.

Use Force Active only when the field must be included in generated queries, but the field does not appear in the user interface.

Guidelines for Using Calculated Fields

This topic is part of "Guidelines for Business Objects Layer".

Calculated fields provide a convenient way to access and display data in the user interface that is not directly stored in a table. However, calculated fields have a cost associated with them. Consequently, it is important to use them appropriately to fulfill your requirements, and not to misuse them.

Each calculated field is evaluated whenever the business component is queried to provide a value for the field. Extensive use of calculated fields, or usage in certain contexts, can impact performance. Some guidelines are as follows:

• Use calculated fields sparingly. Be sure there is a valid business case for their usage.

• Minimize the complexity of the expressions defined in your calculated fields.

• Minimize the use of calculated fields that perform Sum, Count, Min, or Max calculations, such as for detail records in an MVG business component. In particular, avoid using such fields in list applets, or in More Info form applets. The cost of using such expressions can be significant depending on the number of detail records.

  Whenever data is totaled there are performance implications. It is important to limit the number of records being totaled. For example, totaling the line items in a Quote or Expense report is not resource-consuming. However, summing the expected revenue for all Opportunities is resource-consuming. The latter occurs when you generate a chart. However, charts tend not to be generated frequently. Accessing the Opportunities list view for routine searches and data entry is done frequently.

  
  

  Caution: Never put a sum([MVfield]) in a list column. Doing so requires that a separate query be executed for each record in the list, which is a significant performance issue.

  
  

• Avoid defining calculated fields using complex expressions that provide different values depending on the current language.

• Avoid using a calculated field to directly copy the value of another field.

• Avoid including calculated fields in search specifications, particularly if the calculated fields use functions that are not supported by the underlying RDBMS.

  • If the RDBMS supports the function, then it will have algorithms for performing the calculations efficiently and will return the calculated values with the result set. However, if functions such as EXISTS, Max, or Count are included, then multiple subqueries can be performed, impacting performance.

  • If the function is not supported in the RDBMS, then the Siebel application might have to rescan the entire result set to perform the desired calculation, considerably increasing the time it takes to obtain the results of the query.

  In the first case, the calculations can take place before the results are returned, while, in the second case, they must to be performed in memory, on the Siebel Application Object Manager or client.

  
  

  Note: Even if the calculated field is supported at the RDBMS level, there can be other reasons why a search specification on a calculated field might result in poor performance, such as the lack of an index (for example, when using the LIKE function) supporting the search specification. See "Managing Database Indexes in Sorting and Searching".

  
  

Using Properties to Improve Picklist Performance

This topic is part of "Guidelines for Business Objects Layer".

To cache the content of certain picklists for subsequent use in the same user session, the Cache Data property must be set to TRUE for the PickList Generic business component. By default, this property is FALSE.

Note: Picklists based on PickList Generic display LOV data, which is unlikely to change during the user session, and are thus suitable for caching. Picklists based on other business components display data that could change during a user's session and is thus generally unsuitable for caching.

Also set the Long List property to TRUE for each applicable Pick List object definition. When Long List is TRUE, the focus is not maintained on the current picklist record, thus improving performance for picklists with many records. The default setting of Long List varies for each Pick List object definition.

Using Primary ID Fields to Improve Performance

This topic is part of "Guidelines for Business Objects Layer".

MVGs configured without Primary ID fields require separate queries to display each parent record and each set of child records. For example, for a list applet that displays 10 records and two MVGs per record, a total of 21 queries would be required to populate the applet: one query to populate the parent records and 20 additional queries (two per parent record) to populate the MVGs. The number of queries executed is many times the number actually required.

You can avoid unnecessary queries by configuring a Primary ID field on the master business component. The Primary ID field serves as a foreign key from a parent record to one primary child record in the detail business component. This allows the application to perform a single query using an SQL join to display values for the parent record and the primary child record in the applet. In other words, it defers having to perform additional queries for the MVG until the user opens the MVG and displays a list of all child records.

List applets receive the most performance benefit from using Primary ID fields because list applets typically access a large number of records and each record can have one or more MVGs associated with it. The Primary ID field avoids having to submit queries for each MVG for every parent record.

Form applets can also benefit from Primary ID fields, even though in form applets only one parent record is accessed at a time. A Primary ID field allows the application to submit a single query for each new parent record displayed, rather than having to perform multiple queries for every MVG on the form applet. This can improve performance as the user moves from one record to another.

In some circumstances, configuring a Primary ID field is not desirable or feasible:

• When Microsoft SQL Server is being used, and the creation of the primary join would create a double-outer-join situation prohibited by the Microsoft software

• When the only purpose of the multi-value field is to sum detail record values

For information on how to configure Primary ID fields, see Configuring Siebel Business Applications.

How the Check No Match Property Impacts Performance

This topic is part of "Guidelines for Business Objects Layer".

In most cases, the Check No Match property of a Multi Value Link object definition (used to implement Primary ID fields) must be set to FALSE. Setting the Check No Match property to TRUE could negatively impact performance, especially in situations where most parent records do not have child records defined in an MVG.

The Check No Match property defines whether a separate query must be used to populate an MVG when no child record is found through a primary join.

• When Check No Match is set to FALSE, the application does the following:

  • If a parent record's Primary ID field is invalid or has the value of NULL, then a secondary query is performed to determine whether there are child records in the MVG. If there are no child records, then the Primary ID field is set to the value NoMatchRowId.

  • If a parent record's Primary ID field has the value NoMatchRowId, then the application does not perform a secondary query, because NoMatchRowId indicates that there are no child records in the MVG. Avoiding these extra SQL queries improves performance.

  
  

  Note: NoMatchRowId is not a permanent setting; the Primary ID field can be updated after it is set to NoMatchRowId.

  
  

• When Check No Match is set to TRUE, a separate SQL query is executed for each parent record in which the primary join did not find a primary child record. Doing this ensures that the multi-value field does not appear blank unless there are no child records. But executing these extra SQL queries decreases performance.

It is appropriate to set the Check No Match property to TRUE in the following cases:

• When the multi-value group allows records to be added without having to go through the MVG. For example, account addresses might actually be inserted through the Business Address multi-value group on the Contact business component instead of the Account business component.

• When records can be added to a detail business component through Siebel EIM.

For more information about configuring Multi Value Link object definitions, see Configuring Siebel Business Applications.