Siebel 8 Tab Order defect on Popup applets (8.1.1.1)

We seem to have lots of encounters with Popup applets here at Impossible Siebel

About Record Applet Challenge

Siebel 7 Dual Screen popup

Siebel 8 Dual Screen popup

Conditional Popup based on button click

MVG Popup Challenge

[Another popup challenge]

On the last day before code freeze, the following challenge came through as a critical defect.

The problem in Siebel 8, is that the tab order is ignored on all popup form applets using grid layout (CSSFramePopup).

The tab order still functions correctly in view applets, but on popup form applets, the tab always moves in a sideways fashion, from left to right, no matter how the sequence property is set on the controls.

This may not seem like a huge issue, but for a customer facing staff this can be mission critical. The tab order allows staff to efficiently key in data in a logical sequence, without using the mouse, and if the tab order changes all of a sudden, they have to un-train their old typing habits and adapt to the new behaviour.

This problem was escalated to the Siebel engineers and we were advised that there is no workaround for this behaviour.

This is bad news, especially for customers who have upgraded from 7.8 to find this functionality has been broken.

[Tab Behaviour]

To fix the root cause of this problem, we need to understand how the tab behaviour works.

Is it controlled by class/ActiveX code? or by HTML? or by Javascript/browser script? who knows?

The answer is HTML. The actual solution will lead us to a very obscure part of the application.

When we configure Tab order in Siebel, we need to set the HTML sequence for the control on the applet or use the format menu option. The latter option is disabled in Siebel 8.

When siebel generates the HTML for this control definition, it creates a tag called tabIndex which controls the tab sequence in the browser.

Take a look at the following example, and copy it into a plain text file and run it to see how it works.

<html>
<head>
 <title>Controlling TAB Order</title>
</head>
<body>
<SPAN>
 <form>
   <table border=1><tr><td ><div class=GridBorder>
   Field 1 (first tab selection):
   <input type="text" name="field1" tabindex=1 /><br />

   Field 2 (third tab selection):
   <input type="text" name="field2" tabindex=3 /><br />

   Field 3 (second tab selection):
   <input type="text" name="field3" tabindex=2 /><br> </div></td>
     </tr>
     </table>
 </form>
 </SPAN>
</body>
</html>


The problem is, this particular tag, cannot be inspected by looking at the HTML source, or sniffing the HTML, because the HTML source is the pre rendered content, which contains all the HTML code and Javascript commands that your browser interprets on the fly to create the actual content that you see.

The only way to get at this information is to traverse the DOM tree, and spool out the post rendered structure (which is the true representation of what you seen on the screen).

When i spooled out the HTML that Siebel rendered, the controls were missing the tabIndex, and it was also malformed.

No wonder it didnt work!, this tag was correctly rendered for applets in the view frame, but was not for popup applets.

[The challenge]

Our particular requirement for this challenge, was to only fix one applet, there were a few others which were affected, but given where we were, the business accepted this compromise, because there was likely to be a lot of hard coding.

We need some mechanism to control the tabIndex, i could query the repository to get the control sequence, but it wouldn't be easy to grab this information from Browser script and was overkill in every sense of the word, the alternative, was to hard code the tabIndex references to correspond to the HTML sequence of the actual control on the applet. Not very nice, but it was an idea.

[The solution]

An unexpected treasure appeared, when the post rendered Siebel HTML source was analysed, the malformed tag actually contained the HTML sequence, but it was disguised by an empty identifier and was actually hacked to the back of another attribute. It seemed that Siebel did generate the sequence attribute, but chopped off the tabIndex indentifier required for this to work.



So now that we have the most important ingredient (the tab sequence of all the controls), we can modify the HTML to create the tabIndex property and inject our sequence.

Its easy to access a node, and grab its attribute, but its difficult if the attribute dosnt have a name, so how do you reference some thing that has no reference? It took me a while to figure out, but heres how i restored the Siebel Tab order.

Put the following code on applet load:
var oControl = this.FindActiveXControl("Any Control Name");
var oObject = oControl.document.body.getElementsByTagName("object");
for (var i=0; i < oObject.length; i++)
    oObject[i].tabIndex = oObject[i][""];


What this does, is grab a hold of any arbitary control to gain access to the DOM. We then use this handle to go to the top of the DOM hierarchy, and grab all the tags for the applet controls, and insert a tabIndex attribute, and assign it the value of the un-named identifier.



The final solution involved no hard coding of the sequence or control arrays, nor did it require a server trip to retrieve this information from the respository. So we ended up fixing all the other applets that the business wanted.

This is only meant to be a stop gap solution, and hopefully Siebel will fix the bug soon. Dont hold your breath, but also dont go crazy and put this on every popup applet in the application. This solution is only designed for HI mode and was tested on 8.1.1.1, a SI fix wasnt applicable, and wasnt explored. (Thanks to KW for help on analysing this problem)

ImposSiebel Toolbar, About Label

I had a conversation with some Siebel architects not too long ago, and we were talking about Siebel 6. One of the best things about the interface (probably the only thing that was good), was the fact that, when you hovered over any label on the client, it would reveal the actual BC field name in the application status bar.



This was a golden nugget for developers, because instead of going to the applet, viewing the layout, inspecting the control, scrolling down the properties window to get the field name. Siebel 6 provided this information plainly to anyone who cared to look.

The person who designed this functionality was obviously an engineer, and the person who killed the feature in Siebel 7.0 was most likely a marketing person. Siebel professionals who came from the 10 year batch, will remember this feature, and will be happy to know that i've brought this feature back.

This feature is provided for pure nostalgia, but will not have any practical value anymore and I'll explain why soon.

[About Label]

Rather than borrow design cues from a 10 year old interface, i've come up with something a little more modern.

'About Label' provides the developer with detailed information about the label of any form applet inside a floating window, which can be interacted with to show low level BC information.

To invoke this feature, goto any form applet, and pay attention to the labels. When you hover over a suitable label, the background of the label will change color, indicating that this feature is enabled.



Double click on the desired label to call 'About Label'. A dialog will appear showing the following summary information about the field, if it is available.



Calculated fields will not have mapped columns, VBC fields will not have a Table, and System fields will have no definition.

So depending on the kind of field you are inspecting, the following information is displayed.

1. Field Name
2. Column
3. Calculated Value
4. MVL Name
5. Dest Field
6. Dest BC Name
7. Picklist Name
8. Picklist Type Value
9. Table Name

Click on the toggle icon, and the dialog will expand to show the entire list of configured properties for the field.



And finally the field name will be displayed in the status bar for those Siebel 6 hippies who want to do some reminiscing. Give me a Hi-5 in the comments, if you're a hippie.

[Limitations]

1. List applet support
This feature is sorely missing, but it is a tough one, and requires an overhaul of the current design to work, so dont expect it on your radar anytime soon.

2. Popup applet support
This also requires some new design to work, but consider it a weak bleep on your radar.

3. Home pages/SI mode support
SI support is possible with a little tweak and some further testing, but hasnt been enabled. Consider this one a phantom bleep that might appear anytime soon.

4. MVF Column/Table name
'About Label' doesnt show the mapped column/table name for MVF fields. This is a personal annoyance for me, but i dont have a quick solution, so this will be a future enhancement.

[Whats on the horizon?]

Theres still a few features of "Super About View" that i have yet to port over to the ImposSiebel toolbar. The most notable are listed below.

1. About Script

Displays all browser and server script related to the current BC and Applet in an explorer tree. This is useful to inspect the behaviour behind a button, or action on the UI, without going into Tools.

2. About Applet & About BC

Displays low level details about the user properties, and object properties of the Applet and BCs. This is useful to see why fields are read only, or what user properties could contribute to the UI behaviour.

3. 40 second Repository Search

As the feature title suggests, the Impossible Siebel toolbar can scan the repository in roughly 40 seconds, and display a detailed report on the repository reference to any string, field, applet or view definition. Try this with a standard Siebel full repository search, and you'll hang your tools for a few hours!

This will be the last major release for this year, and mostly likely the early part of next year. I must admit, i skipped some corners to get this release out in time, and also deliver the ABS articles. So i will focus on refactoring the code, and creating object wrappers, so its more scalable for future enhancements.

Although this is mostly under the hood enhancements, the foundations will make the above enhancements easier. But to keep you guys/gals happy, i'll provides some nice easter eggs along the way so you dont get bored with all this stability, and scalability nonsense.

ImposSiebel Toolbar, Version 0.54 Release Information

This is the anticipated version of the Impossible Siebel Toolbar, with the "About Label" feature, which was the winner of our last poll.



"About Label" should be fairly obvious to use (hint, its has something to do with Labels). If you can't figure it out, a follow up article will be posted soon to explain how "About Label" works.

Before you skim over this article, the new XML configuration file is mandatory for the "SQL Profiling", and "About Label" to work. This is required for new and existing users.

[Installation]

1. Existing Users


Managed Option
Under the ImposSiebel Toolbar options, just click on "Refresh
Toolbar"

Bookmark Option
If you are using the server copy, i've already uploaded the new
version.

2. New Users

Follow the instructions in the first article
http://www.impossiblesiebel.com/2009/09/impossiebel-toolbar-beta.html

[XML configuration file]


This new component is critical for "About Label" and other future
functionality to work.

Create a XML file called "ISConfig.xml" with the following contents and put it in the following directory.

C:\Program Files\Impossible_Siebel\
<IS>
       <odbc>
              <source>
                     <dsn>Your Local Siebel DSN</dsn>
                     <username>datasource username</username>
                     <password>datasource password</password>
              </source>
       </odbc>
       <sqlspoolfile>c:\spool.sql</sqlspoolfile>
</IS>

This directory will already be there for users who have opted for the "Managed" version.

[New Features]

1. About Label
This feature provides the developer with detailed information about the label of any form applet.

Keep an eye out for the next article, and i'll provide a tutorial on how to use this functionality.

2. Current Applet and Id
Next to the [IS Menu], i've added dynamic information on the current active applet, and the current Row Id.

When you hover over this text, it will be copied to your clipboard automatically. This is useful, when you have a popup window and want to know its name.

3. Position sensitive "About View", "About Label"
The most annoying behaviour of the previous version, was "About View" only appears in a hard coded position near the top. So if you have a long screen, and try to invoke "About View", you wont see it until you scroll up.

"About View" is now position sensitive to where you double click. This enhancement also applys to "About Label", however other dialogs are still hardcoded.


[Changes]

1. Invoking "About View"

In the previous version, "About View" was invoked by double clicking on any free space in the main view. The term "main view" dosnt really mean anything to anyone except me.

So i've made it more user friendly, by allowing the user to double click on any free space in the application, and this will bring up "About View"

2. Active position/Login information
This information has been shifted from the right of the toolbar to the left

3. SQL Profiler Total Operations

SQL Profiler shows the top 10 operations ordered by SQL cost. There are some cases where you could get thousands of small transactions taking a large amount of resources. In this case the top 10 operations wont reveal the whole picture.

I've added the Total number of SQL operations, so if you have a nasty piece of rescursive SQL, this new information will reveal the proper context of the top 10.


[Fixes]


"About View" Smart Script Crash

Fixed an issue that caused the toolbar to die under a smart scripts
view.



[Known issues]


Cannot establish connection to local database
In Siebel 8, if you are connecting to an encrypted local database, you need to have Tools open at the same time.

You need to open Tools and re-start the client for the changes to take effect.

Server DSN issues
A server DSN can be configured, but it is not recommended because it can be slow. Also the toolbar has only been tested on DB2, and therefore is not guaranteed to work with any other DB vendor.

SI About Label
"About Label" has not been implemented in SI.

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.