c



  


1. Always use   

 to call the application, as the declaration of a global variable to
represent the application (e.g. var theApp = TheApplication()) is not recommended by Siebel.
The use of this variable may cause memory leaks, reduce performance or other unpredictable
behavior.

2. User-defined functions must be 

    in the general declarations of each script.
This avoids compilation errors that may arise if the functions called are not in alphabetical order.
The compiler compiles all functions alphabetically and so if one function calls another that is
later in the alphabet the compiler does not recognize this second function and therefore, fails.

3. Be cautious when adding script to business components as this code applies application wide
across applets and views. If a certain piece of coding is needed at the business component level
but is restrictive to certain situations like if exposed only through some particular views then
make sure to limit the processing through an appropriate condition.

4. The use of µµ is recommended by Siebel as it enables the code to be changed faster and
more readable way to group operations performed within the same business component. The use
of µWith¶ also presents a slight performance improvement.  is generally used to process a
group of operations on a set of records (on a data record sequentially)

5. Using 
can make code maintenance easier due to readability. However overuse of
variables increases the amount of operations that have to be performed and can reduce
performance slightly.

6. Siebel does not recommend the use of µµ. µEmpty¶ is an undefined variable which is
assigned as type variant. A variant is initially set to a null string (´), which means that any scripts
currently using this term will not be affected. However, it is better practice to assign ´ rather than
µEmpty¶ to any strings you need to set back to NULL. The use of µEmpty¶ prevents Option
Explicit from checking all other variables are declared correctly.

7. The use of µ  µ prior to a query is the equivalent to the µSELECT¶ statement in
SQL. The use of µActivateField¶ in Siebel scripts code can be confusing and should be
minimized as much as possible as this has a performance impact. However there is nothing
worse than receiving a runtime exception: µ was not active«¶. When activating fields note that:

a. Siebel system fields (Id, Created, Created By, Last Updated, Last Updated By) are always
force active.

b. Fields that have Force Active = Y on the business component are always force active.

c. Fields that have Link Specification = Y on the business component are always force active.
d. Fields that are included in the definition of an applet on the active view if it is bound to a web
template item and the µShow In List¶ property of the list column or µVisible¶ property of the
control is TRUE. If the user removes the list column from the µColumns Displayed¶ in the list
applet, the field may no longer be active after the next query.

e. Fields that are used as part of a calculated field calculation when the calculated field is
retrieved for use on the active applet.

8. µ  µ should only be used prior to µ   µ to ensure that a particular field
will be activated and included in the equivalent µSELECT¶ statement of the query. Therefore
µActivateField¶ is usually never to be used with µthis¶/'Me¶ (eg. this.ActivateField(µField1ƍ)).
This is because you don¶t usually perform a query in the current context as this would change the
on screen query displayed to the user. Siebel actually specifies that the use of ActivateField with
µthis¶ can possibly cause data corruption to occur.

9. When performing a query, always use µ

 µ after the µExecuteQuery¶ to set the
cursor position unless moving back through the returned records. This is a much faster query
because it does not create a cache that stores the previous records.

10. If you have a set of 


 !"
" # statements then use !$
# statements
instead. This simplifies code and improves performance.

11. It is best practice in Siebel scripting to use the !%$% # statements in code. This
will ensure that exceptions are caught and handled appropriately and instantiated object variables
are always destructed in the finally block (which reduces the chances of memory leak) as the
code in the finally block is always executed. Note that object variables should be destroyed in the
reverse order they were instantiated. If the script exists abruptly the memory that is being used to
hold that value might not get released causing memory leak. To avoid any kind memory leak it is
a good practice to null those variables. Common object references that should be set to null are

Business Objects

Property Sets

Business Services

Business Components

Applets

12. Reduce the number of queries performed as much as possible. Siebel maintains the parent-
child relationships defined in links automatically so there is no need to query the child Business
Component to obtain records for a given parent. Make use of commands like,
µ& ' c
$
µ to access the parent record, instead of re-querying to retrieve record.
13. Don¶t create objects (BC and BOs) if you need a reference to BC and BO from the current
context. Make use of default application variables µBusComp¶ and µBusObject¶ in this situation.

14. The use of µActiveBusObject¶, µActiveBusComp¶ and µActiveApplet¶ should be limited

because the object represented by these statements may change depending on the active applet.
Siebel recommends the use of the µthis¶ object for eScript (µMe¶ for Siebel VB) wherever
possible. µMe¶/'this¶ represents the object where the code is written, µActiveXXX¶ represents the
object behind the current active applet. The use of µMe¶/'this¶ is a safer method, especially during
development when, it is not entirely clear which applet will be active at any given time. It also
enables easier interpretation of the scripts because the µbase¶ object, represented by µMe¶/'this¶
will never change. The use of µMe¶/'this¶ also removes the need to store the active BusObject and
active BusComp in variables as it does not need to be declared or explicitly destroyed at the end
of the function.

15. All code must be indented logically, including comments which efficiently describe what the
script is doing. Each new script should include a header comment which provides: Author, Date,
Description and Version History for that script.

16. Delete all µempty¶ scripts that once contained text. Delete everything, including the function
header and footer. Otherwise the application will go to that script when the event is triggered and
performance will be impacted slightly.

17. Keep use of Applet scripting to a minimum where possible. Attempt to meet business
requirements by configuring in Siebel Tools where possible and generally implementing scripts
for minor functionality where a given functionality cannot be met using declarative
configuration.

18. Scripts which insert new records or change data should take care to explicitly commit the
record otherwise the data could be lost.

19. When you are deleting records in script based on a particular query, be sure to use a while
loop rather than an µIf¶ statement as the µIf¶ condition will only delete one record where multiple
records may need to be deleted.


(

1: bcPositionMVG.ClearToQuery();
2: bcPositionMVG.InvokeMethod(³SetAdminMode´, ³TRUE´);
3: bcPositionMVG.SetSearchExpr(³[Id] ¶0-5220ƍ´);
4: bcPositionMVG.ExecuteQuery();
5:
6: // The first record is identified and deleted. However,
7: // subsequent child records are not deleted.
8: if ( bcPositionMVG.FirstRecord() )
9: {
10: bcPositionMVG.DeleteRecord();
11: }

Ë(

1: bcPositionMVG.ClearToQuery();
2: bcPositionMVG.InvokeMethod(³SetAdminMode´, ³TRUE´);
3: bcPositionMVG.SetSearchExpr(³[Id] ¶0-5220ƍ´);
4: bcPositionMVG.ExecuteQuery();
5:
6: while ( bcPositionMVG.FirstRecord() )
7: {
8: bcPositionMVG.DeleteRecord();
9: }

)*+c

 

  

The main purpose of Siebel Browser script is to extend the functionality of the browser. So
Browser script should be limited to user based events. On the other side Server Side script is
used for data manipulation or anything beyond the capability of the browser.

c



 
  
(

Communication with the user

Interaction with desktop applications

Data validation and manipulation limited to the current record

  

 
  
(

Query, insert, update, and delete operations

Access to data beyond the current record. So validate your requirement against this best practice.

),+r
& -.&c
$

- 

  -.& 



As the method name suggests it gets the Business Component of the record that MVG is based
on. This is a very helpful Method that would save a several lines of unnecessary code.

For example, we have Accounts and there are Sales Reps associated to each of these accounts.
These Sales Reps are based on Position BC. Position BC is the MVG Business Component of
Account BC. The requirement is to get all the sales rep associated to the details of all the sales
rep associated to this account using eScript. Now a developer who is writing this eScript and not
aware of this Method would write an eScript something like this.
Get Account Row ID

Get Account Position BC

Query for Account ID

Get the corresponding Position Id

Get Postion BC

Query for that Postion Id from step 4

Get Employee details from this Position BC

"
  
  

  / 


Get Account RowId

Get all the sales rep records using GetMVGBusComp

Get Employee details from this Position BC.

Here is the code for your reference.

---------------------------------------------------

oAccBC = oAccBO.GetBusComp("Account");

//Get the corresponding Sales Rep Bus Comp ² eScript Best practice here.

var oAccPostnBC = oAccBC.GetMVGBusComp("Sales Rep");

//Add search spec to already filtered records

//No Need to get the Sales Rep those are associated to only this account

//The Method already gets sales rep that belongs to only this account

//Do not to use ClearToQuery here.

//You could add more Search Spec if you desire

oAccPostnBC.SetSearchSpec("Position Type","Partner Sales Rep");

oAccPostnBC.ExecuteQuery();

var rAccPostn = oAccPostnBC.FirstRecord();

//Here I am getting all the email Addresses

while(rAccPostn)

sEmailAddr = sEmailAddr + oAccPostnBC.GetFieldValue("Active Email"a) + ";";

rAccPostn = oAccPostnBC.NextRecord();

))+.  
  
. Ë 
   

After you execute the method ExecuteQuery() make sure to check if there is at least one valid
record that you desire otherwise it might result in an invalid scripting. For example in the code
above before I get the email addresses I check there is a valid record returned from my
ExecuteQuery Method using the while statement. Otherwise GetFieldValue on the BC record
will behave weird by throwing error. Also you could use IF statement to check if you expect the
result to have just one record.

) +