| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
 Previous |
 Next |
View PDF |
| Siebel CRM Performance Tuning Guide Siebel Innovation Pack 2015, Rev. A E54321_01 |
|
Previous |
Next |
View PDF |
This chapter discusses how you can avoid common performance-related problems in Siebel Business Applications that stem from customer configuration done using Siebel Tools or Siebel scripting languages. It contains the following topics:
Application development information is also available in the following books on the Siebel Bookshelf and in Siebel Tools Online Help:
Configuring Siebel Business Applications
Configuring Siebel Open UI
Using Siebel Tools
Siebel Developer's Reference
Siebel Object Types Reference
Siebel Object Interfaces Reference
Siebel eScript Language Reference
Siebel VB Language Reference
This topic provides some general guidelines for customer configuration using Siebel Tools.
Using your hardware resources optimally, and configuring your system appropriately, can help you to achieve your performance goals. Consider your resources and requirements carefully, and test and monitor system performance on a continual basis.
Siebel Business Application architecture has been designed and tuned for optimal performance, making use of features such as database indexes, data caching, RDBMS cursors, efficient SQL generation, native database APIs, and so on. However, custom configurations can have various potential performance pitfalls, the impact of which might be amplified in environments with large databases and wide data distribution across servers. Follow the guidelines presented here and in other documentation to avoid such problems.
The following are some miscellaneous configuration guidelines for maintaining optimal performance:
Avoid using sort specifications on nonindexed columns or joined columns. For more information, see "Managing Database Indexes in Sorting and Searching" and other relevant topics.
Avoid overly complex user interface configuration. In general, do not include a large number of applets per view (generally include no more than four applets), or a large number of fields per applet.
Use the performance of standard Siebel views as a benchmark. Custom configurations are customized versions of the standard Siebel Business Applications configuration. The Siebel data model is designed to have good performance for the expected standard queries for the standard views. If a custom view is slow, then verify the performance of the most appropriate standard view for that custom view. If your custom version of the All Accounts view is slow, then verify the performance of the standard All Accounts view. Use this as a benchmark for the custom view and something to compare the performance to.
Limit the number of business components in a view. An excessive number of different business components used in applets in a view can slow down the display of data upon entry into that view. This is because each of the applets must be populated with data.
Limit the number of virtual business components in a view. Avoid using more than two virtual business components in a single view.
Limit the number of fields in business components or applets. There is no set limit on the number of fields in a business component, or the number of list columns in a list applet. However, a business component with too many active fields will have degraded performance. Also, in some database systems it is possible to generate a query that is too large to be processed. See also "Limiting the Number of Active Fields".
In particular, reduce the number of fields that are displayed in the master applet on related views. The information is static and might not be necessary. Additional space will be available on the view for supporting data without users needing to scroll. (This will also provide a usability benefit.)
End users can reduce or increase the number of fields that are displayed in a list applet, by using the Columns Displayed menu option. However, it is best to provide an optimal default number of visible fields for each applet. It is also best to provide the minimum required total number of fields, including those that are hidden by default.
Limit the number of required fields. Required fields are always retrieved from database queries. Consequently, limiting the number of required fields (that is, fields for which the Required user property is TRUE) in your business components can improve performance. See also "Limiting the Number of Active Fields".
Limit the number of records returned. To limit the number of records returned for a business component, you can add a search specification to the business component or to applicable applets or links, or you can define a default predefined query on the view.
Limit the number of joins, extension tables, and primary ID fields in a business component. Joins degrade performance by causing an extra row retrieval operation in the joined table for each row retrieval in the main table. Extension tables and primary ID fields also use joins, although implied rather than explicitly defined, adding a row retrieval operation for each.
The more joins, extension tables, and primary ID fields defined in a business component, the higher the number of row retrievals required in tables other than the main table, with a corresponding performance degradation.
Limit the use of Link Specification property in fields. TRUE settings in the Link Specification property in fields can also slow performance. If TRUE, then the field's value is passed as a default value to a field in the detail business component through a link.
This is necessary if the master business component has a link relationship (in the current business object) with one or more detail business components, and these detail business components utilize the Parent: expression in the Pre Default Value, Post Default Value, or Calculated Value properties in any fields. The master business component must pass the field value to any detail records displayed.
As with the Force Active property, fields with the Link Specification property set to TRUE will be retrieved every time the business component is queried.
Use inner joins rather than outer joins. Inner joins can be used for joined tables, with a resulting savings in overhead, provided that you are guaranteed that all foreign key references are valid.
For example, when the join is from a detail business component to its master, you are guaranteed of the existence of the master. You can configure the join as an inner join by setting the Outer Join Flag property of the Join object definition to FALSE. This improves the performance of queries that use the join. In general, avoid using double outer joins.
Configure Cascade Delete appropriately for many-to-many links. The Cascade Delete property in a Link object definition must be correctly configured for use in a many-to-many link, or the first insertion or deletion in the association applet will be abnormally slow. A link object definition used in a many-to-many relationship is one that contains a non-NULL value for the Inter Table property. The Cascade Delete property in such a link must be set to None.
Remove unneeded sort buttons. Remove sort buttons from list columns in list applets where this capability is not required.
Reduce the need to scroll in a view. Whenever possible, design views that do not require scrolling. (This will also provide a usability benefit.)
Provide tuned PDQs. Provide tuned PDQs (predefined queries) that address most user requirements. Doing so reduces the likelihood of users creating undesirably complex queries. You might also provide guidance to end users on constructing appropriate queries.
Cache business services. Cache business services that must be accessible at all times in a user session. To do this, set the Cache property to TRUE for each applicable Business Service object definition. Caching of business services has an impact on memory, because the services are cached per session. Make sure that only frequently accessed business services in a session are marked cacheable.
Avoid calculated fields that do Counts and Sums. Reduce, where possible, the use of calculated fields that do Counts and Sums. If such fields are active, they will cause performance degradation.
Performance troubleshooting is an iterative process. You need to consider performance implications during design and development. Note any changes to potentially troublesome areas, such as MVGs, business component sort and search specifications, joins, extension tables, or indexes. You then test the application to determine bottlenecks, using realistic data volumes and distribution in your test environment. Focus your testing efforts on the slowest, most important, and most highly configured views.
If a performance problem is detected in testing or production, then your next step is to analyze the SQL statements being generated by Siebel Business Applications. This is one of the most useful diagnostic tools available to you for performance analysis.
This topic contains the following information:
"About Specifying SQL Logging and SQL Tagging for Siebel Application Object Manager Components"
"Troubleshooting Poor Performing SQL at the Database Level Using Workload Tagging"
This topic is part of "Analyzing Generated SQL for Performance Issues".
SQL logging and SQL tagging are diagnostic tools that log and tag SQL statements generated and executed by Siebel Business Applications. When used in conjunction with SQL logging, SQL tagging can help administrators trace long-running or slow-performing SQL queries back to the user or action that triggered them. You can also use these tools to review generated SQL in a development or test environment after making configuration changes in Siebel Tools.
SQL logging controls the level of SQL logging detail in a log file for an object manager-based component. To set SQL logging for a component, set the Object Manager SQL Log (alias ObjMgrSqlLog) event to an appropriate value. For example, specify the event value for a Siebel Application Object Manager component such as Call Center Object Manager (ENU).
SQL tagging controls whether or not SELECT statements are tagged for an object manager-based component. SQL tagging also controls whether or not to log additional information, such as the name of a business component. SQL tagging is primarily used during the development phase. To set SQL tagging for a component, set the OM SQL Tagging (alias ObjMgrSqlTag) event to an appropriate value. By default, SQL tagging is disabled.
|
Caution: SQL tagging changes the format and content of the SQL SELECT statement by adding a bind, which inhibits the use of Oracle stored outlines, if they exist. |
With SQL tagging, data that can be logged includes the server component name, server name, task ID, user ID, flow ID (with Siebel ARM ID), business object name, business component name, and view name. Which elements are logged depends on the level set for the event.
For instructions on how to use SQL tagging and logging to log and tag generated SQL statements at the server component level, see Siebel System Monitoring and Diagnostics Guide.
This topic is part of "Analyzing Generated SQL for Performance Issues".Siebel workload tagging is a diagnostic tool that tags SQL statements generated and executed by Siebel Business Applications running on Oracle Database. This tool helps database administrators trace and troubleshoot poor performing SQL or excessive workload at the database level.
|
Note: Siebel workload tagging is available only for Siebel applications running on Oracle Database. |
When workload tagging is enabled, specified Siebel Application Object Manager-generated SQL statements (SELECT, INSERT, UPDATE, DELETE) are tagged with workload tagging attributes. The values for these attributes include the following:
CLIENT_IDENTIFIER: component_name,servername,taskID,userID,FlowID:SarmID
ACTION: View Name
MODULE: Business Component Name
|
Note: The length of the previous attribute values is limited to 64 bytes for CLIENT_IDENTIFIER, 32 bytes for ACTION, and 48 bytes for MODULE. Truncation occurs when the length exceeds these limitations. |
When poor performing SQL statements are suspected, the database administrator can use this tagging information to trace details about the generated SQL and the user that initiated it. Database administrators can then use Oracle Enterprise Manager to find the component task and log detail for more in-depth analysis of the performance issue. Alternatively, you can use SQL*Plus or similar tools to query the Oracle Database V$SESSION view to look up the CLIENT_IDENTIFIER, ACTION, and MODULE attributes by using SQL_ID of the SQL statement.
This topic contains the following information:
"Enabling and Disabling Workload Tagging Using the Siebel Application"
"Enabling and Disabling Workload Tagging Using the Siebel Server Manager"
"Using Workload Tagging to Troubleshoot Poor Performing SQL at the Database Level"
By default, workload tagging is disabled. You choose which SQL statements you want enabled for workload tagging by setting the log level of the OCI SQL Tagging event type for the applicable Siebel Application Object Manager server component. The log levels are listed in Table 12-1.
Table 12-1 Log Levels for Enabling and Disabling Siebel Workload Tagging
| Log Level | Description |
|---|---|
|
0 |
Workload tagging is disabled. |
|
1 |
Workload tagging is disabled. This is the default setting. |
|
2 |
Workload tagging is enabled only for |
|
3 |
Workload tagging is enabled only for |
|
4 |
Workload tagging is enabled for |
|
Note: The OCI SQL Tagging event type is available to all Object Manager-based components for supported languages, such as Call Center Object Manager (ENU), Sales Object Manager (DEU), eService Object Manager (FRA), and so on. |
You can use either of the following methods to enable and disable workload tagging:
Before enabling (or disabling) workload tagging, make sure that the following requirements are met:
Siebel Server is up and running.
Oracle Enterprise Manager is configured for the database server. For information about Oracle Enterprise Manager, see the documentation on Oracle Technology Network.
Use the following procedure to set the log level of the OCI SQL Tagging event type for the applicable Siebel Application Object Manager server component using the Siebel application GUI.
To enable and disable workload tagging using the Siebel application
Navigate to the Administration - Server Configuration screen, then the Components view.
Select the appropriate Siebel Application Object Manager for which you want to enable workload tagging. For example, if the application that you are using is Siebel Call Center for U.S. English, then select Call Center Object Manager (ENU).
Click the Events subview, and then select the OCI SQL Tagging event type.
Set the Log Level as described in Table 12-1.
After workload tagging is enabled, database administrators can use Oracle Enterprise Manager to diagnose and troubleshoot the problematic generated SQL.
Use the Siebel Server Manager (srvrmgr program) to set the OCI SQL Tagging event type for the applicable Siebel Application Object Manager server component by way of the command-line interface. For more information about Siebel Server Manager, see Siebel System Administration Guide.
To enable and disable workload tagging using the Siebel Server Manager
Make sure that the Siebel Application Object Manager server component for your Siebel application is running.
Start the srvrmgr program.
For information about starting the srvrmgr program, see Siebel System Administration Guide.
To enable workload tagging, run the following command:
change evtloglvl OCISqlTag = loglevel for comp appobjmgr_lang
where:
loglevel determines the types of SQL statements that are tagged (see Table 12-1).
appobjmgr is the Siebel Application Object Manager server component for your application, and lang is the three-letter identifier for the language specific to your environment.
For example, the following command enables workload tagging only for SELECT statements for Siebel Call Center for U.S. English:
change evtloglvl OCISqlTag = 2 for comp sccobjmgr_enu
To disable workload tagging, run the following command:
change evtloglvl OCISqlTag = 0 for comp appobjmgr_lang
In this command, appobjmgr is the Siebel Application Object Manager server component for your application, and lang is the three-letter identifier for the language specific to your environment.
After workload tagging is enabled, database administrators can then use Oracle Enterprise Manager to diagnose and troubleshoot problematic generated SQL. For information about how to use Oracle Enterprise Manager for workload tagging, see "Using Workload Tagging to Troubleshoot Poor Performing SQL at the Database Level".
Use the following procedure to diagnose and troubleshoot poor performing SQL at the database level using Oracle Enterprise Manager. For more information about Oracle Enterprise Manager, see the documentation on Oracle Technology Network.
To use workload tagging to troubleshoot poor performing SQL at the database level
Make sure that workload tagging is enabled.
Log in to Oracle Enterprise Manager.
Navigate to the Database Control Top Activity page.
From the Top Sessions section, select the Top Sessions view, and then drill down on the Session ID that you want to troubleshoot.
Click the General tab.
In the Client section, note the values in the Current Client ID field.
The format for this field is:
component_name,servername,taskID,userID,FlowID:SarmID
where:
component_name is the server component alias, for example SCCObjMgr_enu.
servername is the name of the Siebel Server from which the SQL originated.
taskID is the task ID of the user who generated the query.
userID is the login name of the user who generated the query.FlowID is the flow ID of the task.
SarmID is the SARM ID of the task.
For example:
SCCObjMgr_enu,server1,10485770,SADMIN,000008814d7f1fe8:163
This topic is part of "Analyzing Generated SQL for Performance Issues".
Optionally, after making configuration changes in Siebel Tools, you can spool the SQL that is generated by the Siebel application during runtime. You do this to troubleshoot configuration-related performance issues.
To spool the generated SQL into a trace file, start the Siebel application in the Siebel Developer Web Client (connecting to the Siebel database) using the command-line option /s sql_trace_file. For more information about installing and running the Siebel Developer Web Client, see the Siebel Installation Guide for the operating system you are using.
The SQL trace file contains all of the unique SQL statements generated during the current session, and identifies the amount of time spent processing each one. The trace file can be opened in a text editor for examination after the session has ended. The SQL trace file, which is simply a text file holding the spooled SQL from the session, is overwritten during every new session.
You can specify the /s sql_trace_file option by modifying properties for the Start menu item or desktop shortcut from which the Siebel application is invoked. The following example shows a command line for spooling generated SQL from Siebel Call Center using the Siebel Developer Web Client:
"D:\Siebel\15.0\Client_1\bin\siebel.exe /c D:\Siebel\15.0\Client_1\bin\enu\uagent.cfg /s siebel_sql.txt"
If you do not specify a path, then the SQL trace file is created in the Siebel client root bin directory, such as "D:\Siebel\15.0\Client_1\bin".
You can programmatically start and stop SQL spooling though the Siebel Object Interfaces by using the TraceOn and TraceOff methods on the Application object. For more information about these methods, see Siebel Object Interfaces Reference.
This topic is part of "Analyzing Generated SQL for Performance Issues".
As described, you can generate SQL trace files related to your configuration changes, such as for a particular view you have configured. Analyze the contents of the SQL trace file to identify any possible performance issues.
As you look through the SQL trace file, be aware of factors such as:
The number and complexity of SQL statements.
Execution times for SQL statements. This is the SQL execution time plus the time it takes to return rows. It does not include time for client-side processing.
Selection criteria in the WHERE clauses, indicating search specifications.
Sorting criteria in the ORDER BY clauses, indicating sort specifications. (In general, it is better for a query to first filter data using WHERE clauses, in order to reduce the volume of data to be then sorted. Applying sorting criteria that match users' needs reduces the likelihood of users performing their own sort operations, which would require additional system resources.)
The use of joins.
|
Note: If the same SQL statement is executed repeatedly, the Siebel application displays the entire statement for the first query. For each subsequent iteration of the same query, only the bind variables are displayed. You can recognize a query that is repeated by the specific set of bind variables it uses. |
SQL statements are displayed for all queries, including housekeeping queries. These are queries that are necessary for system operation, such as looking up the user's login to obtain responsibilities, and determining today's alarms in the calendar. You will also see queries to the S_LST_OF_VAL table to populate picklists. Queries that populate views are also present in the SQL trace file, and are easily distinguishable based on the tables they access.
This topic is part of "Analyzing Generated SQL for Performance Issues".
If you identify a problematic query in the SQL trace file, then you can obtain more information about it by using the database query tool provided with the RDBMS, such as SQL*Plus for Oracle Database.
Copy and paste the SQL statement from the trace file into the database query tool, execute the query against the Siebel database, then generate a query plan. A query plan is a detailed reporting of various statistics about the query you executed. For an example of generating a query plan against an SQL Anywhere database, see "Example of Obtaining Query Plan".
Use query plans to check:
The use of indexes
The use of temporary tables
The use of sequential table scans
Finally, compare your results with a standard application (that is, not custom-configured) in order to identify any potentially slow queries. You can resolve many performance issues either by modifying search specifications or sort specifications, or by creating new indexes on the base table.
|
Caution: Only specially trained Oracle personnel can modify existing Siebel indexes. This restriction is enforced so that performance in other modules (such as Siebel EIM) is not adversely affected by any index modifications that you make to improve query performance through the user interface. For more information, see "Managing Database Indexes in Sorting and Searching". |
Consider any potential performance implications before modifying search specification and sort specification properties for a business component. By spooling out the SQL into trace files, you can analyze which indexes are likely to be used when your application queries the business component through each applet.
Run your query plans against datasets that are comparable to the production dataset. For example, you will not obtain useful results analyzing the performance of a query against a 30-record test dataset when the production database has 200,000 records.
You might find it useful to prioritize the views to examine, as follows:
First priority. Views that are known to have the biggest performance bottlenecks.
Second priority. Views that are accessed most frequently.
Third priority. Views that are the most highly configured (as compared to the standard Siebel application).
Comparison with the standard Siebel application provides you with a benchmark for evaluation. It is often very useful to obtain a trace file from the standard Siebel application, following a preselected route through the views. Then you obtain a separate trace file from the custom-configured application, following the same route as closely as possible. The two trace files are compared, noting differences in the bullet items listed previously.
Bind variables are the values that determine which records are brought back. The RDBMS substitutes the value of a bind variable into an SQL statement when the same SQL statement is being reused, generally in place of each occurrence of a question mark or series of question marks. For example, a business object bind variable is used in an S_APP_QUERY statement because the purpose of this statement is to open the business object.
Watch for the following indications of potential problems:
Unnecessary fields are being accessed, especially ones not exposed in the user interface and not needed for calculated fields, nor used for passing values to detail records.
Unnecessary joins are occurring, particularly to tables that are not being accessed.
Unnecessary multiple joins are being made to the same table. This can indicate duplicate join or Multi Value Link (MVL) object definitions, or joins using the same foreign key.
Multiple short queries similar to the following:
...FROM
SIEBEL.S_ADDR_PER T1
When a short query appears many times, this generally indicates that an MVG without a primary join is being accessed by a list applet. The system is running a secondary query for each master record to obtain its detail records. The secondary queries are the short queries appearing in the log file. This is usually your best diagnostic indicator of the need for a primary join.
When a short query appears only once, it indicates the same situation, but accessed in a form applet. In either case, the cure is a primary join, as explained in "Using Primary ID Fields to Improve Performance".
This topic is part of "Analyzing Generated SQL for Performance Issues".
The following procedure shows an example of obtaining a query plan when running against a local SQL Anywhere database using the Siebel Mobile Web Client. It is assumed that customers will obtain query plans using the RDBMS for their Siebel database, such as Oracle Database, IBM DB2, or Microsoft SQL Server.
|
Note: For Siebel Innovation Pack 2015, the local database for the Siebel Mobile Web Client uses SAP SQL Anywhere. SAP SQL Anywhere is not available for new deployments after September 2015. For more detailed information on how this change affects Siebel Tools and Siebel Remote, see Siebel Release Notes on My Oracle Support for Innovation Pack 2015 (Doc ID 1996273.1). |
To obtain a query plan for an SQL statement in your trace file
Execute the Interactive SQL (dbisqlc.exe) program, located in the Siebel client installation directory (Siebel Mobile).
In order to analyze an SQL statement from the SQL trace file, copy the SQL statement and paste it into the Interactive SQL program's Command pane.
Replace bind variable references with the corresponding bind variable values.
Click the Execute button.
The query runs against the local SQL Anywhere database. The Statistics pane provides analysis information.
This topic is part of "Analyzing Generated SQL for Performance Issues".
The database that underlies Siebel Business Applications can be queried to obtain information on a read-only basis.
|
Caution: Update queries must never be directly performed on the Siebel database. All data manipulation and restructuring must be performed through Siebel Tools or through the Siebel application. |
This topic provides guidelines for Siebel scripting using Siebel eScript or Siebel VB, or for using declarative alternatives in place of scripts. It contains the following information:
This topic is part of "Guidelines for Siebel Scripting".
Often, customers use scripts for data validation, responses to data changes, or other purposes that might best be addressed through declarative means: by defining properties or specifying business service method invocation using Siebel Tools.
Scripting is often unnecessary and must be minimized or avoided because it can introduce performance problems, add risk and complexity, require greater maintenance, and duplicate functionality already available in Siebel Business Applications.
For example, the Validation field property, which allows for common VB expressions and comparison operators, can be used to perform field validation or string manipulation of data entered through the user interface or through Siebel Object Interfaces.
Expressions for the Validation property can include methods such as LoginId(), LoginName(), LookupValue() ParentFieldValue(), PositionId(), PositionName(), Today(), and so on.
The Force Case field property can also be useful in a data-validation context, such as to ensure that personal names entered have initial capital letters.
For more information on supported expressions and operators, see Siebel Developer's Reference.
Setting the Auto Primary property on MVL object definitions can also help you achieve results that you might otherwise use scripting for. For example, if your business requirement is to assign the first record in an MVG as the primary record (for example, primary address or primary owner), then set Auto Primary to the value Default. For more information about using Primary ID fields, see "Using Primary ID Fields to Improve Performance" and see Configuring Siebel Business Applications.
Scripting can be used in combination with declarative methods, such as to present customized error messages that guide users to enter data appropriately for each field subject to validation rules.
Functionality such as custom responses to data changes, which can often be handled through scripting, might best be addressed through declarative means. Such mechanisms, many of which can be used in combination, include:
User properties on applets, business components, fields, controls, list columns, and other object definitions (for example: Required, Pre-Default, Post Default, Search Spec, Type Field, or Type Value)
Siebel Workflow
State model
Siebel Personalization
Run-time events
Named methods
Business services
Visibility configuration
For more scripting guidelines, see Configuring Siebel Business Applications.
This topic is part of "Guidelines for Siebel Scripting". It provides guidelines for appropriate use of Siebel scripting using Siebel eScript or Siebel VB. For more information about these and other guidelines, see:
Siebel eScript Language Reference
Siebel VB Language Reference
Siebel Object Interfaces Reference
Configuring Siebel Business Applications
Configuring Siebel Open UI
The following are some guidelines for appropriate use of Siebel scripting:
Use declarative alternatives. Try all other possibilities before using scripting to accomplish a functional requirement. See also "Using Declarative Alternatives to Siebel Scripting".
Use browser scripts for simple client-side functions such as field validation. Browser scripts are best used to perform simple procedural logic on the client side, such as performing field validation, or displaying blocking messages or alerts to users. Some such uses, particularly field validation, can reduce server round trips. Using more complex browser scripts, however, might reduce performance.
For example, using Set/Get Profile attribute calls, or invoking multiple business service methods, can require more server round trips and lead to performance problems. Adding extra functionality to scripts that display messages can have a similar effect.
|
Note: Setting the Immediate Post Changes field property has a similar effect on server round trips. Use this property only for constrained picklists and calculated fields that must be updated dynamically. |
Do not return large result sets from server business services to browser scripts. Browser scripts that invoke server scripts must return simple values or a single record, and must not return large result sets.
Minimize scripting on field-level or control-level events. Field-level or control-level events are fired more often than most other types of events. Consequently, invoking scripts from such events can dramatically impact scalability. Avoid scripting frequent events, or simplify scripts on these events. Examples of such events include BusComp_PreGetFieldValue(), WebApplet_PreCanInvokeMethod(), and WebApplet_ShowControl().
Use simple scripts on applet-level and business component-level events. Scripts written on events for applets or business components (for example, for Change Record events) must be very simple, because such events are fired often. Complex or I/O-intensive operations in such events will adversely affect performance.
Caching data in Siebel eScript scripts. Executing the same SQL statements from various locations in a Siebel eScript script can generate an excessive number of script API calls and a redundant number of business component queries. In order to reduce the performance impact (assuming that data does not change between invocations), you can cache a limited set of data within your scripts. (In some cases, you might not want to cache data at the script level, such as if the data that needs to be cached is too complex or too large.)
Declare your variables. Declaring your variables and specifying their data type, as appropriate, can use less memory and improve performance.
Destroy any created objects when you no longer need them (Siebel eScript). Theoretically, the Siebel eScript interpreter takes care of object cleanup. However, complex code involving many layers of object instantiation can in some cases cause the interpreter not to release objects in a timely manner. Destroying or releasing objects helps to minimize the impact on resources such as server memory.
Explicit destruction of Siebel objects must occur in the procedure in which they are created. To destroy an object in Siebel eScript, set it to NULL, or set the variable that contains it to another value. Destroy objects in reverse order of creation; that is, destroy child objects before you destroy parent objects.
Verify that your script is defined on the appropriate method. A script that is not defined on the right method might have a performance impact. For example, if special code needs to be run at the record level when an insert or update is done, then it is better to invoke a script from BusComp_WriteRecord() rather than BusComp_SetFieldValue(). The reason for this is that SetFieldValue events are fired much more often than WriteRecord events. Limit your use of specialized invocation methods.
Verify that your script is implemented in the right view. A script that is not implemented in the right view might cause significant performance impact. Verify that this script is implemented in the right place in the configuration, based on data manipulations, navigation requirements, and business requirements in general.
Avoid redundant repository object settings. Do not perform unnecessary object validation. Each method invocation that you perform has a performance cost. Details on this issue regarding field activation, for example, are provided below.
Use the ActivateField() method sparingly (Siebel eScript). Do not activate a field if you will not use it. Use the ActivateField() method sparingly. Using this method increases the number of columns retrieved by a query, and can lead to multiple subqueries involving joins. These operations can use a significant amount of memory, and can degrade application performance.
Do not perform any unnecessary field activation (for fields that are already active). Each method invocation that you perform has a performance cost.
Do not activate system fields, because they are already activated by default. Such fields include Created, Created By, Updated, and so on.
Do not activate any other fields that are already active. Check the Force Active field property in Siebel Tools to see whether you need to activate it.
Use the ExecuteQuery() method sparingly (Siebel eScript). Removing calls to execute a business component, using the method ExecuteQuery(), can yield significant performance benefit. It is better practice to use shared variables to share values of specific business component records across scripts than to separately invoke ExecuteQuery() in each script.
Use the SetSearchSpec() method rather than NextRecord() method (Siebel eScript). You can improve performance by using the SetSearchSpec() method to get a specific record, rather than using the NextRecord() method to go through a list of retrieved methods until a specific record is found.
Use ForwardOnly cursor mode (Siebel eScript). Use the ForwardOnly cursor mode for ExecuteQuery() unless ForwardBackward is required. Using ForwardBackward uses a significant amount of memory, which can degrade application performance.
Use appropriate error handling. Appropriate error handling can help maintain optimal performance. Although error handling is important, it also has a performance cost. For additional guidelines for using error handling in scripts, see 477766.1 (Article ID) on My Oracle Support. This document was previously published as Siebel Technical Note 514.
Avoid nested query loops. Nested query loops can involve a large number of subqueries and can significantly impact performance. Use this technique very sparingly. Implement a nested query loop in the correct order in order to minimize the number of iterations. Be aware that a nested query loop can be invoked implicitly, depending on how your script is written.
Use the this object reference (Siebel eScript). The special object reference this is eScript shorthand for "this (the current) object." Use it in place of references to active business objects and components.
For example, in a business component event handler, use this in place of ActiveBusComp(), usage of which can have a significant performance impact. Refer to the following example:
function BusComp_PreQuery()
{
this.ActivateField("Account");
this.ActivateField("Account Location");
this.ClearToQuery();
this.SetSortSpec( "Account(DESCENDING)," +
t" Account Location(DESCENDING)");
this.ExecuteQuery();
return (ContinueOperation);
}
Use the Switch construct (Siebel eScript). The Switch construct directs the program to choose among any number of alternatives that you require, based on the value of a single variable. Using this construct offers better performance than using a series of nested If statements, and is easier to maintain.
Use the Select Case construct (Siebel VB). The Select Case construct directs the program to choose among any number of alternatives that you require, based on the value of a single variable. Using this construct offers better performance than using a series of nested If statements, and provides other benefits.
Test your custom scripts. Make sure that your scripts are fully tested and optimized, and are no more complex than required to meet your business needs.
This topic describes guidelines for configuring selected elements in the data objects layer for optimal performance. It contains the following information:
This topic is part of "Guidelines for Data Objects Layer".
Multilingual List of Values (MLOV) fields are implemented below the business component level. Fields that point to MLOVs with enabled target columns return display values that match the current language setting for the session.
For display, the underlying language-independent code is converted to its corresponding display value using a Siebel application lookup. For searching and sorting, however, a database join to the list of values table (S_LST_OF_VAL) is performed. Make sure that any configuration directly involving the S_LST_OF_VAL table is compatible with your Siebel application MLOV functionality.
When a view with MLOVs is displayed for the first time, a separate query on the S_LST_OF_VAL table is made for each field that has an MLOV. The query obtains all of the display values for that MLOV and writes the values to the LOV cache in memory. When the view is subsequently displayed during the same session, the values are obtained from the cache rather than by issuing another query.
|
Note: Displaying multiple records in a list applet that contains one or more MLOV fields will cause memory consumption to increase, and can produce poor performance. The problem manifests particularly when multiple fetches are performed against a given logical result set; that is, you scroll through records. It can also manifest when client-side export is performed to automate this behavior, or anytime the NextRecord method is invoked repeatedly on the business component. It is generally recommended to use MLOV fields sparingly in list applets, or to disable client-side export from list applets containing MLOVs. |
For more information about configuring MLOVs, see Configuring Siebel Business Applications and Siebel Global Deployment Guide.
This topic is part of "Guidelines for Data Objects Layer".
A database index is a data structure in the RDBMS that is associated with a table. It provides references to all records in the table for quick lookup and filtering, and is sorted in a particular order for sorting in that order quickly. The Siebel database uses an index to efficiently retrieve and sort the result set of a query.
Indexes provided in the Siebel Data Model are tuned for optimal performance of standard Siebel applications. When you add new business components with custom sorting or filtering requirements, you need to make sure that a database index is present that supports the requirement and delivers the result set efficiently. You might need to add new indexes.
You add indexes using the Index and Index Column object types. The index is added in the database as a result of its being created in Siebel Tools and database extensions being applied.
|
Note: The addition of custom indexes does not always improve performance and can reduce performance in some cases. The incremental value of an index depends in large part on the heterogeneity and distribution of the data. |
When data is heterogeneous, all or most of the values are unique (such as with row ID values, which are unique). The less heterogeneous the data (that is, the more homogeneity or repeated instances of values), the less benefit the index offers relative to its costs.
For Boolean fields, indexes generally offer little value. Some performance benefit might be found when querying for the least commonly represented values. Little or no benefit is found when querying on more commonly represented values or values that are evenly distributed. Similar guidelines apply for other homogeneous data, such as fields that are constrained to a list of values.
Indexing generally improves performance of SELECT operations. However, it can significantly reduce performance for batch UPDATE and INSERT operations, such as are performed by Siebel EIM.
Discuss any custom index requirements with Oracle Advanced Customer Services. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.
The Sort Specification property for a business component, picklist, or predefined query orders the records retrieved in a query, and serves as the basis for the ORDER BY clause in the resulting SQL issued. An index needs to be present that supports the order specified in the sort specification. Otherwise, the RDBMS engine physically sorts the entire result set in a temporary table.
The index needs to include the base columns for all of the fields, and to use them in the same order. There can be more columns specified in the index than are used in the sort specification, but the reverse is not true.
For example, the sort specification Last Name, First Name in the Contact business component is supported by at least one index on the S_CONTACT base table. One of these indexes is called S_CONTACT_U1, and it contains the LAST_NAME, FST_NAME, MID_NAME, PR_DEPT_OU_ID, OWNER_PER_ID, and CONFLICT_ID columns, in that order. If you want a sort specification that orders contacts in first-name order, then you would need to create a custom index.
Do not sort on joined columns, because indexes cannot be used.
The Search Specification property for a business component, applet, link, or picklist selectively retrieves rows from the underlying table that meet the criterion specified in the property. The search specification is the basis for the WHERE clause in the resulting SQL issued. An index needs to be present that supports the criterion. Otherwise, the RDBMS might scan through all rows in the table rather than only those to be returned by the query.
The index needs to contain all of the columns referenced by fields in the search specification.
In Sales Rep views such as My Accounts or where organization access control is implemented, if the user queries or sorts columns that are denormalized to the intersection table (for example, NAME and LOC in S_ORG_EXT), then performance is likely to be good. The Siebel application uses the intersection to determine visibility to records in the base table, and indexes can be used on the intersection table to improve performance.
For related information, see "Reusing Standard Columns".
|
Note: If a query or sort includes columns that are not denormalized to the intersection table, then performance is likely to degrade, because indexes are not used. |
This topic is part of "Guidelines for Data Objects Layer".
The architecture and data model of your application has been tuned for best performance. This optimization is achieved by using proper indexes, data caching, and efficient SQL generation, and also by denormalizing columns on certain tables. These denormalized columns are indexed so that the application can improve the performance of complex SQL statements by using these columns for search or sort operations instead of the columns of the original tables.
|
Note: Do not remap existing fields, especially those based on User Key columns, to other columns in the same table. |
|
Caution: Do not use custom denormalized columns without the assistance of Oracle Advanced Customer Services. Denormalized columns can improve performance by allowing indexes to be placed directly on an intersection table, rather than on its master or detail table. However, if this is configured improperly, then the data in the denormalized column can become out of sync with its source. This can result in several problems ranging from inconsistent sorting to corrupt data. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services. |
The columns NAME and LOC of the S_ORG_EXT table are denormalized into ACCNT_NAME and ACCNT_LOC in the S_ACCNT_POSTN table.
When sorting accounts by name and location in views where the Visibility Applet Type property is set to Sales Rep, the Siebel application uses the denormalized columns ACCNT_NAME and ACCNT_LOC of the S_ACCNT_POSTN table. Doing so allows the use of an index.
If the account name and location were stored in extension columns (for example, X_NAME and X_LOC), then these columns would have to be used for sorting instead of NAME and LOC. Even if these extension columns were indexed, the application could not use an existing index to create the necessary joins and sort the data, because the index is on S_ORG_EXT and not on S_ACCNT_POSTN. Therefore, the result would be a significant decrease in performance.
The first SQL statement is generated by the standard My Accounts view. The query plan shows that the database uses numerous indexes to execute the statement.
SELECT
T1.LAST_UPD_BY,
T1.ROW_ID,
T1.CONFLICT_ID,
.
.
.
T10.PR_EMP_ID,
T2.DUNS_NUM,
T2.HIST_SLS_EXCH_DT,
T2.ASGN_USR_EXCLD_FLG,
T2.PTNTL_SLS_CURCY_CD,
T2.PAR_OU_ID
FROM
SIEBEL.S_PARTY T1
INNER JOIN SIEBEL.S_ORG_EXT T2 ON T1.ROW_ID = T2.PAR_ROW_ID
INNER JOIN SIEBEL.S_ACCNT_POSTN T3 ON (T3.POSITION_ID = ?, 0.05)
AND T2.ROW_ID = T3.OU_EXT_ID
INNER JOIN SIEBEL.S_PARTY T4 ON (T4.ROW_ID = T3.POSITION_ID, 0.05)
LEFT OUTER JOIN SIEBEL.S_PRI_LST T5 ON T2.CURR_PRI_LST_ID = T5.ROW_ID
LEFT OUTER JOIN SIEBEL.S_INVLOC T6 ON T2.PR_FULFL_INVLOC_ID =
T6.ROW_ID
LEFT OUTER JOIN SIEBEL.S_ORG_EXT T7 ON T2.PAR_OU_ID = T7.PAR_ROW_ID
LEFT OUTER JOIN SIEBEL.S_ORG_EXT_SS T8 ON T1.ROW_ID = T8.PAR_ROW_ID
LEFT OUTER JOIN SIEBEL.S_INT_INSTANCE T9 ON T8.OWN_INST_ID =
T9.ROW_ID
LEFT OUTER JOIN SIEBEL.S_POSTN T10 ON T2.PR_POSTN_ID = T10.PAR_ROW_ID
LEFT OUTER JOIN SIEBEL.S_USER T11 ON T10.PR_EMP_ID = T11.PAR_ROW_ID
LEFT OUTER JOIN SIEBEL.S_ADDR_ORG T12 ON T2.PR_ADDR_ID = T12.ROW_ID
LEFT OUTER JOIN SIEBEL.S_INDUST T13 ON T2.PR_INDUST_ID = T13.ROW_ID
LEFT OUTER JOIN SIEBEL.S_ASGN_GRP T14 ON T2.PR_TERR_ID = T14.ROW_ID
LEFT OUTER JOIN SIEBEL.S_POSTN T15 ON T3.POSITION_ID = T15.PAR_ROW_ID
LEFT OUTER JOIN SIEBEL.S_USER T16 ON T15.PR_EMP_ID = T16.PAR_ROW_ID
LEFT OUTER JOIN SIEBEL.S_ORG_SYN T17 ON T2.PR_SYN_ID = T17.ROW_ID
LEFT OUTER JOIN SIEBEL.S_ORG_BU T18 ON T2.BU_ID = T18.BU_ID AND
T2.ROW_ID = T18.ORG_ID
LEFT OUTER JOIN SIEBEL.S_PARTY T19 ON T18.BU_ID = T19.ROW_ID
LEFT OUTER JOIN SIEBEL.S_ORG_EXT T20 ON T18.BU_ID = T20.PAR_ROW_ID
WHERE
((T2.INT_ORG_FLG != 'Y' OR T2.PRTNR_FLG != 'N') AND (T3.ACCNT_NAME >= ?))
ORDER BY
T3.POSITION_ID, T3.ACCNT_NAME
Query plan : T3(S_ACCNT_POSTN_M1),T2(S_ORG_EXT_P1),T1(S_PARTY_P1),T15(S_POSTN_U2),T10(S_POSTN_U2),T4(S_PARTY_P1),T12(S_ADDR_ORD_P1),T13(S_INDUST_P1),T7(S_ORG_EXT_U3),T16(S_USER_U2),T11(S_USER_U2),T17(S_ORG_SYN_P1),T6(S_INVLOC_P1),T5(S_PRI_LST_P1),T14(S_ASGN_GRP_P1),T18(S_ORG_BU_U1),T19(S_PARTY_P1),T20(S_ORG_EXT_U3),T8(S_ORG_EXT_SS_U1),T9(se)
The second SQL statement generated in My Accounts, below, has a different ORDER BY clause. Even though the columns NAME and LOC of S_ORG_EXT are indexed, the database cannot use this index. Performance decreases from the use of a temporary table. The same behavior occurs if the ORDER BY clause uses the columns X_NAME and X_LOC instead of NAME and LOC.
The following example shows a different ORDER BY clause than the previous example query plan.
WHERE ((T2.INT_ORG_FLG != 'Y' OR T2.PRTNR_FLG != 'N') AND) T3.ACCNT_NAME >= ?)) ORDER BY T3.ACCNT_NAME, T3.POSITION_ID Query plan : TEMPORARY TABLE T3(S_ACCNT_POSTN_M1),T2(S_ORG_EXT_P1),T1(S_PARTY_P1),T15(S_POSTN_U2),T10(S_POSTN_U2),T4(S_PARTY_P1),T12(S_ADDR_ORG_P1),T13(S_INDUST_P1),T7(S_ORG_EXT_U3),T16(S_USER_U2),T11(S_USER_U2),T17(S_ORG_SYN_P1),T6(S_INVLOC_P1),T5(S_PRI_LST_P1),T14(S_ASGN_GRP_P1),T18(S_ORG_BU_U1),T19(S_PARTY_P1),T20(S_ORG_EXT_U3),T8(S_ORG_EXT_SS_U1),T9(se)
This topic is part of "Guidelines for Data Objects Layer".
Adding extension columns to base tables can also affect performance, depending on the data type and length, the joins and queries used, the number of columns, and other considerations. For example, it is recommended not to add more than three columns of the data type CLOB to a base table. See also "Reusing Standard Columns".
This topic is part of "Guidelines for Data Objects Layer".
Case-sensitive queries perform better than case-insensitive queries, where queries include wildcards. However, you can support case-insensitive queries and reduce the performance impact through appropriate configuration. Siebel Business Applications are case-sensitive by default. You can enable case insensitivity for specified columns. End users can force case-sensitive or case-insensitive queries.
You can use the Case Insensitivity Wizard to configure Siebel database columns to support case-insensitive queries. For best performance, it is recommended to accept the recommendations of this wizard. For each specified column, the wizard creates a case-insensitive column populated with upper-case characters and creates a case-insensitive index. Before you run the wizard, verify that the columns that are to support case-insensitive queries are already indexed, to improve performance for case-insensitive queries (by avoiding table scans).The Case Insensitivity Wizard formats the search criteria for the applicable columns into upper case and appends a wildcard to the search string. The wildcard is used to match data in the specialized column populated with upper-case characters.
A trailing wildcard causes performance issues with Oracle Database and IBM DB2. However, you can resolve this problem by setting the user property Use Literals For Like. Instead of the host variable, a literal string like 'SMITH%' is sent to the database server, which determines that the wildcard is in the last position and uses the appropriate index.If you enable case insensitivity for a user key column that is denormalized to related visibility tables, then also enable case insensitivity for the denormalized column. For example, if you enable case-insensitivity for Account.Name, then also enable it for the S_ACCNT_POSTN and S_ORG_BU denormalized columns for Account.Name. After you enable case insensitivity for user key fields like Last Name, the Contacts View is slower. For more information, see 536211.1 (Article ID) on My Oracle Support.For more information about configuring case insensitivity and about different ways of using the Case Insensitivity Wizard, see Configuring Siebel Business Applications, Siebel Database Upgrade Guide, and Siebel Global Deployment Guide. For more information about performing case-insensitive queries, see Siebel Fundamentals for Siebel Open UI and Siebel Applications Administration Guide.Before you configure case insensitivity, a thorough review of business requirements and performance criteria is highly recommended. In addition, if the feature is enabled, then conduct a performance test with a full copy of the production database. It is also recommended that Oracle Advanced Customer Services be engaged to optimize the configuration and review requirements. Contact your Oracle sales representative to request assistance from Oracle Advanced Customer Services.
Related Books
Configuring Siebel Business Applications
Siebel Database Upgrade GuideSiebel Global Deployment GuideSiebel Fundamentals for Siebel Open UI
Siebel Applications Administration Guide
This topic describes guidelines for configuring selected elements in the business objects layer for optimal performance. It contains the following information:
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 toTRUE 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".
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.
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". |
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.
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.
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.
This topic describes guidelines for configuring selected elements in the user interface objects layer for optimal performance. It contains the following information:
This topic is part of "Guidelines for User Interface Objects Layer".
The grid layout feature allows developers to create effective and usable form applets for Siebel views. However, performance can be adversely affected by certain applet design choices.
Typically, such performance problems relate to the alignment of user interface controls such as labels and fields, and stem from the total number of cells in the grid-based form applet, including spacer cells. Performance impact will depend on the number of user interface elements, the applet size, and other factors.
You can optimize user interface performance by:
Making stacked sets of labels or fields the same width. Doing so can reduce the number of adjacent spacer cells that you require.
Aligning stacked sets of labels consistently.
Making labels the same height as the adjacent fields.
Eliminating horizontal or vertical spacer cells that you deem unnecessary.
|
Note: Weigh all optional measures against possible usability concerns. Judicious use of spacing in your view layouts is generally appropriate for optimal usability. |
For more information about using the grid layout, see Configuring Siebel Business Applications.
This topic is part of "Guidelines for User Interface Objects Layer".
Applet toggles are a useful feature where multiple applets based on different business components occupy the same location in a view. Which applet displays at one time depends on a field value in a parent applet (dynamic toggle) or on a user selection (static toggle).
Dynamic toggle applets are based on the same business component, while static toggle applets can be based on different business components.
In general, when configuring applet toggles for your Siebel application, particularly dynamic toggles, you can reduce memory and CPU usage for user application sessions by minimizing the number of applet toggles and fields per applet.
It is important to be aware of potential performance impact of using applet toggles, particularly dynamic toggles:
When a user selects a record in a parent applet for a dynamic applet toggle, the business component and fields for all of the applet toggles are instantiated and cached in memory, and all of these fields are queried.
This query is used to populate other applet toggles that might be displayed when the user changes the relevant field value in the parent record. However, each time the user selects a different record in the parent applet, all of the fields in the toggle business component are required.
Also note that view layout caching is not performed for views containing dynamic applet toggles.
When a user navigates to a view containing a static applet toggle, the business component and fields for the default displayed applet is instantiated and cached in memory, and these fields are queried. Other business components are instantiated and cached, and other queries performed, when the user navigates to the other applets in the toggle.
In each case, cached objects remain in memory until the user navigates to a different screen.
