Oracle Started Supporting Virtualized Platforms For Siebel (But Silently)

In the past days I have been visiting a couple of my customers together with our product marketing lead for Siebel Open UI. A great opportunity and time to discuss lots of top-of-mind topics ;-)

One really interested piece of information, which I missed out on until this week, is that Oracle silently started supporting server and client virtualization platforms. Certify will be further completed soon, but practically your VMWare Hypervisor should be at least ESX 4.x or above. ESX 3.x was known to cause scheduling issues for multiple vCPU virtual machines running Siebel Servers.

Besides server virtualization, also expect soon to see Citrix appearing on Certify.


Today virtualization is only added to Certify for Innovation Pack 2014. And the support message does still come with certain constraints.

The My Oracle Support DocID has been updated:

Virtualization Technology Support in Siebel Environments (Doc ID 1307968.1)

Oracle allows any type of virtual technology to be used with Siebel because, running at a layer below the operating system, it is transparent to the Siebel application.  For the same reason, Oracle does not test Siebel products with specific virtualization technologies.

Oracle makes no recommendation on the use of virtualization technology with the exception that virtual environments need to be appropriately sized.  Each virtual environment must meet the requirements documented in *MOS Certifications.  Customers should consider scheduling a deployment sizing review with their Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services.

Oracle is under no obligation to make changes to Siebel software in order to accommodate any virtualization technology product, and strongly recommends thorough pre-production testing when running server and/or client applications in virtualized environments.

– Jeroen

Microsoft Is Killing Off The Internet Explorer Brand (but really?)

It certainly will not be an easy journey for Microsoft to really leave Internet Explorer behind. Especially not as long as it will ship with Windows 10 for enterprise customers. And the next question is about actual support. Given the fact that Microsoft has stated last year it will only provide mainstream support for the most recent browser available on a given platform. So will the message that Internet Explorer lives on further on Windows 10 for enterprise customers be a carrot or actually a stick? Since most enterprise customers are using Internet Explorer for two primary reasons: one being (perceived) security, the other one being (perceived) support, one should scratch its head about that.

That said, I like the subtle subtitle the Verge put under the article:

IE will live on, but only as plumbing for Windows

– Jeroen

Siebel IP14 – PS4 Has Some Performance Tricks Up Its Sleeve

A few posts back I reported about Microsoft to release a performance fix for Internet Explorer 11. Tonight I completed my initial tests with the Siebel Innovation Pack 2014 Patch set 4 which Oracle released a couple of weeks ago. The Patch Set 4 release notes make note of two particular bugs which should improve OpenUI view rendering performance. So I picked up the glove and executed my usual set of performance review scenarios. I compared Patch Set 2 against Patch Set 4, for the usual set of browsers. I ran each test three times to cancel out any measurements which could have a (too) high standard deviation. The cool thing is that the performance measurement framework does all the heavy lifting for you. Duncan discusses this simple but very effective framework in the Open UI Developer’s Handbook too.


Bottom line? All browsers benefit from the Patch Set 4. IE11 benefits most. But still IE sits all alone silent in corner. Internet Explorer – despite the performance hot fix being applied – remains no competition for Chrome and Firefox.

IP14PS4PerfCompAgain Chrome outperforms all, with significant improvements. These improvements alone should make you to consider Patch Set 4 strongly.

– Jeroen

Siebel IP14 – Enance Checkbox Behavior using Control Plugin-wrapper

A couple of previous posts have already demonstrated the good use of the IP14 Control Plugin-wrapper framework. Today again another simple use-case to demonstrate its potential.

In Open UI it turns out that selecting (or better changing) the value of a check box can be cumbersome. Especially if you want to quickly modify its value in a list applet. Form applets are just fine. Most important of all you need to quite correctly point your cursor on a relatively small area. Further the element containing the check box needs to have focus too, before you can change it.

Experimenting a bit I created a new control plugin-wrapper.


Of course starting-off some solid boiler plate code…!

Implementing the AttachPW event

The usual set-up of a PW requires the implementation of the AttachPW event. This event basically defines for what type of control such as a Dropdown, MVG or Link it should act upon. From the Bookshelf you can get the available controls including the constant value Siebel works with internally. For a Check box this appears to be “SWE_CTRL_CHECKBOX”.

The AttachPW conceptually acts like a bouncer in a bar. It decides if the control’s behavior will be overridden or not. The bouncer will return true, what will make the PW control events to execute. By returning false, well nothing will happen.

PWCheckboxFrom a development perspective, creating plugin-wrappers should be considered carefully, since they could have a widespread impact. A simple typo or a statement which throws an (unhandled) error could make your whole Siebel application could be negatively affected. Further, since the effect of a plugin-wrapper is more or less global, we should refrain from too heavy or process-expensive code.

The AttachPW event allows us to prevent execution of override code, in case this is either not required or would potentially not work at all given the context a certain control type is rendered within.

In this example, I just bluntly return “true”, it passes.

Implementing the ShowUI event

Next, the actual code. All within the ShowUI event.

To get the control’s element is simply done by using the GetEl() method on the object. Following that we need to find the gridcell in the list applet to which the Check box is tied. By testing whether we actually received a value element we select upwards the DOM the closest gridcell.

If that results in a valid element, we can attach a double-click even to it. Whether you use JQuery style or otherwise to bind an event to an element is irrelevant. I opted for JQuery style.

Finally, to make things not more complicated than necessary, I simply simulate and end-user click, again in JQuery style. For that one can use the “trigger” method.

The Out-of-the-box Siebel code will process the event further and “Bob’s you uncle”!


Enjoy and grab the full content here.

– Jeroen

Get your “free” copy of Oracle’s Saas for Dummies now

Oracle published under the “for Dummies” label a free-to-download eBook. Free? Well, it requires you to leave your business details. Click here to open the campaign page! And… this campaign is powered by Eloqua, part of the Marketing Cloud :-)

SaaS for Dummies, is designed to share everything there is to know about SaaS-in the light-hearted, engaging style that’s synonymous with the ‘For Dummies’ brand.



And no marketing campaign without Youtube content :-)

– Jeroen

Siebel IP14: Double-Click for Pick and Shuttle Applets

Update Feb 27th – Double-click issue on MVG resolved :-) Added the new physical renderer to the bottom of the post.

I’m sure that most among us have been double-clicking on Pick Applets in Open UI trying to select a record and close the applet. Well, like it used to work in the old days. In these new days this (still) isn’t a boxed feature unfortunately. But who knows what future Innovation Packs will bring to the table… That said: it was so annoying to me, I decided to spent some time finding a solution.

Approach – Extending the Default List Renderer

For Pick Applets I was done within half an hour or so. I found that Popup Applets like Pick Applets and Shuttle Applets are based on the same JQ Grid Renderer class, as regular List Applets. I started by extending the out-of-the-box Physical Renderer for List Applets. You might not know, but within Manifest Administration you will find a number of record if you query for Type=Applet and Name=DEFAULT*


Extending the Default List Renderer means a global change to the application. That said, solutions like these come with a warning: be careful. A simple typo could have wide-spread effects. Plus, since all of the code would be executed pretty much anywhere in the application where List Applets are used, it also means to consider very well if such a global impact would be wise.

Given the warning, this is how I went about. First step as always is to create a piece of boiler plate code to start with. Really, this should always be your starting point. I named it “DefaultPopupListDblClickRenderer”, could have been shorter, but it explains more or less what it’s about.

Since I like the option to enable/disable functionality through Manifest Administration, I tend more and more to use simple Manifest Expressions such as:


Next I added the boiler plate code and tested if it got successfully downloaded. The boiler plate code does include some basic logging for the different events, which is useful to test whether the code actually gets executed or not.


Well, the boiler plate code was working just fine. So I added just added in some basics. First getting the FullId of the Applet and additionally a debugger statement. Adding the debugger statement is a feature I often use, because it enables one to use the console to test any JQuery selectors for example. Very, very useful.

var pm = this.GetPM();
var placeHolder = "s_" + pm.Get("GetFullId") + "_div";
console.log("placeHolder: " + placeHolder);
var that = this;

So next step was to identify using Inspect Element what the DOM looks like when a Pick Applet gets displayed. If we would know how to identify an element to which we could bind a double-click event, we would be one step further. This went down pretty smooth ending up with the following code snippet:

$("#" + placeHolder).find(".ui-jqgrid-view").dblclick(function() {
     if ($("#" + placeHolder).find(".AppletStylePopup").find(".siebui-icon-pickrecord").length > 0) 
        that.GetPM().ExecuteMethod("InvokeMethod", "PickRecord");

To isolate the double click event once it fires from regular list applets, I found that every Popup would carry a “.AppletStylePopup” class a bit down in the DOM, so I added the conditional statement to isolate the event. Final step was simple, just invoke the “PickRecord” event against the applet. Job done!

Guess what? Works flawlessly.

I got in a good mood, and though about extending the functionality towards Shuttle Applets too. These are also Popup Applets, but a special kind. It took a bit more effort plus collaboration with Duncan Ford.

As we know a Shuttle Applet consists out of two applets. The left side is an Association List, the right side is a MVG. Idea would be that a double click on the left side would “add” the record to the MVG and vice versa. Simple enough.

It appears that the Association List is carrying a specific Id of “#sieb-ui-popup-mvg-available”. Great. So traversing a bit further down the DOM you would find the actual list carrying the class “.ui-jqgrid-view” to which we should bind our double-click event.

Next it appeared that solely using GetPM().InvokeMethod(“AddRecord”) did not work flawlessly. Yes, it would add the record to the MVG. But the state of the Association List got inconsistent. Having the AddRecord invocation being directly followed by an ExecuteQuery does the job just fine.

$("#" + placeHolder).find("#sieb-ui-popup-mvg-available").find(".ui-jqgrid-view").dblclick(function() {
    that.GetPM().ExecuteMethod("InvokeMethod", "AddRecord");
    that.GetPM().ExecuteMethod("InvokeMethod", "ExecuteQuery");

Finally removing a record from the MVG! It works very well using the same approach taken for the “AddRecord”. The Element to look for is the #sieb-ui-popup-mvg-selected and then again the .ui-jqgrid-view class, as such:

$("#" + placeHolder).find("#sieb-ui-popup-mvg-selected").find(".ui-jqgrid-view").dblclick(function() {
    that.GetPM().ExecuteMethod("InvokeMethod", "DeleteRecords");
    that.GetPM().ExecuteMethod("InvokeMethod", "ExecuteQuery");

Given the few lines of code, I feel the benefit is there :-)

You can grab the code here.

– Jeroen