Browser Script Debugger

One of the joys of working with Siebel is debugging Script, those late nights troubleshooting spaghetti code sure brings back memories. It is even more memorable when you encounter code that has never been unit tested, and wonder how did this ever get into production..

Ah the good times, but where would the fun be without Siebel's debugger. Set a break point where you think the error is occurring, let the application run, and Siebel will halt the execution of the Application at your designated break point, it will display all your current variables, and let you step through the code line by line.

Browser Script on the other hand has always been the poor cousin of eScript, it lacks the interactive debug tools, which has always made it harder to work with. Make a typo in eScript, and you'll probably get a compile error or it will halt your application, but with browser script, a typo will silently fail and halt execution of every other browser script in your application, its quite insidious.

There are a few common methods that developers rely upon to debug Browser Script.

The Alert/SWEAlert box is helpful but annoying and painful when working with loops. I know of people who have implemented browser popups that log information to a separate window, not bad, but dealing with popups is too clunky and slow. Siebel also provides the browser trace files similar to eScript, but a much better tool is the the IE Developer toolbar (IEDTB). It is shipped as part of IE8, but had been available as a separate Add-on for previous versions, if you've used Firebug on Firefox before, then this will be familiar to you.

The IEDTB allows the Siebel developer to

1. debug browser code
2. add breakpoints
3. use log statements
4. watch run-time objects and variables
5. inspect DOM elements
6. run code against the active session
etc, etc

In short, it is pretty badass.

If you are ready to turn to the dark side, press F12 on your keyboard now, otherwise press ALT-F4.


The IEDTB provides the browser with an object called "Console", with the following methods.

console.log('start function');'We love disco');
console.assert((1==2), 'Disco forever);

These methods can be used inside any of your browser script event in Tools, and the results can be inspected in the console window as shown below.

Note. The console must be open at the time when the scripts are run.


This has always been the holy grail of Browser Script debugging.

Here's how it works. In the script drop down, find the JS script that you want to debug, and select it before navigating to the Siebel screen that actually fires it.

Click the left side of the left pane to set the break point.

Now navigate to the View that contains your browser script, and trigger your function. The IEDTB will stop at the breakpoint, and allow you to step through your code.

The Local window allows you to inspect all your local variables

The Watch window allows you to focus on particular variables and even change the value during run time.

You can also retrieve the values of the profile attributes, and run other browser commands by using the script console.

This is good news for all the Browser Script Jedi's out there, the IEDTB is an in-dispensible tool for debugging browser script, and beats the hell out of plain ol' Alert or SWEAlert

Best practice has it that we implement our logic using declarative means, then go to Script as a last resort, but there is an even finer unspoken distinction. When we have exhausted all declarative means, and all eScript means, you have reached the last resort, of last resorts. Welcome to Browser script town, when you get into this bad end of town remember to bring your IEDTB.

The IEDTB has saved my life more than once, and it will save yours as well.

Searching through UTF-16 files

In a typical day of a Siebel EAI developer, we are required to investigate problems with XML/XSLT files, and unless you know the system inside out, and outside in, you may encounter XML fragments that look unfamiliar.

For example, your ESB team sends you an XML that they claim to have been sent from your system, but from looking at the XML you dont recognise the interface that sent it. However you reason that, if you could search through all the XSLT files in Siebel you could track down the interface that could be generating this file.

The most obvious tool at the developers disposal is Windows Find, this is the defacto method of searching for files or text in files in a Windows OS, but beware because this method will not yield any results when searching through UTF-16 files. Surely Unix users would have more reliable tools in their arsenal. What about Grep?

Grep belongs to the Unix family of tools who's sole purpose is for searching, so how does this command fair with UTF-16 files? Fire up any Grep tool within reach and search for "xml" within your directory of UTF-16 XSLT files.

Here were my results.

Windows BareGrepX
Mac GrepX
HP Unix GrepX

To understand this behaviour, open a UTF-16 file in a binary editor, you'll see that there is a "00" byte (shown as a space character) between every character, this is how UTF-16 files are physically represented in the file system, but open it in Notepad or your favourite unicode aware editor, and it will magically render the UTF-16 code points into your familiar readable XML.

With that understanding, it becomes clear why text matches will not work in programs that use a non UTF-16 regex engine.

This is a problem for any unsuspecting EAI developer and Siebel project that relies heavily on XSLT for its request/response Integration, but knowing thy enemy is half the battle already won, so here are a few tools to deal with UTF-16 files.

1. Windows findstr
eg. findstr /s /c:"siebelmessage" *.xslt

This command can match strings in UTF-16, and can be used to search directories.

2. Notepad++
3. TextPad

The above two text editors, could search entire directories, and match for text within UTF-16 files.

With this in mind, I'm sure you could easily find other utilities and programs that can scour through UTF-16 files.

It is a little unsettling to discover that you cannot rely on such ubiquitous tools such as Find or Grep for your Integration needs, but hopefully the next time you get that foreign XML in your inbox, you'll already have a hand on a nearby UTF-16 scraper.