Showing posts with label Defect. Show all posts
Showing posts with label Defect. Show all posts

Find Results Highlight defect

1. Log into the Application through thin client
2. Click the Binoculars
3. Choose a search category
4. Enter a search criteria
5. Click Search

The search results should show the selected record with a highlighted background as shown in the screenshot below. This feature worked in 7.8 and broke when the application was upgraded to 8.1.

Note: This issue only occurs on the thin client and cannot be replicated via the thick client.

The Find pane is rendered in SI, so the row highlighting has to be controlled by CSS and the class tag. To verify what is happening right click on the Find pane, view the source code and identify the section that has the Find results.

We can see that the class tag is missing the class name, this is why the highlighting does not work. Is the server not generating a class or is the swe command for active row highlighting broken? To get to the root cause, we need to go to web templates that is used to render the HTML before it is sent to the browser.

Goto your Web templates folder, locate and open the following file


The swe command that is responsible for determining the class is
<tr class="swe:this.RowStyle">

According to the Siebel documentation, this is the correct command, but the Application does not correctly render the class tags.

To work around this feature, we can utilise a swe switch statement to detect the state of the web engine, and the print out the correct class tags for our rows. Heres how its done.
<swe:case condition="Web Engine State Properties, IsCurrentRow"><tr id2='JLEOn' class="listRowOn"></swe:case>
<swe:case condition="Web Engine State Properties, IsOddRow"><tr id2='JLEOdd' class="listRowOdd"></swe:case>
<swe:case condition="Web Engine State Properties, IsEvenRow"><tr id2='JLEEven' class="listRowEven"></swe:case>
<swe:case condition="Web Engine State Properties, IsErrorRow"><tr id2='JLEError' class="listRowError"></swe:case>


There are 5 available classes


If you want to change the styles of these classes, they can be found in the main.css

Notice that I add a custom id2 attribute to the row tags for testing, this lets verify the change on the thick client, since the original swe command and the new switch statement will generate the exact same output, we need something to tell us that we have modified the correct SWT file.

Enjoy your new old feature again.

Set Tab layout order defect

Last year i looked at a Siebel feature that prevented tab orders from being adhered to on Popup Form applets.

This was tested in, but under, this solution dosnt work anymore. The background on this can be found here.


The root cause this time around, is just as obscure but with our background on this problem in, the reason why it is broken in, is more easily identified.

If you recall from last time, Siebel generated the HTML Tab index in the browser source code, but failed to provide it with an identifier.

In, Siebel dosnt generate the tabIndex property or its value at all, so the solution i'm about to provide is a going to be another UI hack.

Although it is not as elegant as the last solution, it has the advantage of being backwards compatible and should be quite future proof.


Since Siebel dosnt generate the HTML Tab index anymore, we need to find a way to make this information available to the browser. To be thorough, you should turn on all the hidden properties in Tools, by setting this option in your tools configuration.

ClientConfigurationMode = All

After that exercise, i've found that only the Height/Width properties work. So we are going to pick one, and for this example i'm going to use the control height property and ask that developers populate that with the desired HTML sequence.

When Siebel renders the controls on this applet, it will be stretched out of proportion, because we used the control height property as our HTML Sequence indicator.

To get around this problem, we will manipulate the DOM on applet load and inject the tabIndex property, with the height value that we have configured above, and at the same time restore the height to the standard 24 pixel, for all the field controls on the applet, before the user has a chance to see it.

Heres how its done, copy the following code and put it into your browser applet load.

fixTabOrder8112(this,"any valid control name");

function fixTabOrder8112(that,ctrlName)
try {
var oControl = that.FindActiveXControl(ctrlName);"none";
var oObject = oControl.document.body.getElementsByTagName("object");
for (var i=0; i < oObject.length; i++){
oObject[i].tabIndex = oObject[i]["height"];
oObject[i].height = "24";
} catch(e){
} finally {

If you look carefully, you'll notice that i hide the entire contents of the applet, ensuring that all the controls are invisible while the code re-draws all the controls, and re-displays the content when the routine is finished.

You may or may not notice a small moment of flicker as the applet is being worked on, but it should be un-noticable. To get a second opinion, I asked a BA to watch it in action and watch out for the flicker, and when it was over, she stated "I didnt see any flicker!" If you are testing this, try it out on both thin and thick client to see the behaviour.

This will work for the majority of cases, but if you have a Popup form applet with varying control heights such as text areas, then you have to work a bit harder to get this solution to work.

The basic idea, is to append the HTML sequence to the end of the height property, split the values to get your separate properties values and use the above method to alter your HTML source.

The original defect was discovered in, and i was told a fix was pushed for We have discovered that it is still outstanding, and has also broken our fix for, but customers who are still suffering from this defect, now have a new solution.

Close Task Pane Automatically [ID 781860.1]


In Siebel 8, when a Task Based UI (TBUI) session is completed the task pane remains open, displaying the default task (which could be totally unrelated to the current view), even after the user clicks Submit.

This problem has been raised by the customer of Support Document [ID 781860.1] on Metalink. The customer was told that this behaviour is hard coded and to contact Expert Services.

I dont know if there was a solution provided to the customer, because the document was never updated, but this defect would have problems passing User Acceptance Testing (UAT)

[Toggle Solution]

At first glance, an easy solution would be to hijack the method behind the X button, and invoke it from browser script, but since it is not a documented API, it should be a last resort.

TBUI can be invoked by Ctrl+Shift+Y , which fires a menu command and invokes a Business service to toggle the task pane.
function closeTBUIPane()
var BS = theApplication().GetService("Task UI Service (SWE)");
var inputs = theApplication().NewPropertySet();
var outputs = theApplication().NewPropertySet();
outputs = BS.InvokeMethod("ToggleTaskPane", inputs);

This would be the ideal solution.

The business service that we are interested in is "Task UI Service (SWE)", it has the following methods

Open,Close and Toggle

The Open,Toggle methods work fine, but the Close methods seems to be disabled. It seems like when Siebel first designed TBUI, they used seperate methods to open and close the task pane, but in the end Siebel replaced it with the Toggle method.

Although we can use Toggle to close the TBUI after the user clicks Submit, but if, on the chance that the user clicks the X button on the task pane in the middle of the task (therefore closing the pane) when the user reaches the end of the task, clicking the submit button to finish would activate the Toggle method and re-open the pane.

Unless we have someway of detecting if the task pane has been already closed and not perform the toggle, this method may not be acceptable. The only way i know of detecting the state of a pane is to check the existence of the frame by using unsupported browser methods, which takes us back to our first solution.

[X Button Solution]

The following line of browser allows us to tap into the method behind the X button, and invoke it from our TBUI applet.

Another problem that we'll face is the Next, and Submit buttons are actually the same physical button that call the same method, TBUI will dynamically change the label of the button depending on what view the task is on, which makes this a little trickier.

There are two solutions to this,

1. Make a clone the TBUI applet and use this clone exclusively for the Submit button and put it in the final view

2. Reuse the vanilla TBUI applet and use browser script to read the button text and decide wether or not to close the task pane

The use of undocumented browser methods is not something i would normally recommend, but until Siebel provides a proper fix, this workaround provides customers with a solution that would not cripple the system if the method becomes deprecated.

The worse that can happen is you revert back to the product defect, the upside is that your application dosnt confuse your users and passes UAT.

EAI XSLT Service namespace limitation

If you've ever tried to use EAI XSLT Service to transform a XML message with more than 30 namespaces, you will get the following dreaded error.

"(xsltransform.cpp (564)) SBL-EAI-04267: XSLT Processing Exception: SAXParseException: An exception occurred! Type:RuntimeException, Message:The buffer manager cannot provide any more buffers"

Googlers will find this information useful, because this error is not documented on Support web, and unless XML is prolific in your Enterprise, you are not likely to run into this problem.

[Root Cause]

Since Siebel is a packaged software, it is not well known that it uses the Xalan 1.5 engine to transform our XML, but this fact can be verified by the existence of xalan-c_1_5_0.dll in the Siebel Tools/BIN folder.

A quick search of the web seem to yield no problems with namespaces with this XSLT engine, so its up to us to dig further into this problem.

If we start by isolating the Xalan component, and see if we perform the XSLT transformation directly using the Xalan DLL, we can test for this namespace limitation and determine if this is a Siebel or Xalan problem.

You can still find the Xalan 1.5 engine on the web; if you want to try it out, go over to the Apache website and download it from the archives.

Finding a Xerces parser compatabile with this engine was more of a challenge, since Xalan 1.5 is obsolete, no archive is kept of the parser.

After 15 minutes of fruitless searching, it occurred to me, that i can use the Xerces DLL from the Siebel directory.

[XSLT transformation with Xalan]

1. Download the Xalan 1.5 binary from Apache.Org
2. Extract the ZIP into any directory
3. Goto your Siebel Tools/BIN folder and copy the xerces-c_2_2_0.dll to the Xalan release folder
4. Supply a XML file with more than 30 namespaces
5. Supply a XSLT file
6. Run the transformation

If you've followed the above steps, you should get the following error.

Bingo!, its the exact same error that we recieved in Siebel.

This is very interesting, so does the problem still occur with the latest version of Xalan?

I used Oxygen 8.2 which comes with the latest Xalan 2.7, and it passed the 30 namespace test.

So we can confirm that this defect is caused by the Xalan 1.5 engine (Oracle engineers take note).

But since this engine is a core part of the product, dont bet on it being upgraded any time soon. Defects in the core Siebel product cannot be easily fixed, so what options does the hapless customer have?

1. [Reduce namespaces in XML]

You can try requesting for your Enterprise to reduce the number of namespaces that is sent to your Application, although this is out of your control, it is worth trying.

2. [Strip out the unused namespaces before transformation]

The idea is that you pass your incomming XML message to a BS utility to strip out the un-needed namespaces, and pass it to the EAI XLST Service for transformation, ensuring that it has less than 30 namespaces.

The above two methods have the following advantages
1. Can be implemented quickly
2. Has very little impact to testing

but it has the following disadvantages.
1. Not scalable
2. Namespaces can change adding to maintenance
3. All namespaces may be needed
4. Different namespaces may be needed for different messages

3. [Use external transformation engine]

An alternative is to replace the default Siebel Xalan engine and use an external transformation engine.

This allows us to bypass the limitations of the standard EAI XSLT Service, and it also provides us access to a more modern XSLT parser.

To achieve this, Siebel provides us with a few mechanisms to extend vanilla functionality by calling on external code.

1. SElib.dynamicLink
2. EAI DLL Transport
3. Java Business Service (JBS)

Although we can use any of the above, methods to call external code. I'll look specifically at using a the JBS option to workaround this product defect, because all the tools and software needed are free and open source.

Using a JBS to call a more modern XSLT parser, will allow our transactions to be more efficient, as well as offering the latest methods available in the XSLT standard.

This is exciting stuff so put that holiday on hold, until this comes out.

Siebel 8 Tab Order defect on Popup applets (

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.

 <title>Controlling TAB Order</title>
   <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>

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, a SI fix wasnt applicable, and wasnt explored. (Thanks to KW for help on analysing this problem)