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.



-243x162.jpg)
No comments:
Post a Comment