eScript: The Siebel Stack

Does your Error Handling framework provide you with a stack trace? People have asked me whether its possible to get the stack trace, or get the name of the function when an error occurs in Siebel. I cautiously say Yes to both, because this method can be easily abused. This article is aimed at the framework designer looking to enhance their project's error handling capabilities.

Respected ex Siebel engineer Mike M Lin, wrote an article on Getting the Call Stack from eScript. In that article, he raises a Siebel exception, and scrapes the error message property to get the call stack. Unfortunately in Siebel 8, Siebel has removed the stack trace information from the error message property when using TheApplication().RaiseErrorText. Siebel has also blocked the ability to enumerate the error object, so the same test case can’t be performed.

According to bookshelf, when an operation fails, Siebel generates an Exception Object. The exception is documented with two properties: errCode, and errText

I’ve taken the Siebel example, added some log statements, and put it through The Harness

We verify that the error is indeed an instance of the Exception Object, and that the Siebel example works.

Next I modify the example to include the two properties that Mike M Lin, identified as part of his test case:

name, message.

Name turns up a blank, and message stores the same value as errText. There is no stack trace in sight, so I try the same test case with TheApplication().RaiseErrorText(), as Mike did, but unfortunately this also produces no stack trace.

Producing the Stack Trace

We can conclude that the Siebel Exception object no longer produces a stack trace, but Siebel Exception objects aren’t the only types of Error objects that are created in eScript. According to the ECMA specifications, which Siebel eScript is based on, there are other types of errors that can be thrown.

In the above example I’ve created a Reference Error, which reveals that the Stack trace is accessible with other error objects within Siebel.

Heres another example, showing the stack trace that is produced with more than 1 function. You'll notice that the stack trace at this point contains a dummy error message, but we'll see how this can be utilised a little later.

Getting The Current Function Name

Getting the stack trace is nice, but it would be great, if we could also get the name of the function that the error occurred in. We can see from the above stack trace, that it would be trivial to write a routine to extract the name of the last function.

The stack trace format is different of the Siebel 7 example, but it's not hard to parse. Heres a quick test case that I put together.

Note: In Siebel 7, the name of the current function can be accessed by "arguments.callee" in eScript, however this has been deprecated in Siebel 8.

Error Object On Steroids

Armed with the above knowledge we can now produce a stack trace at will (even for Siebel generated exceptions), throw back a custom error object containing our stack trace, and log it as part of an Error handling framework.

The concept of throwing a custom error object has been discussed before in ABS Framework - Logging & Tracing Module. The author of the ABS framework has provided some really interesting concepts around error handling, but if we strip away the message lookups, variable bindings, and the bells and whistles, we can take away the concept of throwing custom error objects, and mix it with our idea of generating a custom stack trace, plus extracting the name of the error function.

It can be boiled down to the following steps.

1. Throw an error
2. Check that the error is not an instance of our custom error
3. Cause a stack trace using the method described above
4. Scrape the relevant stack trace information, and ignore the dummy error message
5. Scrape the error function name from the stack trace, also described above
6. Create an instance of custom error with the above data
7. Insert the original error from the real error object into the custom error object
8. Re-throw the custom error
9. At your root function check for the custom error, and log the stack trace, error information

The above steps outline how to create and handle a custom error object. A framework designer can take ownership of it, and incorporate these ideas into your own in-house error handling framework.

Logger Concept

Another complimentary method is to implement a custom script logger. This was also introduced to readers, when we visited the ABS framework logging capability. For a real life example of a logger, Siebel master Mik has kindly shared his design here.

A sample logger template looks like this.

function MyFunction (){
     log.begin("MyFunction");//hard coded function name

Every function would contain the above template, in which a custom logger is called with 3 main methods.

log.begin - Pushes a string of the current function name onto a custom stack
log.end - Pops the last function from the stack.
log.error - Logs the error

When an error occurs, you know that the last function in the stack is where the error occurred, and by its very nature, the custom stack can be simply printed out, as it is just an ordinary array.

The downsides of this technique against the one described above is that it does not provide line numbers, and the developer is also responsible for hard coding the correct function name in log.begin, and also consistently calling log.end.


By causing Siebel to stack itself, we are able to take advantage of the extra information that is provided by the standard ECMA error objects. This provides crucial information of the events leading up to any Exception, including the exact line where it occurred. And with a little added imagination, we can collect further information from each function as the error object is bubbled up the chain, a la ABS framework.

In this article, I've shown how we can get the name of the current function, generate a stack trace at will, and its importance in error handling. Integrating it into your own framework is the fun part, this will require engagement with your core framework professionals, and will require an impact analysis.

Credits goes out to Mike M. Lin for providing the seeds for this article, Mik Branchaud for sharing his logger design, and Mr ABS for sharing his wisdom on error handling in the ABS framework.

Open UI: Build Process


Siebel projects that are crossing over to Open UI, will soon realise the immediate need to implement standards around the development and deployment of the external resources in Open UI. Unlike traditional Siebel development, where source code is checked into a database and compiled into a SRF with a proprietary IDE, Open UI is based on text files that can be edited using Notepad.

Managing external files is not new to Siebel development, but it has never been mainstream, and the processes for managing these resources are not as mature on Siebel projects. This article is aimed at Siebel development managers looking to incorporate best practice from file based development environments, and integrating them with Open UI.

Traditional Vs Modern Siebel Development

A traditional Siebel development cycle involves the developer checking out and locking a project/object, the developer performs the modification, and checks it back in. The Siebel repository stores the source code, which must be compiled into SRF.

Parallel development can be achieved by following the above process with a second repository, and managing the code promotion through a separate environment path. Eventually when those code bases needs to be merged, objects are moved between repositories through exporting and importing SIFs. Siebel provides a decent merge tool for configuration changes, but merging script is always a risky affair, due to the inability to perform a line by line merge.

With Open UI development, developers have to switch from working with a database base repository to a file based repository. This file based repository is similiar to the Siebel repository that it stores the single source of truth for a particular release. Parallel projects can also be supported in a similiar manner, by establishing a separate container.

Open UI development is very much like web development, files can be edited freely in your code editor of choice, the application can be easily debugged from any browser, and you have the flexibility to pick and choose your add-on web technologies. There is no longer a dependency on the Siebel way to build your application.

Building your Application

Do you use XSLTs, client side business services, custom images/JS/CSS, customized web templates? Then you need a build process. A build process allows projects to automate the production of artefacts for deployment with the following advantages

* Resources are deployed in a consistent manner
* Automated quality checks
* Files are optimised for Production
* Integration with Source Control
* Automated unit testing

To achieve the above tasks, we’ll need to establish the build process, procure the required toolset, and develop the necessary automation.

Establishing a Process

Projects need a formal strategy to manage the migration of files from source to deployment. Fundamentally this process should address how files are tracked, changed, merged and deployed, across multiple parallel development streams. This shouldn’t be new territory, so projects don’t have to go shopping for a new process, unless it is broken. Existing HI file deployment processes can be carried over, and augmented to incorporate the some of the best practices from modern web development.

* Integrated Source control
* Continuous Integration
* Automated test cases

SCM (Source Control)

The concept of building an application requires that we have a source. For traditional Siebel development, this source is the Siebel repository, in Open UI, the source should also be in a repository, but it is more likely to be a file repository rather than a database repository.

There are many solutions in the market that offer Software Configuration Management (SCM), but it is up to each project to choose the appropriate solution for their needs. The most obvious place to look is within your own organization to discover what SCM software is available, and used by other IT sections. This allows you to take advantage of the licensing agreements, and leverage the existing support arrangements that are already in place. Open source/free SCM sounds great, but it is risky to introduce it into an Enterprise, unless you have the expertise to maintain/support it yourself, otherwise prepare to negotiate for the support arrangements.

Build Automation

Automation tools allow projects to enforce a standard build process to a set of source files, create build packages and deploy it into its destination. Many projects schedule the automatic compilation of the SRF, generating browser scripts, and deployment of the SRF into development environments overnight. The same process could also be extended to deploy Open UI resources into the same development environment.

Here are some examples of automation that can be applied to Open UI resources before deployment

* Add standard headers such as revision, organization details, release information, disclaimers to all files
* Strip comments from files
* Compress JS/CSS files through minification
* QA JS files with JSHint/JSLint
* Consolidate common JS Files to reduce HTTP requests
* Extract metadata from JS files, and produce documentation
* Run unit test scripts

Are you using a build process for HI? The same principles can be used in HI for other external resources.

Here are some ideas

* Automatically turn off XSLT indenting
* Generating XSLT documentation
* Extracting eScript from the repository and validating it
* Run interface test cases

Code Editors

While Notepad and other standalone editors are sufficient, it is recommended that you choose an editor that has the capability to detect JS language errors, integrate with your SCM, and automation tools.

Siebel Tools has this capability built in to an extent, but in Open UI, if you miss a closing bracket, and it is loaded via a common file, your application could fail silently, and pin pointing it to its exact source might not be fun. Code editors can perform the role of QA, by ensuring that your code is free from syntax errors before it is run against more stringent QA checks by programs like JSHint/JSLint

Automated Test Cases

Automated test cases are used as part of Continuous Integration to ensure that changes from multiple developers, work coherently and doesn’t break the application. The challenge is that developing automated test cases for the UI isn’t easy, at least not for traditional HI UIs. Open UI promises to be open, and exposes a new set of APIs for browser automation tools to interact with.

Until Oracle provides an Open UI automation client (for developers), conceptually, a project could develop their own Open UI automation testing, using a combination of the following tools

* Selenium
* Watir
* Ruby
* Custom JS OUI automation API

Selenium provides the browser automation, Watir is a ruby library that provides a nice abstraction onto of Selenium, and a custom JS interface provides the API bridge between Ruby, and the Open UI client.


Your build process will be dependent on the tools that’s supported by your organisation. The best tools for the job, are dependent on a variety of factors, like cost, availability, familiarity, features, and support. There isn’t a standard set of tools for everyone, however the main tools in your arsenal should be the IDE, SCM, and Automation tools

* List of source code editors
* List of build automation software
* List of SCM software

Other tools to investigate

* JS minification
* JS/CSS consolidation
* JSHint/JSLint
* JS Documentation


Establishing a build process isn’t something that is restricted to large teams, it just important to have this process in place for a single developer working offline. There are times when you need to blow away an environment and rebuild from source control, or you need to rebase to a completely new project. Having source code control becomes critical for working in Open UI especially in large teams, so gone are the days where it is acceptable for developers to modify files directly on the web server.

A build process can ensure that your application remains stable throughout the iterative development process, or alternatively without one, your project can become a cowboy arena, where developers go in, make adhoc changes, send off different file revisions for deployment via emails, and break the application at every deploy. The choice is pretty clear.

Further reading

* Why use source control
* Setting up a JS Build Process
* Siebel Continuous Integration Setup
* Branching, Merging concepts with Git

Some customers will have more mature processes than others, so what build tools are you using in your project?

To kick this off, here’s what works for me

* ANT (Build automation)
* ClearCase (SCM)
* Eclipse (IDE) + ClearCase Plugin
* Sublime (IDE)
* Eclipse JSHint integration via RhinoJS
* YUI Compressor (JS minification)
* + Selenium & Ruby for some UI automation fun