Scribd
Upload
27 views2 pages

Best Practices for Siebel Server Scripts

This document provides guidelines for writing server and browser scripts for a Siebel application. For server scripts, it recommends destroying objects when no longer needed, handling exceptions, avoiding nested queries and direct database access from certain events. For browser scripts, it advises against direct DOM manipulation of Siebel objects and returning large result sets from the server.

Uploaded by

venkat576
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
27 views2 pages

Best Practices for Siebel Server Scripts

This document provides guidelines for writing server and browser scripts for a Siebel application. For server scripts, it recommends destroying objects when no longer needed, handling exceptions, avoiding nested queries and direct database access from certain events. For browser scripts, it advises against direct DOM manipulation of Siebel objects and returning large result sets from the server.

Uploaded by

venkat576
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd

Server Script

 Destroy the objects when they are no longer needed.


 Destroy objects in the opposite order of creation for business objects and components
 Use the ForwardOnly cursor mode for ExecuteQuery(). Try to avoid ForwardBackward
mode if you can.
 Know when to explicitly activate fields.
 A common error is to activate fields after ExecuteQuery() has been invoked but before
SetFieldValue() is called.
 Do not explicitly activate system fields, which is unnecessary since they are always
active.
o Id
o Created
o Created By
o Updated
o Updated By
 Field attributes may force a field to always be active. These are the following:
o If an applet that is currently displayed is based on the instance of a business
component and the field is displayed in the applet, then it is active in that
business component instance
o If the field’s Link Specification property is set to TRUE
o If the field’s Force Active property is set to TRUE
o If the business component’s Force Active property is set to TRUE
 Use language exception handling features to write resilient code.
 Avoid nested query loops.
 Use standard Tracing functions.
 Use Standard Naming Convention
 Use the “this” object instead of TheApplication().ActiveXXX() functions
 Declare variables at the beginning of functions (for code readability)
 Put code in the most appropriate modules. For example, if it is a business rule, put the
code in the Business layer. Don’t repeat the code in multiple places.
 The following table lists the standard uses and warnings for all BC events
Event Recommended Usage
PreSetFieldValue, The Pre… events are usually used to validate changes made
SetFieldValue, by the user and cancel the operation if there is a problem.
PreNewRecord, Only write code for these events that determines if the event
NewRecord, PreAssociate, may proceed or not. Use data-driven read-only user
Associate, PreWriteRecord, properties to enforce validation whenever possible (see
WriteRecord, Appendix F of the Siebel Tools Reference, Vol 2). Use the
PreDeleteRecord, post-processing events for logic that does not determine
DeleteRecord whether or not the event should complete.

In the post-processing events (those that are not prefixed with


“Pre”), code should be limited to processing which cannot be
performed by configuration means. Investigate the use of
Runtime events and Workflow, user properties, calculated
fields, and so forth before writing script.
PreGetFieldValue Modifying field values before the value is retrieved by the
GetFieldValue business component method. Note: overuse
of this event can cause severe performance degradation—
use it sparingly.
ChangeRecord Use only for updating module variables or other short, simple
scripts. Do not put code in this event that queries/writes to
the database, contacts external systems, or interacts with the
file system. This will result in severe performance
degradation.
PreQuery, Query The PreQuery event should be used only for logic that cannot
be achieved through search specs.
PreInvokeMethod, PreInvokeMethod should be used for dealing with custom
InvokeMethod methods. In some situations, it can be used for capturing
standard Siebel methods and canceling them if necessary.
Note, however that this is what the above events are for
(PreSetFieldValue, PreWriteRecord, etc.), and code that
depends on nonstandard methods, such as those used by
specialized business components, may not upgrade.

The InvokeMethod event should be used to do any


processing that does not determine whether or not the
method invocation should continue. Avoid using
InvokeMethod to handle methods for which there is a
predefined event.

Browser Script
 Avoid direct DOM manipulation of Siebel objects
 Do not return large result sets from server business services to browser script

Common questions

Powered by AI

Overuse of the PreGetFieldValue event for modifying field values can seriously degrade performance as it introduces unnecessary processing overhead each time the GetFieldValue method is called, which can be particularly detrimental in large datasets or high-frequency operations .

Using the 'this' object rather than TheApplication().ActiveXXX() functions adheres to best practices, enhancing code readability and maintainability by explicitly referencing the current context directly within scripts, avoiding potential confusion and errors associated with global function calls .

The PreInvokeMethod event should be employed to handle custom method logic when there is a need to intercept or modify standard transactions that cannot be managed with predefined events, offering flexibility to adjust behavior while ensuring the code remains upgrade-safe .

Destroying objects in the opposite order of creation ensures that dependencies between objects are properly maintained, preventing potential errors and maintaining system integrity .

Returning large result sets to browser scripts can lead to significant performance issues, such as increased latency and memory consumption, ultimately impacting user experience due to the browser's limitations in handling large volumes of data smoothly .

Field attributes, such as the Link Specification property or the Force Active property, dictate the activation state by ensuring certain fields are always active in corresponding business component instances. This is crucial for fields used in currently displayed applets or those required for link functionalities, maintaining data integrity and accessibility .

Activating fields after calling ExecuteQuery() but before SetFieldValue() can lead to inefficiencies and runtime errors because it may cause unnecessary data retrievals or disrupt the intended execution order, potentially impacting performance and correctness of data handling .

The ForwardOnly cursor mode should be used when a simple, linear traversal over a result set is sufficient and performance is a concern. It avoids the overhead of supporting random access and backward traversal, thus improving query execution efficiency .

Data-driven read-only user properties provide a configuration-based approach to enforce field validation without additional scripting overhead, simplifying maintenance and improving performance by leveraging native configuration settings rather than custom code .

Developers should use the PreWriteRecord event only for validation purposes to determine if the user-initiated operation can proceed. Misuse for post-validation logic can lead to unnecessary complexity and potential errors since this event is specifically intended to evaluate conditions prior to writing a record .

You might also like