Siebel OpenUI performanceLets script again!


1 juni 2016



A lot of Siebel implementations are migrating, or have recently migrated, to OpenUI. Browser support (IE8) is often the main reason for this upgrade. Depending on the Siebel version, the performance of the new interface can vary. With every new Innovation, and Fix Pack, Oracle introduces new performance improvements. Nice performance metrics can be found at the Oracle Implementation Advisor blog. After this technical upgrade, a whole new world of (web) development challenges becomes available. Improving the user experience and extending the integration possibilities with third party web API’s are just a few examples of ongoing OpenUI development. Nice examples can be found in various blogs about Siebel OpenUI. And even more is available when browsing through JQuery examples. But what about performance of these customizations?

I guess most of the new customizations will be performed by experienced Siebel configurators, but relatively inexperienced web developers. Siebel guru’s with a great understanding of the Siebel architecture, massive amount of e-script experience (I’m not sure if that’s a good thing) but relatively new to web technology topics like CSS and JQuery. So I think it might be a good thing to be aware of possible performance wins and losses when writing your own JQuery code.

What are the general factors, which determine the performance of Siebel Open UI?

  1. First of all your browser, and more specific your browser version. After the upgrade to OpenUI, it is recommended to upgrade the browser of your choice to the latest available version as well.
  2. Try to upgrade to the most recent available Innovation Pack (and preferably also the latest fix pack). This will make sure that you will benefit from the latest performance enhancements, UI improvements and solved OpenUI related bugs.
  3. Keep in mind that all JQuery code is executed in your browser. This means that the performance of your local machine (or VM/Citrix client/tablet) has also impact on your overall performance.

When writing this blog, I came across some interesting blogs about JQuery performance quidelines. Hereby I’d like to bring some of these guidelines under your attention:

    1. When using JQuery selectors, use Id’s rather than classes. For example:

[code language=”javascript”]$(“#some_id”);[/code]

Will be faster than:

[code language=”javascript”]$(“.some_class”);[/code]

The main reason for this difference is simple: your code will stop searching when a specific ID is found, while there can be multiple occurrences of the class attribute. Instead of using the JQuery selector it will be even faster to use native JavaScript code:

[code language=”javascript”]document.getElementById()[/code]

    1. Avoid executing the same selector multiple times. Try store it in a variable or, in case of CSS manipulation, try chaining the changes within a single selector statement. For example:

[code language=”javascript”]
$(“#some_id”).css(“color”, “green”);
$(“#some_id”).css(“font-size”, “1.2em”);
$(“#some_id”).text(“Text has changed”);


[code language=”javascript”]$(“#some_ id”).css({“color” : “green”, “font-size”: “1.2em”}).text(“Text has changed”); [/code]

    1. Never change the DOM within a loop. For example:

[code language=”javascript”]
for (var i=0; i<100; i++){
$(“#some_id”).append(i + “,”);};


[code language=”javascript”]
Var html=””;
for (var i=0; i<100; i++){
html += i + “,”;};

  1. Sometimes it is better to use native Javascript instead of JQuery. See also the first example on the selectors. Using[code language=”javascript”]document.getElementById[/code]is much faster than using a JQuery selector.
  2. In general, changing the DOM (your HTML schema) is relative expensive. New JavaScript frameworks, like React, try to solve these performance issues.

More performance guidelines can be found in various JQuery and Javascripts blogs (I’ve listed some at the bottom of this blog). Some may have become less relevant, due to increased browser capabilities or higher JQuery versions. But it is a good thing to realize, that writing JQuery/javascript is a different programming area, than writing Oracle/Siebel eScript. So although a “quick-win” by doing some DOM manipulation may sometimes be tempting, try to keep in mind the possible (performance) impact your code can have.

When writing this blog, I’ve spend some time in testing the different pieces of code inside a custom physical renderer. Although timings proved the above statements, it all came down to milliseconds. Does this mean we shouldn’t care about these syntax differences? In my opinion we should definitely take care, or at least be aware of the different options we have! For the coming years, when writing first customizations, performance may hardly be affected. But after years of building new functionality in custom Javascript files, we might encounter new performance issues due to poor programming. And haven’t we seen this before in the fabulous world of eScript?

Some JQuery performance blogs:

Neem contact met op met Pieter voor meer informatie over Siebel

Kunnen wij je helpen?

Neem contact op met Ebicus via het contactformulier of raadpleeg direct één van onze collega’s om je direct te ondersteunen!

Bekijk al onze blogs