1. Always use TheApplication 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 behaviour.
2. User-defined functions must be Forward Declared 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 'With' 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.
5. Using variables 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'. '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 'ActivateField' 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. 'ActivateField' should only be used prior to 'ExecuteQuery' 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 'ForwardOnly' 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 3 or more 'IF Else If' statements then use 'Switch Case' statements instead. This simplifies code and improves performance.
11. It is best practice in Siebel scripting to use the 'Try/Catch/Finally' 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.
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, 'GetParentBusComp' 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.
Wrong Way:
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: }
Related Posts
Very helpful. Thanks for the articles, please keep on updating
ReplyDeleteUseful Tips, Thanks for Posting
ReplyDeleteThanks for Posting helps a lot
ReplyDelete