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 {
oBC_Account.ClearToQuery();//4
oBC_Account.SetViewMode(AllView);//5
oBC_Account.ActivateField("City");//6
oBC_Account.ActivateField("State");//7
oBC_Account.SetSearchSpec("Id","1-ABC");//8
oBC_Account.ExecuteQuery(ForwardOnly);//9

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

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

Let me explain what is happening here.



















 Legend
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.


[Inputs]



sId = Row Id

hbChildHandler: Child BC instance

hbChildField: Fields to return

bRaiseErrIfNoRecChild: throw error if not found

sSortSpecChild: Child BC Sort Spec


[Re-Use]

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.

[Upgradability]

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.

[Conclusion]

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.


Reactions:

8 comments:

  1. This is really informative article and clearing out lots of doubts about ABS.

    Thanks a lot for such a nice initiative and great explanation.

    ReplyDelete
  2. Your judgment of 2x improvement in efficiency is a misleading message to me.

    It is true that you don't need many developers, especially costly
    useless contractors.

    It is also true that >100k lines of code can be shrunk to <10k lines.

    But...

    It is not true the overall development can be shortened to half its
    original time, at least not for us. We spent a lot of time to atomize
    the code because ABS itself is a perfectly atomized machine.

    It is definitely not 2X improvement in time efficiency, but it is 99%
    on time for sure.

    The ABS framework version is immeasurably deep. It is too simple to
    summarize the BO chapter with just one function called
    GetChildFieldValue. I actually expected a little more, for example,
    why is ABS programmed in such a classy way to make every line so
    succinct? How did ABS achieve the three principles of object-oriented
    programming?...

    My project is probably the most unique Siebel project recognized by
    Oracle. We need an application to manage hundred thousands of spare
    parts and the suppliers of those spare parts. Our primary choice was
    always SAP and Siebel was never in the picture. After meeting up with
    SAP pre-sales, one of our engineers fed up with the sales talks and
    started prototyping one of the requirement using Siebel. He hacked out
    half of the required functionalities in one week while the SAP vendors
    were still undecided about their right approach.

    When the Siebel prototype was presented, a lot of people said "Are you
    sure this is Siebel? You must be a fool". What they didn’t know was
    that the Siebel solution was done with an impeccable framework.

    What it implied is very striking: Siebel + Impeccable Framework =
    Solution dominated by SAP.

    Overall...

    Siebel is good in process-oriented application but nothing close to excellent.

    Siebel is adequate for lowly transacted system but inadequate for
    heavy transaction.

    To close these gaps, you need a smart architecture. If you owned a
    buscomp of 100 calculated fields populated with multi-nested iif, this
    level custom declaratives is as destructive as scanning 1000 lines of
    dirty codes. It ain’t smart. The system will eventually become craps
    if scripted rules and vanilla declaratives are all over the bodies of
    Applet and BusComp.

    My framework may not be similar to ATI as mentioned in your
    introduction. Nonetheless I believe they share the same origin after
    reading your ABS series. My version was based on the Siebel framework
    adapted by NASA Ames. Yes, rocket scientists use Siebel. Furthermore
    the one-page documentation (in German) is what I got to start with. I
    was thinking to get it translated by Google and post it here if
    possible.

    ReplyDelete
  3. As with any new technology, there is a learning curve, and you need to factor that into your development time. It took me a few years to understand the difference between a BO and a BC! But delivering a project 99% on time with new technology is quite an achievement.

    You are right, the BO layer is quite deep, but i wanted to keep it simple for all readers. The concepts of OOP and code structure will be covered in the next article: ABS - Code and Language Structure.

    The long lost training notes, are you able to send it to me?

    jason@impossiblesiebel.com

    ReplyDelete
  4. Jason, Good Post !!!

    Thanks for highlighting the benefits of the ABS framework.I can definitely see the advantages of this framework.
    The framework will immensely improve the efficiency as well as the delivery time of any Siebel implementation.

    There is sparse information about this framework on the net today.
    The Siebel world will be greatly benefited if there is an ABS bookshelf detailing the architecture and the usage.
    Once the framework is mature enough and properly unit tested, it needs to be published as a standard library that can be easily leveraged in a Siebel Implementation.

    We are moving in the right direction. Thanks Jason. Keep up the good work !

    Geeksajan
    Siebel Musings
    http://geeksajan.blogspot.com

    ReplyDelete
  5. Siebel is not a development platform. Never need such a framework. Hard to maintain code and also not a best practice.

    ReplyDelete
  6. What's the latest on the ABS/ATI Framework? Is it at all compatible with the ST eScript engine?

    Thanks!

    ReplyDelete
  7. The short answer is YES. It is best to get support from your vendor to upgrade the ABS/ATI framework.

    ReplyDelete
  8. Where I can download this framework?

    ReplyDelete

Comments are open to all, please make it constructive.