Oracle Partner? Oracle Siebel IP2014 Partner Workshop!

Are you an Oracle Partner? In that case you might have interest in this upcoming Siebel IP14 Partner workshop. More info and registration via this link.

Oracle is hosting a special 2-day event to give our partners an overview of the Siebel IP 2014 release, and an opportunity to work through hands-on labs and demos to learn about key concepts and best practices with Open UI. The Oracle Siebel IP2014 Partner Workshop will feature key experts who will guide you through the IP2014 release. In case you first need to catch up on Open UI? No worries. Come and join at the pre-session workshop!

No More Java Applets In Chrome – Does It Impact You?

Since Google published the “NPAPI de-support statement for Chrome” on September 2013, it was a matter of time. And with Chrome R42, the April ’15 release it was a fact. The NPAPI got disabled.  For Chromium, the Linux fork of Chrome, it was already with R35 by the way. Thanks to @lex for the notification. Since I was running with Chrome R41 I did not notice it (yet).

Now, the question is – what could the impact be? Obviously you should be using Chrome to have an impact. Although Oracle Siebel development is not promoting the use of Java Applet based integration (or any other browser plug-in), with Siebel Innovation Pack 2014 Oracle implemented… a Java Applet. Specifically meant for managing file attachments realizing like-for-like functionality conforming to the High Interactivity client. Basically the Java applet materializes two main functions:

1) It allows to open attachments with known extensions immediately after downloading the file

2) It allows edit & save-back

To realize both functions, it requires any type of browser plug-in, to bridge the gap between the browser and the OS. And a Java applet makes the most sense.

Well, this standard IP14 functionality will cease to work with Chrome R42. But so will any other Java Applet bespoke integrations. And for sure, there are a number of such integrations under development or in production. Since with OpenUI the ActiveX-based Siebel Web Client Automation framework is no longer a valid option, Java has been the resort of choice.

UPDATE: Google plans to take away NPAPI completely per September 2015.

For the time being Chrome allows to re-enable the NPAPI. There are basically three options:

1. Entering “chrome://flags/#enable-npapi” in the address bar, select “Enable” and “Relaunch” Chrome.
2. Start Chrome using an addtional swith “–enable-NPAPI”
3. Through Group Policies using Chrome Administrative Templates. This allows to enable NPAPI plug-ins selectively. .

Next question is when Firefox will move in the same direction? For Internet Explorer, the Java Browser Plug-in is ActiveX based. But a valid question is whether the new “Spartan-generation” browser will support the NPAPI framework. Spartan will quite surely not support ActiveX 🙂

Talking Spartan, recently Microsoft released it for beta testing along with Windows 10. First results are not very promising.

Quoting:

Spartan is meant to be, well, Spartan. Internet Explorer is commonly viewed as bulky and slow, and Microsoft wants to fix that perception. Unfortunately, Spartan doesn’t do as much as expected to challenge user preconceptions.

And further…

Spartan has a new Web browsing engine called Edge. Well, kinda new. It’s actually a fork of Trident, the browser engine used by Internet Explorer, but changed to improve Web standard support and performance. Presumably, the gap between it and Trident will only grow over time, as Microsoft says that Internet Explorer’s legacy engine won’t receive any of Edge’s updates.

For now, though, it seems that Edge is not far removed from its predecessor. We started out testing with the Peacekeeper Web-browsing benchmark, a test that broadly covers numerous performance metrics, and it gave Spartan no advantage.

But then… and this is really important… Octane is the Google-driven suite of benchmark tests. And it turned out in previous tests done by me, being the best predictor for Siebel Open UI. So quoting…

Ah, at last, we have a result that’s favorable to Spartan! It appears that Microsoft has done serious work upping the browser’s JavaScript capability, and that’s an incredibly important feat given how widely it’s used.

The excellent Octane result may explain the feel of the browser, which is quicker than the benchmarks suggest. In typical use, on Web pages that don’t include games or video, Spartan feels just as snappy as Chrome and actually quicker than Firefox. Pages scroll smoothly, even when they include numerous intensive elements, such as high-resolution photos, with no hint of unsightly check-boarding (on our desktop with an Intel quad-core, at least). Multiple tabs eventually slowed the browser, but only after opening 15 or more.

So I can safely end a bit more positive on the Spartan project. Unfortunately Spartan will only be released on Windows 10. No backport as of yet to Windows 7 / 8 (even if it were technically feasible). And we can safely say that it will take years before enterprises will change from Windows 7 to 10 (my guestimate).

– Jeroen

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?

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:

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.

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.

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.

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.

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:

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

   

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”)

   

4. The business  service is as straightforward as can be. I condensed the initial version a bit further taking out unnecessary code.
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.
6. A bit of styling with a golden edge. Add this snippet of CSS to your own override file.
7. And finally, it needs to be added under Manifest Administration.

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

• Postload file
• CSS fragment

– Jeroen

Siebel Hub – The Open UI Challenge 2015 Is On!

April has started and the team at the Siebel Hub can look back at an amazing start of their newly crafted platform since January. It is apparent a lot of effort went into launching the Siebel Hub. And a wealth of information got shared already by @lex, Richard and Bruce. And the team is further expanding in uncharted territories. And what a great idea: an Open UI coding challenge. Open for everybody. For single developers as well as teams. Do you feel taking up the glove and enter the competition?

– Jeroen