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*

DefaultListRenderersMA

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:

ManifestExprDblClick

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.

DefaultPopupPR

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;
debugger; 

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

Siebel Open UI: Microsoft Released IE11 Performance Patch

Maybe some of you have followed last year my performance-benchmarking endeavors for Siebel IP13 on Chrome, Firefox and IE11.

Which turned out that IE11 was miserable failing to match the performance from its rivals. Unfortunate, because still within enterprise environments it is a very common browser.

Because several larger customers have reported and escalated this issue, Microsoft has taken the glove. It has resulted in a (first) fix. Oracle released this week a document on My Oracle Support:

Complex view performance fixes for Microsoft Internet Explorer 11. (Doc ID 1944035.1)

The document explains:

Open UI uses name based querySelectors to render UI’s both in code written by Oracle and third parties. Name based querySelectors do not perform well in Internet Explorer 10 and 11 as compared with other browsers.  Lag caused by slow performace is magnified in screens with complex applets, large list views and high number of applets. This can result in up to 30% performance degradation for complex views. This is related to poor performance of name based querySelectors in Internet Explorer, which are prevalent in the Siebel user interface for Open UI.

What this means:

Siebel OpenUI as we know uses the JQuery framework to make the application to work across browsers. Which is good. But in the “Siebel World”, the HTML generated is pretty dynamic and Siebel assigns values to element id’s which are not fixed, but like “s_1_1_53_0″. These can change when the UI changes after a compilation. So elements really cannot be selected by using GetElementById() which is common in web development. Instead we use a lot of JQuery selectors, to identify elements based on other attributes, often the class attribute.

The document mentions a possible 30% improvement. Although I have seen in my benchmarks that even in standard and straightforward Siebel views, IE11 was lagging FF and Chrome easily by 30%. For complexer views this quickly became a factor 2-3. So my hopes here are not that high.

But I have not laid my hands on the fix yet. It will take a bit more time to come to a real first conclusion. Nevertheless I am happy MS picked up the glove, but also hope that it will not stop here.

And apparently Microsoft is open to discuss with customers the option to backport the fix to IE10 as well. Not sure whether that be realistic or not. That said, still a large number of enterprise customers is stuck on IE10. So it would be a nice gesture from Microsoft.

The patch will likely become available per March patch update for Internet Explorer. Customers can request the hotfix in advance.

- Jeroen

Oracle is quietly becoming a cloud giant?

Two recent articles on Oracle’s progress in the cloud business underline that the long-term strategy seems to be taking off with a profitable margin. Although it yet remains only 5% of Oracle’s overall business.

  1. CNBC’s Ari Levy: Oracle’s cloud gains momentum, says analyst
  2. Network World’s Andy Patrizio: Oracle is quietly becoming a cloud giant

How one would consider the comparison of Oracle and SFDC is another story. Can one compare Oracle which offers an enormous variety of cloud solutions which besides SaaS also include IaaS and PaaS with SFDC? The Oracle published figures are missing granularity so, you could say these analysts are not comparing apples and apples.

That said… Just some quotes :-)

“Its cloud business is now half the size of Salesforce, and the gap is closing quickly”

“Oracle is pulling off a minor miracle”

“Oracle’s cloud gains momentum, says analyst”

“…an outperform rating on the stock and a $48 price target, 11 percent above Monday’s closing price of $43.40…”

“In the latest quarter, sales in the cloud business increased 47 percent”

“Considering Salesforce reported $2.2 billion in revenue in 2012, $3 billion in 2013, and $4 billion in 2014, it will likely come close to $5 billion this year. However, unlike Oracle, Salesforce is also bleeding money”

– Jeroen

navbuttongs

Siebel IP14 – Glyphify those navigation buttons please

Some recent posts by the Siebel Hub and SimplySiebel have discussed the option to change glyph icons in Siebel:

In this article I discuss the approach to change the pretty awful and tiny navigation buttons in the standard application. The buttons are so tiny you almost need spectacles to see them. Not to mention to click them. Initial thought would be to increase the size of the static image, but the image appears to be a CSS sprite. Not being a true web developer I only remembered the term “sprite” back from the days I was coding Basic on my C-64.

orignavbuttons

It turns out to be really straight-forward in this case too, to change these navigation buttons to glyphs. Just a couple of lines CSS. I went to IcoMoon to create a completely new custom font. This tool really is great. You can create your own font set containing a selection of selected glyphs.

I selected these fonts to act as navigation buttons.

navglyphs

On the IcoMoon site you select these fonts, and hit “create fonts”. At this stage you already see the hexadecimal address which uniquely identifies the glyphs.

icomooncreatefonts

Once you download, you get a nice zip archive contains the fonts, and as a plus also a demo page which again shows you the glyphs inside and their unique hexadecimal addresses.

zipfolder

The demo page is a good to save along side your actual fonts. So one week later, you will still be able to see what fonts you put inside the collection :-)

demofontpage

Now, the next step is to identify the classes to override and to generate the necessary CSS. First create a font-face which loads the newly created fonts. I named the fonts respectively siebelnavicons.eot, siebelnavicons.svg, siebelnavicons.ttf and siebelnavicons.woff

fontlist

The font-face definition I just copied from the standard theme-aurora.css.uncompressed. There is one “gotcha” here. The url needs to go two levels down (“../../”) because I put my custom CSS in the /enu/files/custom directory. Where as the theme-aurora.css is located in the /enu/files directory. Anyways, that was quickly spotted in the browser console.

cssfontfam

Next the meat. Two points to mention in particular. First is that I could not find a descent “back” button. So I choose to flip it. Second is that styling for two additional navigation buttons got added too. Those are “move to first record” and “move to last record”. These buttons will mimic the traditional HI behavior where you could draw the vertical scroll bar all the way down to the bottom in order to move to the last record.

cssnavbuttonrules

By only putting the styling in here, nothing happens. For that we need to override the Default List Renderer. Really, the best way to start with any OpenUI presentation model, physical renderer or control plug-in wrapper should be boiler plate code.

First we need to inject the HTML code which creates the placeholders for the buttons together with their own distinctive class (ui-icon-seek-top respectively ui-icon-seek-bottom).

NavButtonsPR1

Then code to actually Invoke the methods.

navbuttonspr2

Finally, the stuff we just created needs to be administered to have it being loaded.The CSS should be added to Type = Application, Usage Type = Theme. To override the Default List Renderer you have to create a seperate entry for Type = Applet, Usage Type = Physical Renderer and Name = DEFAULT LIST APPLET. As per below.

navbuttonsmanifest

The end-result should look like this. And of course you can select you own glyphs if you find these a bit too dodgy.

glyphnavbuttons

The things you need can be grabbed here:

  1. Style sheet
  2. Physical Renderer
  3. Navigation glyphs font

Thanks to Duncan for this solution.

– Jeroen

Siebel IP14 – Multi-row select in non-touch mode

My attention recently got drawn by the feature to select multiple records when you run Siebel OpenUI on a tablet. Traditionally selecting multiple records is done using either Control or Shift, but that method does not translate to “touch” devices. Would this feature not be a blessing in some scenarios on the desktop too? I thought so, so I went reverse-engineering to see if it were feasible.

To come to the final conclusion that… this is actually documented functionality, which can be enabled on specific applets using a user property. See below.

multiselectdesktop

This feature got hidden pretty well in the documentation though. One would need to read through the chapter “Creating and Managing Client-Side Controls” to bump into “Configuring Client-Side Multi-Select”. It tells you…

Siebel Open UI uses a client-side control implementation to display a Multi-Select checkbox column in list applets. While this is primarily intended for touch-based devices where multiple selection of rows is not possible using the Shift + Click or Ctrl + Click, it can also be configured for desktop browsers.

The Multi Row Select Checkbox Display user property controls the behavior and availability of the client-side multi-select checkboxes. The property can have the following values:

  • TOUCH-HIDE. The multi-select column does not appear on touch devices.
  • TOUCH-SHOW. The multi-select column appears on touch devices.
  • NONTOUCH-HIDE. The multi-select column does not appear on desktop and non-touch based devices.
  • NONTOUCH-SHOW. The multi-select column appears on desktops and non-touch based Touch devices.

Voilá. By the way, for this applet user property you do not need to configure the ClientPMUserProp. I found though that the selector column does behave quite sensitive. If you have selected multiple records and accidentally click an already selected record again, you will loose your selection. That said, the feature has typical use-cases which would benefit and where it behaves more user-friendly then using Ctrl + Click.

– Jeroen

Siebel IP14 – Popup editing Text Area controls (the sequel)

A while back I blogged about a solution to enable pop-up editing of Text Areas in Siebel IP14, using the Control Plugin wrapper framework. Well, it had some rough edges.

At that time I only tested the code exclusive on Form applets. One of my customers asked (because it apparently did not work on List applets) to enable it for List applets too. Why it did not work flawlessly on List applets, is that specifically text area controls behave different. Back in December I found already that on Form applets, Siebel injects a <span> once you click on a Text Area control, which did not work very well with the Popbox library.

While discussing this yesterday wit Duncan Ford, it resulted in a refactored solution. Factually a simpler, more elegant one which can be styled appropriately. And which works for both Form as well as List Applets. It behaves as a modal dialog. Selected event is the double-click on the Text Area control. This way if you want to can still use the Text Area control as-is.

.
Further, what got added is a little transient tool-tip (well, not a real one) to tell the user he might want to double-click on the control. Probable this will start to get annoying soon, but it might help as matter of change management support. The tool tip will only show once within a given view. That means, if you navigate to a view and hoover over a text area control it will display the (yet hardcoded) string. Once you have hoovered accross, the PW injects an attribute, such that the next time the “mousenter” events fires, it will not show the transient tool-tip again.

popfade

This piece of the code is responsible for managing the transient tool-tip. Important piece is the conditional statement to check wether this.GetEl() returns an object. It appears that the PW also fires for the header row of a list applet, in which case though GetEl() is an empty object.

popupareacode1

The code responsible for showing the actual JQuery dialog. The JQuery dialog is passed its own class so it can be styled accordingly. Important of course the type of the dialog is shown as a Modal one, so one cannot navigate around.

popupareacode2

You can grab the complete code here: