OpenUI – Single Click Sort

Got triggered by an internal discussion with some colleagues, to re-enable a single-click-sort solution. Came up with the below solution, which does work beautifully.

But with to major drawbacks:

  1. It disallows the column ‘lock’ / ‘unlock’ feature.
  2. It still sorts default in Ascending mode, where I’d like to have the option to specificy ‘Descending’ under certain circumstances.

Well – thought, just post the work-in-progress and elicit some feedback from the field (yes, you!). Posted the same sample code also on the OracleSiebel Git repository.

My first focus is on a proper solution that will somehow enable lock/unlock along side the single-click-sort. The path using a dblclick event handler led nowhere, because having two mouse events on the same element is simply no good. I had a quick look at overriding the context menu (right mouse) and instead displaying again the standard sort / lock popup.

Any takers :-)?

if (typeof(SiebelAppFacade.QuickSortPR) === "undefined") {

define("siebel/custom/QuickSortPR", ["siebel/jqgridrenderer"],
function () {
SiebelAppFacade.QuickSortPR = (function () {

function QuickSortPR(pm) {
SiebelAppFacade.QuickSortPR.superclass.constructor.apply(this, arguments);

SiebelJS.Extend(QuickSortPR, SiebelAppFacade.JQGridRenderer);

QuickSortPR.prototype.ShowUI = function () {
SiebelAppFacade.QuickSortPR.superclass.ShowUI.apply(this, arguments);

var placeHolder = "s_" + this.GetPM().Get("GetFullId") + "_div";
var elSortable = $("#" + placeHolder).find(".ui-jqgrid-sortable");
var sort = $("li[data-caption='Sort']");

elSortable.on("click", function () {

sort.parent().css("visibility", "hidden");
setTimeout(function () {;
}, 0);

return QuickSortPR;
return "SiebelAppFacade.QuickSortPR";

– Jeroen


Siebel IP16 – Browser Battle Benchmark

So – how does rendering performance has evolved with Innovation Pack 2016? I have been asked that question a number of times in the recent past. So, I put Innovation Pack 2016 on the rack, measuring Open UI’s response time per usual benchmark approach.

Again, four views with increasing complexity are used. Where really, the complexity of View 4 is ludicrous and primarily meant for stress-testing. In the past IE11 showed a non-linear pattern, that is why I included that impossible complex view.

Those ‘non-linear days’ are over due to largely IE11 specific framework enhancements included in IP15.3/14.9 back in September 2015. Based on my measurements we could say, that Innovation Pack 2016 does a slightly better job compared to IP15.3/14.9. Nothing spectacular. Call it stable.

meta-chart– Jeroen

CSS Performance Debugging…

Most of us would agree that Internet Explorer isn’t a top-notch browser. Neither in supporting HTML5, the bread and depth of its developer tools, nor in performance. Still it’s the browser we have to deal with, because for many enterprises it remains the corporate standard. And let’s be honest, most web sites or web applications render acceptable in Internet Explorer. But matter of a fact is – Siebel’s OpenUI client is not just any web application. It’s quite a bit more demanding than the average.

The situation I got confronted with recently at one of my customers, was their Siebel Marketing Gantt Chart did not perform at all on IE11.It was actually that bad, that the Gantt Chart not only loaded terrible slow – but once loaded it more or less hung the browser all together. Making even developer tools merely impossible to be used. Interesting was that just looking at task manager, the iexplore.exe process would consume near full CPU as well as a humongous amount of memory (growing up to 1.5GB). It took up to 30-40 seconds to show the Gantt Chart. The number of Programs and Campaigns to be shown around 250, driven by the default PDQ.

And of course, it behaved just fine in Chrome and Firefox. Although loading the Gantt Chart was not spectacular fast neither.

Well now, the Gantt Charts which can be found in different Siebel Applications have always been a highly specialized feature. That was true for the High Interactivity client, but as much so for the revamped version in OpenUI. Siebel will pull down from the server a seriously large DOM, largely dependent on the number records filtered by the default Predefined Query.

My initial analysis was focused on the PDQ, because regardless of the selected time-scale the SQL would not contain any signs of filtering based on a date-range. Something I’d have expected. For example if today is May 16th 2016 (which it happens to be, at time of writing) and the time-scale equals  ‘D/H’ (= Days broken down by Hour) and the number of ‘pages’ to retrieve would be ‘3’ – why would the Gantt’s underlying business component query not add a date-range in its WHERE clause?

A bit more on the notion of ‘pages’. Gantt charts have an applet user property named Duration for TimeScale LIC. Bookshelf writes about it:

Specifies the number of days that Siebel Open UI sends to the cache for each time scale. For example, the following value specifies to send seven days of data to the cache for the Week/Day time scale: 1:7.

The first parameter ‘1’ signifies the ‘Week/Day’ time-scale. If you’d query list of values where Type = ‘TNT_SHM_GNTAX_TIME_SCALE’ you will find the matching integer representations for the different time-scales.

timescales_defThe second parameter ‘7’ means that in total 15 pages are being rendered in the Gantt chart. Today, 7 days ahead of today and 7 days after today. I found this configurable parameter having no relationship with the number of records which are actually being returned to the client. It just means that infinite scrolling (using the horizontal scroll-bar of the Gantt applet) re-submits to the server a new request, after which the view refreshes. Looking at the detailed log traces, you will see exactly the same SQL is executed and exactly the same number of records are fetched. Kind of weird, isn’t it? Let is sink in a bit.

Anyways, end effect is, that even with the D/H time-scale activated and although for only few of the roughly 250 ‘Active’ or ‘In Planning’ rows (Campaigns or Programs) it would make sense to show them in the Gantt – they still are returned to the browser. Creating an IMHO unnecessary large DOM. In the customer case > 1.5 MB.

And exactly there is, where Internet Explorer starts to choke. A large DOM. After doing some due-diligence using Chrome’s profiler – IE was really choking – I identified the likely root-cause to be in pure rendering.


At the same time, Oracle Support was actively helping to analyze the root-cause too. And they came with an interesting finding. Although I first was not inclined to belief it. It appeared to be related with the Simplified UI theme. Where initially Support was reproducing using Aurora, my customer was using the Simplified UI theme.The relationship of the issue with the Simplified UI theme got confirmed!

That brought us at an interesting junction. It was frankly quite clear by now that the root-cause was to be related with one or another offending CSS rule. And surely, IE does neither have a strong Javascript engine – it’s CSS engine is as outdated too.

But how on earth to compare Simplified UI with Aurora and tell what selector/rule would cause the havoc?

I went on a nitty gritty trial-and-error route. And it was not a nice one. I had to use IE, since it only reproduced in IE. But instead of using Siebel I opted to use JSFiddle (if you’re interested you can have a look at the JSFiddle here).I took the raw and integral DOM from Siebel + the complete theme theme-sui.css. And next ran the JSFiddle in IE. Issue reproduced immediately, but at the same time IE Developers tools was just ‘responsive’ enough to work with. I started removing parts of the DOM to see if the issue could be isolated further. And yes, it appeared the issue was related with say the re-sizable ‘left-hand’ side of the chart where it shows the name, status and so on of the campaigns and programs. If I removed it all together, immediately I could freely without much delay scroll up and down the Gantt.

Alright, what next? Visual inspection and more manual labor. I just went through the offending part of the DOM (or better the part of the DOM which triggered an offending CSS rule). Just to understand, what the triggered rules where all about, and which rules could potentially trigger on many elements. Simply by counting in Notepad++ the number of occurrences of certain classes, not having a better idea. And that did lead to identify the problem quite quickly. It appeared that the class ‘ui-resizable’ occured > 3500 times in the DOM. And guess what? that rule neither exists in the out-of-the-box theme-aurora.css.

hanging_marketing_calendar_IE11_CSS_CauseAn interesting journey, to say at least!

I’m looking for any pointers which could have made life easier? I have been Googling for any tools which could help in pinpointing offending CSS rules. Found none. It appears that even Google dropped their wish for a  detailed CSS profiler feature, because they feel nowadays it’s not real concern in their own top-notch browser anymore. Not so much can be said for IE…

– Jeroen