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 |
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 codeIf 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 code15 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 memoryBusiness 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/resourcesThe 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.
