Showing posts with label ABS. Show all posts
Showing posts with label ABS. Show all posts

ABS Framework - Business Object Library

The ABS Business Object library is probably the most important feature of ABS, from a benefits realization point of view, and heres why.

ABS can make your project atleast 2x more efficient.

The ABS framework provides a global class of functions that allows developers to write code that is leaner, faster, use less memory and require less time and resources than traditional build methods.

That’s a really big promise, and we should be sceptical when someone makes a claim like that, but in this article I’ll look at how ABS achieves this, and how it can be quantified.

[Abstraction Layer]

The goal of the ABS Business Object library is to build on top of the existing Siebel BO functions, and provide the developer with tools to achieve complex functionality with just a few lines of code.

It’s difficult to talk about abstract concepts, without an example, so heres a scenario that all developers can relate to.

If you wanted to query an Account and get back the primary Address related to this account and return the state and city in an array, how many lines of code would it take?

Here’s the traditional way of writing this logic in standard Siebel eScript.

function GetAccountInfo() {
var aAddressInfo = [];

var oBO_Account = TheApplication().GetBusObject("Account");//1
var oBC_Account = oBO_Account.GetBusComp("Account");//2
var oBC_Address;//3

try {

if (oBC_Account.FirstRecord()) {//10
oBC_Address = oBO_Account.GetMVGBusComp("Address");//11

if (oBC_Address.FirstRecord()) {//12
aAddressInfo[0] = oBC_Address.GetFieldValue("City");//13
aAddressInfo[1] = oBC_Address.GetFieldValue("State");//14
} //15
else {
throw "No Address found in the Account";

catch(e) {
throw (e);
finally {

return aAddressInfo;

That’s over 15 lines of actual logic, not including line spacing, and error handling. So how many lines does it take using the ABS BO Library? Just one.

Here’s how we would write the same logic using ABS.

function GetAccountInfo() {
var bErrRaised=false,aAddressInfo;

try {

aAddressInfo = TheAccount.GetChildFieldValueWithId(“1-ABC”,TheAccount.oBCChild_Address,["City","State"],true))[0];//1

throw (e);
finally {
if (!bErrRaised) return aAddressInfo;

Let me explain what is happening here.

TheAccount  This is a predefined ABS BO object that is always available in the Application.

Take it for granted that this exists, and you can use it anywhere, and in the chapter on the ABS Universal Object, I’ll explain how this object comes into existence.
TheAccount.oBCChild_Address  This is another predefined ABS BO object.
GetChildFieldValueWithId  This is a method of the ABS BO Object, which is inherited by all BO instances such as TheAccount. It allows the developer to query a child BC using a row id as a search spec, and return a set of values as an array.


sId = Row Id

hbChildHandler: Child BC instance

hbChildField: Fields to return

bRaiseErrIfNoRecChild: throw error if not found

sSortSpecChild: Child BC Sort Spec


The above example highlights one of the main principles around ABS: Re-use.

Why do we have to write

GetBusObject(), GetBusComp(), ClearToQuery(), ActivateFields(), SetViewMode(), SetSearchExpr(),ExecuteQuery(),FirstRecord()

in every function, in every business component, applet or business service in the application, hundreds of time, over and over again?

We can start to imagine how this kind of code writing can lead to application bloat, adding to application maintenance, reducing the upgradability of a project, and obscuring business logic with un-necessary repetition of technical artifacts.

ABS encapsulates the above logic in a single function, that can be used anywhere in the application.

Writing less code, will definitely add to your efficiency.


One of the main arguments for using declarative configuration methods is that it can be easily upgraded. The reasoning is that if all your logic is configured rather than scripted, then the upgrade would be painless and carefree.

Well, that is really not the case. In 7.5 you could have WFs that have steps that were free standing with no connecting lines, 7.5 also allowed WF designers to have multiple start points. This is illegal in 7.7 onwards, and during the upgrade you will have to fix all your WFs.

Experienced people will see that WFs are not foolproof in upgrades, they are just as likely to be obsolete as scripted solutions.

The argument against using traditional eScript, is when you perform an upgrade, Siebel does not touch your script, so every piece of code has to be retested.

How does ABS differ?

The highly modular design of ABS makes it more favourable to upgrades.

For example.

If Siebel decided to make ActivateFields deprecated, and forced developers to use ActivateMultipleFields instead.

You’ll only need to find that one place in the ABS framework, and replace it with the new method. Of course, the unit testing has to be thorough, but once it has been unit tested in this function, the entire application will benefit.

Upgrades can never done by the push of a button, but if you given the choice of upgrading an application with a hoarde of WFs with hundreds of individually defined steps, a massively scripted spaghetti system, or a highly modular but concise scripted system, which one would you choose?

[Improve Efficiency]

Let’s revisit that promise again.

“ABS can make your project atleast 2x more efficient.

…write code that is leaner, faster, use less memory and require less time and resources than traditional build methods. “

Write faster code

If we had two developers with EQUAL knowledge and experience, 1 is skilled in eScript and the other is skilled in ABS.

Which developer would have the advantage? I think the answer is obvious. The eScript developer would have to write 15 times more code than the ABS developer.

That is an unholy advantage. Not only would the ABS developer be faster, but would also have 15x less code to troubleshoot if there was something wrong.

Leaner code

15 lines vs 1 line, need I say more?

The code is not only leaner, but also more representative of the business logic and more readable at the same time.

Use less memory

Business Objects and Business Components are only ever instantiated once, and re-used throughout the lifetime of the user session. This will be explained in more detail in a section for the ABS Universal Object.

Less time/resources

The tangible benefit that the ABS BO library brings to projects is obvious. To run and maintain a large scale project will require less time and resources. This puts project managers in a better bargaining position.

Theoretically, you would have to hire 15 eScript developers to do the same amount of work of 1 master ABS developer.

But realistically, you do not need to hire master ABS developers, you only need to get Siebel developers who have a solid foundation in scripting (preferably ECMA), and who are open minded to the ABS philosophy.

While you cannot hire just anyone that walks in from the street, you’ll only need a few very good people, rather than a brigade of good people.


The use of ABS is not widespread, and part of the reason for this is that it needs to be implemented as a total solution, and not in bits and pieces. And the most suitable implementations are the green field projects, or projects which are still young.

Currently there is only one Systems Integrator that is implementing ABS solutions on a grand scale, and the benchmark hasn’t been made public.

A 2x improvement in efficiency sounds controversial, but if we base our conclusion of other ECMA script frameworks, such as jQuery, Scriptaculous and Prototype. We know that scripting frameworks do deliver on efficiency, as well as improving code readability, and application maintenance.

We saw that by using ABS, build and testing times were cut by a factor of 15. Saying that ABS delivers 2x more efficiency is quite conservative, but keeps it realistic.

Code bloat is detrimental to the long term maintenance of the application, and the main culprit is eScript, so its interesting to see a framework like ABS tackle this problem head on with a very radical tactic:

Using ECMA Script to reduce eScript.

Implementing a concise, highly modular, Siebel framework, using ECMA script to lay the foundation, is not something that your average scripting expert can achieve.

People that can pull off this sort of feat, are your architect of architects.

ABS Framework - Prototype Library

[What is a Prototype?]

Using the prototype object is common in web development circles, but it is foreign to most experienced Siebel professionals.

This is the definition of “prototype” object according to Siebel Help
    An object prototype lets you specify a set of default values for an object. When an object property that has not been assigned a value is accessed, the prototype is consulted. If such a property exists in the prototype, its value is used for the object property.

    Object prototypes are useful to be sure that every instance of an object use the same default values and that these instances conserve the amount of memory needed to run a script. Then every instance of the object use the same function instead of each using its own copy of it.

That is quite an abstract description, and although it tries to explain the concept using a generic example, it still feels very disconnected.

In layman terms, using the prototype statement allows developers to add properties and methods to all instances of custom and pre-built objects in eScript/browser script (excluding Siebel Objects).

    So how do we use prototype to solve real world Siebel problems?

[ABS Prototypes]

The ABS framework includes prototypes to reduce the daily scripting chores for Siebel professionals. In this article we look at the some of the most interesting prototypes in ABS, and see how it can make our lives easier and more fun.

The ideas for these prototypes comes from years of experience and tideous hours of work to encapsulate the common routines that Siebel configurators and Integration people can share in one common library.


There are a lot of times when we want to compare the current active view, to a list of predetermined views, before performing some action.

Normally we have to write code like this to achieve it

var sViewName = TheApplication().ActiveViewName();

If (sViewName == “View1” || sViewName == “View2” || sViewName == “View3”) {


ABS provides us with IsIn() to achieve this same functionality in a more elegant manner.

var aViewName = [“View1”,“View2”,“View3”];
if (aViewName.IsIn(TheApplication().ActiveViewName()) {

This function returns a Boolean, indicating whether a value exists or not, but also returns an additional property that points to the index of the matched value.


ToISO() is useful for formatting dates to ISO format. This is commonly used to convert dates, so it can be easily sorted alphabetically.

var oDate = new Date(2000,1,1);
oDate.ToISO() = "20000101"


ToDB() allows the developer to get the current date and do a setfieldvalue without doing messy conversions.

Date.ToDB() //This returns the current date in MM/DD/YYYY format for setfieldvalue

Compare() is a really powerful shorthand method of comparing dates or datetime.

A common business requirement is to ensure the currently selected date is greater than the created date, but less than a future date.

Heres how we would normally perform this operation.

//Convert to date object
oCreated = new Date("12/31/1999");
oFutureDate = new Date("1/1/2001");
oCurrentDate = new Date("1/1/2000");

If (oCurrentDate.GetTimeStamp() > oCreated.GetTimeStamp() && oCurrentDate.GetTimeStamp() < oFutureDate. GetTimeStamp ())

ABS does it in one line

Date.Compare("1/1/2000",">","12/31/1999","<","1/1/2001") = true

Heres a couple more examples of how it can be used to quickly compare dates.

//Created for date comparison of date1>date2 or date1>date2>date3
//Example 1:
Date.Compare("12/31/1999",">","1/1/2000") = false

//Example 2:
Date.Compare("12/31/1999","<","1/1/2000",">","") = true
//for the case of open date


PSToStr () converts a Siebel PropertySet to a string for debugging. This is a very common situation for developers to find themselves in.

But it’s the implementation of this function as part of the Array object, which makes it unique. This allows it to be executed from Global scope, anywhere in the application, without using business service script libraries.

var oPS = TheApplication().NewPropertySet();

[oPS].PSToStr(); //This returns a string representation of the PS

[Reducing code in your application]

Date.Compare() is a really good example of how prototypes can reduce code in your application. This prototype allows a developer to use date strings, to compare dates, without having to manually convert them to date objects.

Converting strings to dates is integral to comparing Dates correctly in Siebel, so instead of having these date conversion routines littered across the application in BCs, Applets and BSs, ABS prototypes this functionality to the Date Object.

ABS Prototypes is a feature purely for coders, but even if you don’t write a lot of script, whatever script you write will be very compact.

What if your project has massive amounts of scripting? We all know these projects exist.

Some projects start off with the noble principle of “exhausting” every declarative means of configuration, before turning to script, but this usually dosnt last, and there are a few common reasons for this.

    * Project cannot say “No” to funky ideas from business
    * Tight deadlines
    * In-experienced developers

Its likely to be a combination, if not all of the above. Its natural that people pick up scripting quicker than using WF, a junior can come in fresh from high school, know a little bit (or a lot) of Javascript, copy a bit of code from here and there, and with a small amount of effort, get a working solution.

Using prototype allows projects to build your own code library, these functions are bound to the standard ECMA objects, and can be re-used across the application without instantiation.

[Reduce memory usage]

I know you didn’t pay much attention to Siebel’s definition of prototype, but its interesting to revisit it (a part of it).

    Object prototypes are useful to be sure that every instance of an object use the same default values and that these instances conserve the amount of memory needed to run a script. Then every instance of the object use the same function instead of each using its own copy of it.

At this stage, we have a little more context of what prototype can do for our projects, and the Siebel definition seems to be more comprehensible.

But for the project managers, and executives out there, the prototype objects ensure that functions are instantiated once and shared across the application, and by taking advantage of prototypes, a project can reduce the memory usage in the application.

With a robust suite of prototypes at the core of your application, you have a more scalable and manageable solution at hand.


The ABS Prototype feature, dosnt make people better scripters, but it does reduce the amount of scripting in the application, and provides a repository of common routines, that in-experienced (and experienced) developers can rely on, without re-inventing the wheel.

Benefits of using Prototypes

    1) Reduce the size and clutter in the repository
    2) Reduce redundant code writing
    3) Standardize implementation of common routines
    4) Easier code maintenance
    5) Speed and streamline up code development
    6) Reduce memory usage


Prototypes should be implemented by developers with a solid understanding of ECMA script (not eScript). Improper implementation of prototypes can lead to memory leaks and defective behaviour across your application.

This also applies to projects that currently have ABS, and want to enhance the prototype library.

Projects need to ensure that there is a clear owner for the prototype library, and this person or group, have exclusive controls to these library functions, and makes changes on behalf of everyone. This ensures a layer of quality control, and a consistent coding standard is maintained for the project.

ABS Framework - Logging & Tracing Module

Log files are the bread and butter of every developer, so every once in a while it is interesting to meet a developer who has never used Trace() before. So how do these people troubleshoot Siebel? Using debugger, amazing!

Although debugging is useful, it’s not always reliable. In complex scenarios, when you have logic across different objects, the debugger just dies, or jumps around erratically. In these cases it’s just more efficient to dump out all the information to a file and analyse what went wrong.

From the most mundane, to the most critical problem, having informative logs is crucial to solving problems quickly.

For this purpose Siebel provides us with a basic tool.


Good old Trace, what this does is allow us to route key information to a log file during script execution. This same log file is used by the Siebel application for its application logging. So the first frustration developers get is all the information they are trying to dump out, is being buried by all the Siebel internal object allocation and destruction information.

Trace() is used by developers during the build phase and is inserted when a problem is found or in key areas for unit testing, and it is removed before the code is migrated into the test environments and ultimately in production.

does the job, and gives developers the basic means to troubleshoot problems. Its function is not flashy, and it’s a little better than popping up an alert box, but we all learn to live with it pretty quickly.

[Paradigm Shift]

With that perspective, anyone that looks at ABS business code, will notice one major contrast to the above logging paradigm.

The ABS tracing module is used as part of the program design, rather than to troubleshoot problems as they arise.

In standard code, we normally trace the start, end and catch of each function, and put lots of comments to explain the code.

In ABS code, tracing is done at the start, end, catch, and is put at key decision points in the program, and this is left in the code, even when it is migrated into production.

The advantage of doing this is two fold.

1. The code is self documenting
    By including descriptions of the program logic in business speak, anyone can turn on tracing, perform the function, and the system will spool the program logic to a log for analysis.

2. On demand function execution information
    Since the tracing code is part of the program design, a developer can go into any environment, look at the ABS logs, or re-run the function, and have access to the details of the function execution details.

Similar to the way Workflow provides a debug mode for developers to see step and variable information of the runtime action. This ABS design feature closes the gap on the advantage that declarative configurations once had.

This is quite powerful, because it allows the developer to debug the problem live in an environment with real data, which can’t always be created on a local environment.

[Logging Levels]

Conforming to the Siebel logging standard, the ABS logging module has 5 levels of logging detail. Setting this value controls the amount of detail that is spooled to the log file. By default it is set to 3, but this can be overridden by the developer in the system preference or in the code.

[ABS Logging & Tracing components ]

    1. MSG object
    2. LOG object
    3. EXCEP object

[MSG Object]

One of the key design principles around the ABS System is re-use. Messages can be categorised and parameterised and re-used across the application.

To display errors or log error messages, we need to create our own message category in the Application, ABS encourages this over hard coding custom errors on the fly.

The ABS System creates a category called ABS Defined Messages.

Instead of using numbers and defined ranges for their use, the ABS Logging module uses identifiers with the following naming standard.

The ABS Defined Messages is only used for the ABS framework for standard error messages, to display more specific error messages, we need to create our own custom message category, and follow the above standard to define our messages.

Although it is not enforced, it is encouraged to follow this standard, because it makes managing error messages, and looking up their relationship to the functional areas easier.

[LOG Object]

This object defines how a function is logged, and does the actual job of tracing the messages to a file.

ABS Log files are generated in the following format, but can be changed according to individual user preferences.

 LOG object Methods
 Begin  Tell the logging module that a new function has begun
 Step  Used to record key milestones in the script and document the process
 StepResult  Used to document the result of a milestone
 End  Tell the the logging module that the function ended without any errors
 Error  Logs the error object

The basic construct must be built like this, for the proper logging and log format indenting to happen.

[EXCEP Object]

In a standard application, when an error is raised, the developer can choose to override this error, to provide a different message that is more suited to the context, or bubble it up the the parent function, but local variables are lost when the function loses scope.

In ABS, when an error occurs, the EXCEP object is thrown, the relevant parameters are captured and stored in the EXCEP object, and the original message is discarded after it is logged, the EXCEP object is then bubbled up in the function chain.

When the error bubbles back to the base function, the parameters are written out along with the error message.

This is very interesting, because it allows us to display a meaningful error message with full context of the parameters at the point when the error occurred.

[Example Error Log]

This is the function calling path from the above example.
    BO_Service -> LOV_Service -> LOV_GetValue -> LOV_GetAnyField -> BO_Query -> SYS_Assert

The error is raised at SYS_Assert, but it has no useful information at this point, so the error is thrown up the chain to BO_Query.

BO_Query is the real reason why the exception was raised, the arguments captured by this function are important, and will not be available once the function finishes, so it is bubbled up further along the function chain, with arguments captured from previous functions, until it reaches BO_Service

BO_Service is where the message is finally displayed. The cause of the error is due to a BC query that returned no results, but you want to override this, and display something more meaningful to the end user, but still log the actual technical reason for the developer.

The result is an informative message that contains details gathered from various parts of the function calling chain.

[Consolidated Server Logs]

The ABS Logging module solves a very fundamental problem with Siebel server logs. If you are in a multi-server environment and have 10 Siebel application servers, each will have its own set of application logs. So what happens when there is an error? We need to find out which server we were logged onto!

Why do we have to hunt for our logs?

ABS allows us to save logs from all our application servers in one central location.

Developers and environment guys a like, will really appreciate this feature. The design of ABS is an evolution of the way Siebel manages its logs.

[Self Documentation]

Traditional documentation and diagrams can be quickly outdated, especially if the rules are complex, and change every release. Script should be easy to read and understandable, the ABS system takes this idea further, and uses the logging objects to document the system.

With the correct usage of these functions, the ABS logging module will allow anyone to go into the system, and generate 100% accurate documentation of the system in business speak.

[Pro-active Error handling]

During the build and test phase, a developer builds a piece of functionality, does the unit testing, and migrates the code for testing. The tester will look at the build and raise defects that will event get re-assigned back to the developer. This process can take days.

The ABS system takes a more proactive approach, when ever an error is raised, it uses a SR style ticketing system, and assigns the error, based on its category to the correct position, in real time. This way a developer can get all the details of an exception, even before the tester has even realised there was an error.


The ABS logging & Tracing module provides the following features

    1. Detailed contextual error messages
    2. Step execution and function parameter information
    3. Self documentation mechanism
    4. Problem ticket assignment
    5. Consolidated server logs
    6. Works in WF and Script

Developers will appreciate the level of detail provided by the ABS system.

    1. Point of error
    2. Function calling path
    3. Function inputs and outputs
    4. Name, Value, and Type of arguments used in function

ABS can generate a lot of logs, so its important to keep your eye on disk space. The good news is the design of ABS allows all logs to be saved to one central place, so you only have to monitor one location, unfortunately, we cannot do the same for Siebel logs.

The developer shouldn't have to hunt around the logs for an error, then wonder where it exactly originated, and what were the conditions that caused it to error. All this information should be captured at the point of error.

If we reflect for a moment and compare the ABS logging module to the standard Siebel solution, the TheApplication().Trace() feels somehow inadequate, its like trying to fight fire with a water pistol.

The ABS logging and Tracing modules provides advanced tools for projects to quickly identify problems, turn around a solution and focus on the delivery.

Introduction to the ABS Framework

When considering the solution design for a business requirement, we usually have a few configuration options at our disposal.

One of the cardinal decisions we make, is wether we choose to build our solution using WF or Script, there is a lot of emphasis put on this decision by the Siebel community.

In my opinion, wether we use WF or Script isnt important, what is important, is the result. The ultimate goal should be to ensure that the build, is maintainable, scalable, and upgradable.

In the comming series, and i'm going to look at the ABS framework, and see wether it meets the above goals.

What is the ABS framework?

The ABS framework is a custom Siebel framework that embodies the following principles

  1. Maintainable
  2. Resuable
  3. Scalable

and it is written in eScript!

Its important to note that, the ABS framework is more than just a library of functions, it is an alternative Siebel framework, with features beyond scripting.

What are the features of the ABS framework?

  1. Centralization of all business logic
  2. Reduces scripting
  3. Reduces development time and implementation
  4. Superior Logging and Tracing
  5. Ready made eScript library
  6. Abstraction of Siebel Objects

There is no public documentation on the ABS framework, and what we currently know, are mainly from word of mouth or blogs across the Internet. There are still a lot of questions and speculation about the ABS Framework.

With courtesy from the ATI framework (which is extended from ABS), i have a unique opportunity to explore the framework from the source code level.

In the next series of articles, i will endeavour to reveal its features and discover the answers to all the questions we've been asking.

An interview with the creator of the ABS Framework

I've recently had the pleasure and good fortune, of meeting the creator of the Siebel ABS eScript Framework and what follows will be an interesting journey.

This is a continuation of my first article on the implementation of an eScript Framework.

If you dont know what the ABS Framework is then, this article wont mean much, but for those are keanly following this topic, it will make us re-think the way we develop Siebel and also open a lot of doors that we didnt know existed.

In my first article, i discussed an implementation of a Siebel framework, that solves Mike M. Lin's dilenma of creating a custom Siebel class with proper method chaining.

In the closing of the first article, i hinted on another implementation of the framework, which avoids the horrible problem of attaching methods to the Object constructor.

But my opportunistic meeting with the creator of the ABS Framework (who wishes to remain anonymous), has confirmed this theory, that attaching custom methods to the Object constructor is not the way to go.

I've also discovered, that while our implementation mechanism of the eScript class method chaining is different, our ideas for laying the foundations for a framework and the results are the same.

Our initial conversation covered the architectural design of a framework and the different implementation methods, scripting standards, and the absolute need for such a framework.

We are currently evaluating this framework, and also looking at some potential changes for Siebel 8, but thats as far as we got.

The first and only place, that we've heard about this framework is from the Siebel Unleashed forum, and there is little if any knowledge of this framework, by Oracle or any other independant source, but in conclusion to this article, i can definitely confirm that the ABS Framework exists.

In the next article, i will provide some more information on our eScript framework, so stay tuned...