Siebel CRM Performance Tuning Guide Siebel 2018 E24801-01 |
|
![]() Previous |
![]() Next |
View PDF |
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
Using Siebel Tools
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 or 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.