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


        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.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 – New Feature: Theme Defaulting

Selecting your OpenUI theme can be done through the usual mechanism by setting it in the User Preferences – Behavior view. As added feature you can now globally set it on object manager level too. Under many circumstances this makes sense because often customers will not give their end users the flexibility to select another theme.

Another alternative would be to default a certain theme using Manifest Administration, which is also a new capability in IP14. See @lex post about Themes and Manifests in IP14 to get a grip on this functionality.

And then there is a third approach: a new component parameter “DefaultNavigation” has been introduced as part of IP14. It it seeded with “NAVIGATION_SIDE”.


Values can be any of the Language Independant Code values “NAVIGATION_SIDE”, “NAVIGATION_TAB” and “NAVIGATION_TAB” (or a custom theme you added of course). These LOV values belong to Type = “NavCtrlPR”


Next it would be nice if we could also default the transition at the object manager level 😉

– Jeroen

Siebel Open UI – Webcam integration

This question got raised by a consumer goods customer I recently worked with: “how could we integrate the webcam on our Windows Tablet PCs to point & click and generate attachments?”. The consumer goods business can be characterized in that sense that Siebel customers have traditionally (and pretty much continue to do so) deployed on Siebel Remote clients. Reason is their sales reps need to have full disconnected functionality and the data which goes along. These implementations traditionally tend to run on Windows Tablet PCs, also quite specific for this industry. Sales reps need the ability to easily take pictures and store them against the visited account or visit itself for matters of retail audits. So I set my mind to think and come to a working solution with just a bit of code.

First the teaser…

A bit Googling revealed a nice plug-in called WebcamJS and initial tests plus reading the documentation stemmed positive.

So, next step. Integrate it within Open UI. I took the challenge to use a IP14 pre-release. The WebcamJS code comes with a stand-alone JScript library.

I took the vanilla “Account Attachment View” as a starting point and added a “no-menu applet”. Basically a regular list applet but with particular applet web template.


Added the applet to the existing Account Attachment view. Nothing fancy.


Next I created an empty shell physical renderer using Duncan’s code generator, called “DesktopWebcamPR”. I associated both my physical renderer as well as the “webcam.js” to my “Webcam JS Applet” I just created. This ensures that the webcam.js will be downloaded alongside the DesktopWebcamPR physical renderer.


Next, I put the necessary code in the DesktopWebcamPR. I added three <div> elements to hold the webcam canvas, the result and a bunch of buttons (#mycam, #myresult, #buttons). I added three buttons to Take a snapshot, Clear the snapshot and Save the snapshot. Each button invoking its own function, respectively take_snapshot(), clear_snapshot() and save_snapshot().

Initializing the webcam is just a matter of a single line:



Next, implementation of the three functions.

To generate a snapshot it requires just a few lines:

function take_snapshot() {
Webcam.snap( function(data_uri) {
document.getElementById('myresult').innerHTML = '<img src="'+data_uri+'"/>';

To clear the snapshot I choose a simplistic approach:

function clear_snapshot() {
$("#myresult").find("img").attr("src", "")

To save the snapshot obviously required a bit more work. I considered couple of options. One was to actually invoke a Webservice, the other to invoke a server-side business service. A Webservice could also be invoked locally on a Mobile Web Client, and would be kind of transparent when working with a Web Client to invoke the service against the EAI OM. Since the data is already Base64 it would make sense and we would not need a single line of eScript. Anyways, I opted for the quickest which would be an eScripted business service “ORCL Create Attachment”.

It does a few things:

1) It generates a SiebelMessage based on the OOTB “CRMDesktopAccountIO” Integration object
2) It retrieves the next available ROW_ID to act as an unique file name for the attachment
3) It adds the Base64 payload
4) It invokes the EAI Siebel Adapter to Upsert the SiebelMessage

And well… that more or less is what is need to make this to work. Obviously, the solution has some rough edges but serves its purpose.

You can grab the necessary code here.

– Jeroen

Dromaeo benchmarking – IE11, FF R31, Chrome R37 and Canary

Besides Google’s Octane 2 there is another extensive benchmarking framework: Dromaeo.

I took it to the test for the usual suspects.

The good thing about Dromaeo is that it has dedicated tests for jQuery, very useful with OpenUI in mind 🙂

And the results are… I ran a number of tests on my good-old i5-2520M@2.5Ghz. I ensured while running the test the machine was idle.

DromaeoFrameworks DromaeoCoreDOM DromaeoJslib

The tables list the number of runs/second for the different test dimension. From those I calculated the performance factors. So “Chrome vs. IE” has a performance factor 2,9 for the “DOM Attribute (Prototype)” dimension. So Chrome R37 is 2,9x faster than IE11 for this particular characteristic.

It is clear that IE11 overall is being surpassed by its rivals. Especially when looking at the relevant dimensions for Siebel Open UI (jQuery) Chrome is the overall winner. For jQuery DOM Query/selector operations Firefox and Chrome end up ex-aequo. More general the jQuery framework is better tailored for Chrome. The more all-purpose DOM operations are best tailored for Firefox (these entail direct DOM operation without using any framework).

On generic DOM traversal IE11 is tailing its rivals.

A closer view on Siebel OpenUI performance, the Firefox – IE11 battle

In a recent previous post I already concluded that IE11 is not an ideal browser for Open UI. Which obviously is shame because still the most widely used browsers within organizations. In private life though people tend to use different browsers. But even though the decline for IE is ongoing it will take time before IE is replaced in workplace environments.


Organizations tend to move towards Firefox rather than Chrome. Most likely because Chrome being a Google product, too risky? Firefox as Open source is assumed a safer bet. But this goes at a very slow pace. We should not expect that to change dramatically over the coming years.

So, we have to deal with IE. That is why I created in Siebel OUI as couple of “test” views. Large views which have increasingly more applets and controls. These views are build on top of a VBC in order to cancel out any false-positives from the test results (e.g. to measure only rendering, not queries and fetching).

Taken for granted that I created huge views which you will never (?) see in a typical Siebel environment. But I wanted to take a somewhat scientific approach here to find a possible pattern. View 1 and 2 could be considered still realistic in terms of number of controls in certain customer scenarios – though 2 could be considered pretty outrageous.

  • View 1 (indicative: 40 controls in total)
    • One Form applet with 20 controls
    • One List applet with 20 list controls
  • View 2 (indicative: 240 controls in total)
    • One Form applet with 20 controls
    • One Form applet with 100 controls
    • One List applet with 20 list controls
    • One List applet with 100 list controls
  • View 3 (indicative: 440 controls in total)
    • One Form applet with 20 controls
    • Two Form applet with 100 controls
    • One List applet with 20 list controls
    • Two List applet with 100 list controls
  • View 4 (indicative: 640 controls in total)
    • One Form applet with 20 controls
    • Three Form applet with 100 controls
    • One List applet with 20 list controls
    • Three List applet with 100 list controls

If you want to grab the .sif file – go ahead 🙂 It contains the VBC, Applets, Views and Screen. You only need to register the screen in the application of your wish.

Ok, what have been my observations? Firefox is the winner with IE11 on the other end of the spectrum.

What would be your leading design practice: design & keep your views small 😉 No, really – the should be kept small if you want a view to render sub-second. And prevent at all times to enable too many list columns. The common reason “we need it for export” should be reconsidered. Where that might work in HI – in OpenUI it has severer implications. The JQGridRenderer has a noticeable overhead.

Do not forget that the timings below (in milliseconds) are measured between “PreLoad” and “PostLoad”. Those are JScript events of the OpenUI API. But these timings exclude further rendering time (such as CSS).



Siebel Innovation Pack 2014 & Open UI – Statement of Direction

Siebel Innovation Pack 2014 – Statement of Direction
Siebel Open UI – Statement of Direction

The IPxx numbering scheme will be Oracle’s major delivery vehicle, as most Siebelists know. Every year, scheduled late Q4. Honestly the IP numbering is just so much more informative. Despite that fact that yes, there will never be a “Siebel 9” release (as competition of Oracle likes to market it towards Siebel customers). I have always found it hard to tell what a major release entails, most of all marketing driven. The IP numbering scheme is honest and clear to all customers. No more fuss?

Siebel IP2014 will bring a number of important improvements to the table.

To name two enhancements in particular: direct editing of attachments and iHelp.

Both were features lost in Open UI.

Direct editing of attachments due to browser limitations (especially the fact that browsers to not consistently support the HTML5 FileIO specification yet). For OpenUI to have this feature enabled again, it will require Java.

iHelp because it required extensive re-factoring of both the iHelp designer UI as well as the iHelp pane and highlighting feature. But IP14 will bring this feature back, sigh 🙂

Further list of OUI improvements:

  1. OpenUI rendering performance (see also my other post)
  2. Calendar Alarms
  3. Drag and Drop of items
  4. Catalog Browse – The Siebel Catalog Browse for Quote and Order has been evaluated to support a drag-and-drop functionality for adding products to the shopping carts
  5. Product Configurator User Interface – The Siebel Product Configurator web artifacts have been updated to uptake all of the design principles of Open UI. This will allow our customers to refactor their customizations into the new Configurator framework. Style and theme changes are also available for web artifacts to complement the new framework. Additionally, all administration views that support Siebel Product Configurator are now available in Siebel Open UI.
    SmartScript Designer
  6. Smart Answer for Service
    Siebel Scheduler Administration View
  7. Gantt Chart Resource Scheduler
  8. Partner Portal (Quote/Order Home Pages)
  9. Organizational Chart or Global Account Hierarchy View (Account and Contacts)
  10. Expression Rules Designer
  11. Organizational Analysis View
  12. Barcode Scanning and Quick Search
  13. Email/Print Invoice (Siebel Service Mobile)
  14. Funnel Chart (Sales Pipeline Analysis Chart)
  15. Loyalty Program Designer

Siebel is available (Innovation Pack 2013 Spring Release)

Siebel is available (Innovation Pack 2013 Spring Release)

Siebel – the Innovation Pack 2013 Spring release has been made available for download. It further improves the Siebel Open UI – and will add Open UI in Disconnected mode as quickfix in the coming period. does include also the Incremental Repository option to improve parallel development efforts.