Monday, May 26, 2008

A test drive with the Siebel 8 ST engine


A new script engine i.e. the Siebel ST eScript engine has been made the default scripting engine in Siebel 8.0.
In case you did not know, Siebel eScript is a scripting or programming language that application developers use to write simple scripts to extend Siebel applications. Till recently, the default script engine for Siebel Tools and Client Applications was the T eScript engine. And ST for the uninitiated stands for Strongly Typed.
If you stayed awake through your programming classes, you might remember that strongly typed languages bind variables to a particular data type. So if you declare a variable to be of type Dog, you cannot abruptly decide to assign a Road-Roller to the variable midway through the program. The good thing about this is you cannot call invalid methods like Road-Roller.bark() or Dog.BlockTrafficAndAnnoyCommuters() by mistake.
The bad thing is that you need to declare more variables and therefore need more runtime memory when using a strongly typed language instead of a weakly typed languages. There are proponents for both types of programming languages. But that is not the issue that interests us here.
What did interest me is that Siebel claims that the ST eScript engine provides the following enhancements:
  • Improved performance and self documentation due to strong typing of variables
  • ScriptAssist utility and
  • Fix and Go feature
I decided to take the ST engine out for a test drive to see if the above claims are indeed true.
In my little experiment, I decided to use a COMCreateObject to pull the data from an external source, in Excel and update the Siebel database. The excel file contained some new records that and some changes to existing records. The update would be triggered on the click of a button which would in turn invoke a Business Service which comprises of many functions.
Here are my findings:
ScriptAssist
I loved the new Script Assist Feature which makes the life of the programmer much easier providing auto-complete, auto-indentation, method listing, and method signature capabilities.
There is no longer a need to remember all the methods related to an object. Just press Ctrl+Space or “.” and ScriptAssist will display a dropdown of all methods and properties available for that particular object.
This is a big timesaver and is highly appreciated by us.
Auto-complete is another nifty feature that helped us avoid a lot recompilation. Just enter the first 2-3 alphabets of a method and it shows the available method name. For example, when I started off with the letters “BusC”, the editor offered to save me the effort of typing in the remaining 5 letters in “BusComp()”. This is similar to IntelliSense technology from Microsoft.
Fix and Go
With Fix and Go enabled, there is no need to compile the .srf to restart the debugger after making a change.
This was a big pain in the bad old days. With fix and go, I hope to have a lot more time to spend on “strategic meetings” near the coffee machine.
Performance improvement because of Strong typing:
I tried to see if I would get any performance improvements by using ST Script by putting an equivalent piece of code created in ST-Engine with another piece of code in Siebel 7.8 T-Engine
Although we ran the code through some 10,000 iterations, we did not see a major difference in the execution time.
However, there should in theory be a performance improvement on account of saving time on type-checking at run-time and compile time.
Also, the code should be more robust as it would not be possible to call invalid methods as it would be in a weakly typed language
So, should I throw away all my T-script Engine code and embrace the new ST-Script Engine ?
It depends on the amount of scripting you have done in your Siebel Installation. If you have heavily customized your objects with scripting, it is going to be a major exercise to verify that the code is working correctly in the new environment.
But once, the upgrade is done, there should be a performance improvement and your application will be more robust because there is a lower likelihood of getting those errors because of calls to invalid methods.
Inputs from Sajid Attar and Abhinav Anand.

0 comments:

Post a Comment