Siebel Performance Tuning Guide > Tuning Customer Configurations for Performance > Best Practices for Siebel Scripting >

Siebel Scripting Guidelines for Optimal Performance

This section 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

The following are some guidelines for appropriate use of Siebel scripting:

• Use declarative alternatives. Generally, you should 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, may reduce performance.

  For example, using Set/Get Profile attribute calls, or invoking multiple business service methods, may require more server round trips and lead to performance problems. Adding extra functionality to scripts that display messages may 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 should return simple values or a single record, and should 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—should 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 data does not change between invocations), you can cache a limited set of data within your scripts. (In some cases, you may 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, may 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, complex code involving many layers of object instantiation may 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 should 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. The best practice is to destroy objects in reverse order of creation—that is, destroy child objects before you destroy parent objects.

• Verify your script is defined on the appropriate method. A script that is not defined on the right method may have a performance impact. For example, if special code needs to be run at the record level when an insert or update is done, 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 your script is implemented in the right view. A script that is not implemented in the right view may 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 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 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 if 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 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. Additional guidelines for using error handling in scripts are provided in Technical Note 514, located on Siebel SupportWeb.
• Avoid nested query loops. Nested query loops may involve a large number of subqueries and may 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 may 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." You should use it in place of references to active business objects and components.

  For example, in a business component event handler, you should use this in place of ActiveBusComp(), usage of which may 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)," +
  " 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 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 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 your scripts are fully tested and optimized, and are no more complex than required to meet your business needs.