Friday, March 20, 2015

Your eScript loop sucks!

Scripting in Siebel has a bad reputation.

I'm not that old with Siebel, but I believe this bad reputation may had started because Siebel started scripting with VBScript language. It is that easy to make terrible code with it.

If you don't agree, please leave some comments explaining why Microsoft moved from it favoring other programming languages.

Anyway, I'm always listening that scripting is bad and you should avoid it at all costs.

Yeah, right.

"Because learning how to program is not for everybody" should be the rest of the recommendation that nobody will give you.

That's not because programming with eScript requires an "Einstein". Because programming requires attention and dedication. If you want to do it right, you must practice it, study it. There is no way around, this is not the same thing than drawing squares and dragging arrows around.

And, to finish my rant, let's go for a example. You should have seen that a lot in your life developing with Siebel:

var OfferBO = TheApplication().GetBusObject("Offer");
var OfferBC = OfferBO.GetBusComp("Offer");

OfferBC.SetSearchSpec("Id", TreatmentID);
var rec = OfferBC.FirstRecord();
while (rec) {
    //do something with the data
    rec = OfferBC.NextRecord();

OfferBC = null;
OfferBO = null;

It's the same old story to get data from the data layer. Let's ignore that this lame code is not using try-catch for now,  just please take a look at the while block.

You did? Right... now, if you're doing loops like that PLEASE STOP for God's sake!

eScript has the proper statement to do that kind of thing and I wonder why people keep writing the same damn thing:

if ( OfferBC.FirstRecord() ) {

    do {
        //do something with the data
    } while ( OfferBC.NextRecord() )

} else {

    TheApplication().RaiseErrorText("What the hell?!? Where is my data???");


Now you have it. Cleaner code. No extra variable to control execution flow. Properly validating that you have the data you're looking for or doing something about otherwise.

Let's tweak a little further:

    var OfferBO: BusObject = TheApplication().GetBusObject("Offer");
    var OfferBC: BusComp = OfferBO.GetBusComp("Offer");

    try {

        //Get the priority
        OfferBC.SetSearchSpec("Id", TreatmentID);

        var Priority:String = null;

        if (OfferBC.FirstRecord()) {

            do {

                //a silly example, but anyway...
                Priority = OfferBC.GetFieldValue("Priority");

            } while (OfferBC.NextRecord())

        } else {

            TheApplication().RaiseErrorText("No offer found for treatment id " + TreatmentID);


    } catch (e) {

        throw (e);

    } finally {

        OfferBC = null;
        OfferBO = null;


Let's review the changes:
  1. Using strongly typed variables: you should be using it nowadays to improve eScript performance.
  2. Hey, try-catch-finally is there for something! Use it!
  3. Always declare your cursor type when calling ExecuteQuery, and use a constant for that, not a number. "ForwardOnly" is the one you want in most cases.
  4. Always check if you're getting what you're expecting. If you're not, do something except hiding the dirt under the carpet. If you don't know what to do in such situation, add an exception and later you figure it out during your QA tests with some functional expert.
  5. Clean up your objects, you don't want a memory leak crashing the Siebel component.
That's it. And come on, it wasn't that difficult, it was?

Additionally, let me tell that despite Siebel Tools not helping you with that, your code does not have to look like indented by your cat sleeping on your keyboard. There are plenty tools to make your code look nice, I personally use for that.


Friday, March 13, 2015

Resolving HTTP 404 errors for Siebel on Linux

I couple of weeks ago I was checking OHS logs files that serves a Siebel web application instance for some errors regarding the application and what I found were a lot of errors regarding "File Not Found" (HTTP 404) errors.
Double checking those messages, all them seem to be happening because of two different "categories":
  • transparent GIF images used in the Siebel vanilla application
  • favicon.ico
In the first case, I had to look for those GIFs in the Siebel default folder for web content. The files were there. Looking further, I found a bug regarding Cascading Style Sheet: those CSS files, while used under Microsoft Windows OS didn't bother to use the correct case for file names or file extensions. For those GIFs, that meant the file extension was written as ".GIF" meanwhile it should be lowercase (at least the image files had that in lowercase).

File extensions don't make much sense for Linux, but the OS is case sensitive regarding file names. That's why OHS wasn't able to find them.

A fix to this issue is simple: change the CSS or the GIF file names. I preferred the former since using Sed for that is pretty straightforward. Assuming that the Siebel Server is installed in the directory defined for the $HOME environment variable, that's what I did:

tmp_file=$(mktemp);sed -e 's/\.GIF/.gif/g' $HOME/81/siebsrvr/webmaster/files/esn/main.css > "${tmp_file}";cat "${tmp_file}" > $HOME/81/siebsrvr/webmaster/files/esn/main.css; rm -v "${tmp_file}"

tmp_file=$(mktemp);sed -e 's/\.GIF/.gif/g' $HOME/81/sweapp/public/esn/files/main.css > "${tmp_file}";cat "${tmp_file}" > $HOME/81/sweapp/public/esn/files/main.css; rm -v "${tmp_file}"

That took care of fixing in place those CSS in webmaster and sweapp directories (yes, you should make that on both since they are synchronized by the Siebel application). This bug seems to be present only in Siebel versions or lower.

The second issue is easy to fix as well. You only need to find the proper favicon.ico file to use (most probably the one used by the company in their institutional web site). Just copy the file to the root folder of OHS and the next time a modern browser hit the page, it will find the icon just fine.


I really don't know if the end user will ever notice that those images are now available... if they did, we should know about errors long before looking at OHS log files.

The main reason is to avoid thousands of HTTP 404 errors being logged. It doesn't hurt anyway to check OHS logs anyway from time to time to see how things are going.