Siebel – Please Don’t Loose My Attachments!

One of my customers recently showed me that using the most straight-forward scenario one could think of, would make them loose attachments in Siebel.

What is the issue? Once you would attach a new file in Siebel you will typically use the “New File” button, which brings up the browser’s File Browser window. You select an attachment, and save it back to Siebel. Easy.

But guess what, if you do not force focus on the “Attachment Applet” but immediately click on the “New File” button, you will still be shown the File Browser. You select your file, and save it back to Siebel.

You’d guess. Although the UI makes you think the attachment is there, it will not be committed to Siebel unless you force focus on the Attachment applet. That could be a simple click on the applet, or filling out some attachment related fields which implicitly forces focus.

AttachmentIssue

Supposedly many customers will potentially hit this issue. But then data loss in production is one of the hardest issues to tackle… Apparently it did not yet get reported to Oracle Support yet. Well, now it has and will be tracked under:

Bug 21119217 – ATTACHMENT NOT SAVED UNLESS ATTACHMENT APPLET IS GIVEN FOCUS

This Bug will quite definitely be fixed soon per patch set. The issue applies to Siebel 15 as well, unsure whether it applies to IP13 (I did not take the time to test it).

Since my customer could not wait until a definite fix from Oracle, I created simple fix for the time being. Done by means of a postload. Not ideal, but since it pertains extremely light script…

It attaches a function to every element with class “siebui-ctrl-file”, which makes it to trigger a click on the button’s parent element once the button is clicked. This forces focus on the Attachment applet, hurray!

AttachmentFix

The file can be downloaded here.

– Jeroen

Advertisements

Siebel IP14 – Watermarking Those Query Assistant Controls

Never gotten remarks from a customer about those two “Query Assistant” controls, which are to a normal end-user less self-explanatory than a developer might think?

QA1

Putting some watermark text behind those controls should be easy. And it is. I did resort to a post loader solution. Although it could have been resolved with a Contron Plugin Wrapper (PW) too. But in this case, the code is so extremely light if written on a post loader… Why take the added overhead of a PW?

$("[aria-labelledby=QueryComboBox_Label]").attr("placeholder", $("[aria-labelledby=QueryComboBox_Label]").attr("aria-label"));

$("[aria-labelledby=QuerySrchSpec_Label]").attr("placeholder", $("[aria-labelledby=QuerySrchSpec_Label]").attr("aria-label"));

Really, there is nothing more to it. Just adding a placeholder and pulling in the “aria-label” attribute. The latter is already translated, so it solves any multilingual issues in one step.
After adding it to the Manifest Administration, this should be the outcome:

QA3

Grab the code here.

– Jeroen

 

Siebel IP14 – Getting Rid Of The “Case Sensitive” Watermark

One of my customers reported a Bug about the inappropriate display of the <Case Sensitive> watermark, is cases where fields got configured to allow case-insensitive queries. To be exact, this is the bug:

Bug 20601528 : OPEN UI: CASE REQUIRED PROMPT UNEXPECTEDLY SHOWN IN HOME PAGE SEARCH APPLET

Diving a bit deeper in the subject, in appears indeed that the Bug is yet unresolved. Although it seems on the surface a cosmetic issue, it could be confusing for end-users. All those years they have been allowed to query case-insensitive on a limited number of fields. Did the developers revoke that privilege?!

Interesting enough, in normal views the behavior is correct. If a certain field is configured for case-insensitive searches, the watermark <Case Sensitive> would not be absent. Just on Home Page views containing Search Applets, the issue is present.

CaseInsensitiveSearchApplet

After some considerations, I choose to solve this with a Control Plugin Wrapper (PW), which would be fit-for-purpose. Since a PW has a global scope, as it is administered as “Application” / “Common” – we would need to add some simple conditional logic. The PW should only trigger if both the Applet Name for the control would match and the Case Sensitivity mode of the control would be “Case Insensitive”. Otherwise, the PW should do nothing.

CIControlPW

Next, I needed to attach the PW to different types of possible controles such as Generic Fields, Picklists, MVG controls… Basically replicate the same statement.

CIControlPW2

I found that the BindEvents events, provided the appropriate timing for my code. Initially I tried ShowUI, but that event apparently triggered too early. Removing the watermark? Just a simply removing the placeholder attribute. The placeholder is a standard HTML5 feature.

CIControlPW3

And well, that’s that. No more, no less.

Grab the complete source here. Simply add it to Manifest Administration under “Application” / “Common” and Bob’s your uncle.

– Jeroen

IP 14 – Displaying The Siebel Server (The Sequel)

Last year I spent a post explaining a rather simple means enabling to display the Siebel Server name in OpenUI, IP13 at that time. Given the number of questions the article raised I opted to spend another post explaining it a bit further, improving it a bit and including the sources for IP14. But for a starter, have a quick read of the previous post.

The end result we aim for would be along these lines:

ShowSiebelServerName

So, where do we start?

        1. First of all, the concept I came up with last year is based on the fact that every Siebel Server host will have an OS system variable defined. In my case it has been named “COMPUTERNAME“. So basically every Siebel Server will need to be configured with an environment variable, named as you’d like it. On Windows it’s easy, on Linux/Unix flavors you’d need to add it to the .profile for the user under which the Siebel Service process runs.SiebelServerNameEnvVar
        2. To add-in a little flexibility I decided to create configurable System Preference which would hold the name of the environment variable. So you would be able to call it SIEBEL_SERVER_HOST or whatever you prefer. This could be an optional step, but hard-coding such parameters, should be a no-no to all among us. I named the System Preference SiebelHostEnvVar. 

          syspref

        3. The next step would be to configure two new fields in the the Personalization Profile business component. These fields would both turn out as Profile Attributes after a Web Session starts. Beautiful! And as said before – not widely known. The SiebelServerHost field will simply invoke a Business Service to retrieve the value of the OS environment variable. Nothing more, nothing less.
          • Name: SiebelHostEnvVar
          • Value: SystemPreference(“SiebelHostEnvVar”)
          • Name: SiebelServerHost
          • Value: InvokeServiceMethod(“Get Environment Variable”, “Get Environment Variable”, “‘Name’=’eval([SiebelHostEnvVar])'”, “Value”)

          pers

        4. The business  service is as straightforward as can be. I condensed the initial version a bit further taking out unnecessary code.GetVar2
        5. Now, the tiny few lines of “postload” code. Using a postload script comes with a warning, caution and instruction for good behavior. Do not overly use postload scripts. And if you use them, be considerate about the global impact. All navigations will be affected.ShowSSName
        6. A bit of styling with a golden edge. Add this snippet of CSS to your own override file.ShowSSNameCSS
        7. And finally, it needs to be added under Manifest Administration.SSNameManifest

That’s all. Grab the code here if you like:

– 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.

IE11PerfFigures

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: 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