Using BI Publisher as low-cost approach to generate correspondence from Siebel

Siebel Correspondence, technologically a dinosaur solution. Running Microsoft Word as single-threaded proces on a Windows-based Siebel Server… Well, it still works and there are plenty of implementations still using this good-old approach. But the side-effects are there. Scalability (only by adding servers, regardless of being small & virtual), little ability to include logic in the templates and sensitive to incidents such as hanging Word instances to name a few limitations. Still, use cases are still there.

Of course Oracle has alternatives in this area too. Our flag-ship product is Oracle Documaker, which came along with the aquisition of Skywire back in 2008. A full-fledged solution with enterprise capabilities including batch and interactive generation of documents, a full IDE called “Documaker Studio” with template design capabilities driven by business users (really), workflow driven and scalable build of Web logic server. But this post is not about Documaker.

I wanted to highlight a recent customer web cast:

Innovations with Siebel Correspondence for Customer Service at New York Justice Center


For those who are not familiar with BI Publisher, this is an application allowing to generate reports, and is available as a standalone product but as well integrated in products such as OBIEE and Siebel. BI Publisher can work with different data feeds, but the integration of BI Publisher in Siebel is purely based on Web services.

Funny fact: BI Publisher was long ago sold as XML Publisher. Similar to Documaker it works with an XSD to map data elements into a report document, where Microsoft Word is the “editing tool” or IDE using a BI Publisher plug-in to support mapping the data. Under the hood, in Word you do no generate a true Word document but rather an XSL-FO (XSL Formatting Objects) template. Consider Word as just the IDE which was chosen in the past. BI Publisher can output in different output format including pdf, rtf, xls and ppt.

Where writing typical “report” template can be pretty straight-forward. Developing a true correspondence letter type-of-template though could easily become more complex. Think of hiding paragraphs or making distinctions based on recipients or recipient-related attributes. The cool thing is that in your XSD you can essentially provide all relevant data available in Siebel, as long as you can relate it to the business object on which you base your XSD (Integration object). And with XSL you have a lot of flexibility at your fingertips, but you need to have some level of comfort in writing XSL 🙂

So… defining a BI Publisher template document can easily become more an IT-task than a task for a business-type of user, because of the need to resort to custom XSL instructions / logic.

What Deloitte did for the New York State Justice Center was leveraging the Siebel Reporting business service to on-demand generate a Word document and allow post-editing. This is a nice alternative for traditional Siebel Correpondence and a fairly low-cost solution in terms of licensing too. But the limitations should be kept in mind with regards to template development and management in general. There is no such thing as a multi-user IDE with in-build version control, approval workflow and more of those goodies you would get with a solution like Documaker.

– Jeroen

OpenUI Rendering Performance: Dummy Toggle Applets to the Rescue

This the the teaser…


This post actually can be considered a workaround. On the other hand it provides end-user functionality. As most of you will know IP13 comes with the configurable option for “Collapsible Applets“. Just adding two Applet User Properties does the work to make an applet to appear either expanded (default) or collapsed. Though this is very nice, collapsing the applet will only happen once most of the OpenUI code has completed execution. In that sense if you would collapse all your applets in any view, it would take almost the same amount of time to render the view.

Now, I wanted to figure out an option which would reduce rendering time by showing collapsed applets. Why? Because large views in Siebel Open UI tend to require linear more time to render (see my previous post). And we do have many existing customers which have build such legacy views in the past which would render just fine in High Interactivity, but are less acceptable in Open UI.

What I came up with is the option to use traditional toggle applets. For my noticeable expensive view from my previous post I created a whole bunch of “dummy” applets. Just empty shell form applet with no controls exposed. The nice behavior here is that rendering the dummy toggle applets obviously would come at considerable less execution time.

One “dummy” applet for any applet I want to expose. Why one for each? Because the hard-coded configuration of the “Toggle” attribute on the applet. But since it pertains here just a bare-essential applet that is not such a big deal.

dummyapplets dummapplettoggle

So far so good. But traditional toggle applets require the clumsy use of a combobox to toggle between applets. Perfectly fine if you have a whole list of potential toggles. But in this case I want to present the user with a more user-friendly “double-click” to toggle from the dummy applet to the actual applet.

After inspecting (or say: reverse-engineering) a bit the OOTB code concepts, I found a way to actually invoke the Toggle method within a physical renderer.  It took some time to get this particular part of the solution to work 😉


I put the code within tine BindEvents funcion of my custom “togglepr.js”. After reverse-engineering other OOTB code – I found that using the “OnControlEvent” method on the Presentation Model would be best suited. The nice thing here is that BindEvents will pass the PM context along, which you can access using the data.ctx object. The ctx object will get you the presentation model.

Next invoking the Toggle should be best-practice done using the constant defined by Siebel for this method “PHYEVENT_INVOKE_TOGGLE”. Finally we need to pass the sequence of the applet we would like to toggle to. In our case “1”.

I decided only to implement uni-directionally toggling (from dummy -> actual applet, but not back to the dummy applet). That keeps things easy.

Next I wanted to have clean and crisp dummy applets. So no “Toggle” combobox, no “Menu” and now Row Counter.


Removing the toggle combobox and the menu was easy.

Removing the row-counter caused more troubles. It appears the row-counter is inserted at a very late stage. After the ShowUI of my custom physical renderer completed execution.

Using setTimeout brought the solution. This function can be found on several location in the Open UI standard code, and is standard JScript function. You pass it two arguments, a function and a sleep time. Functionally, if you provide a sleep time of “0”, it will execute after all other JScript code has completed.

Because I also did not want the Toggle combobox on the actual applets, I needed to add some further logic using ClientPMUserProperties. I created two:


The “BareEssentials” property will remove the complete div for all applet content. The “HideToggle” property will remove the Toggle combobox.

Just for sake of the POC I added these two to the OOTB pmodel.js. This is obviously not a recommended practice for production. But it saved me time creating a custom presentation model extension.


The end result is that the initial view looks as such:


By double-clicking on any of the headers, the applet will toggle. Double-clicking on e.g. “ToggleCAC” will render the view as such. And this will execute very fast too, as it only partially refreshes the view instead of rendering the complete view.


You can grab the complete physical renderer here.

Comparing browsers for OpenUI – Octane 2 as a benchmark tool?

Recently I took Google Chrome Canary 64-bits (R39) to the test. It appeared that Google’s own disclaimer:

Be forewarned: it's designed for developers and early adopters, 
and can sometimes break down completely.

Should be taken seriously. Both Canary and the stable version (R37) should be able to run side-by-side. Even though both R37 and R39 were working flawlessly for normal browsing, my Siebel dedicated client would no longer run against R37. Uninstalling both releases and installing R37 fresh resolved the issue.

First thing I did: run Google’s own Octane2 benchmark against both browsers a couple of times. I made sure there were no other CPU intensive tasks running.

Interestingly enough R39 falls behind R37 overall.

Octane is a an open source initiative from Google. The dimensions against which Octane tests browsers are shown on the left-hand side. In the middle section contains the rough results for IE11, FF31, Chrome R37 and R39 are shown. On right-hand side performance factors are calculated.


R37 overall is a factor 1,1 faster than R39. On certain dimensions the differences are more than a little.

The red highlighted rows have in my personal view are important dimensions for Siebel OpenUI performance. The dimensions are pretty well explained here.

For example “Splay” and “SplayLatency” are relevant to the OpenUI framework. OpenUI depends on JQuery and executes fast amounts of script. So object creation, destruction and an efficient garbage collection process are key.

  • Splay
    Data manipulation benchmark that deals with splay trees and exercises the automatic memory management subsystem. Main focus: Fast object creation, destruction.
  • SplayLatency
    The Splay test stresses the Garbage Collection subsystem of a VM. SplayLatency instruments the existing Splay code with frequent measurement checkpoints. A long pause between checkpoints is an indication of high latency in the GC. This test measures the frequency of latency pauses, classifies them into buckets and penalizes frequent long pauses with a low score. Main focus: Garbage Collection latency.

Put it together in a visual representation…


What I’m personally particularly interested in is whether Octane2 could be a valid benchmark for Siebel OpenUI in particular. Octane2 is developed by Google, so will Chrome prevail by definition over other browsers? There are other benchmarks such as Sunspider (see previous post) and Dromaeo. The nice thing about Dromaeo is that it splits up in certain categories of tests focussed e.g. on CSS selection and JQuery (used quite a bit in OUI as we know). I did not used Dromaeo so far, on the list. Dromaeo tests are more elaborate and take more time to complete.

So let’s loop back to my previous post where I build a number of increasingly heavy Siebel OpenUI views. I ran a new set of timing tests using the described mechanism.

You will see two rows (collapsed and expanded). For now – just neglect this. Will spent a separate post on my challenges to improve complex views – rather than splitting the applets across different views 😉


For example these test tell that Chrome R37 is on average 1,2x faster than R39. That compares to the Octane2 results. Especially if you relate it to Siebel OpenUI relevant test dimensions:


Also the Chrome vs FF (1,4x) compares pretty well to the timings measured in my OpenUI stress test views.

But to comparing to IE it would be a very bad indicator… Where the OpenUI performance factors are 3,4x for FF vs IE and 4,3x for Chrome vs IE – Octane would respectively indicate a factor 1,8x and 2,5x.

What is clear is that the performance breakdown on IE11 follows an exponential function, where as for FF and Chrome it’s a more linear curve. Which was made clear in my previous post already.

In a next post I will dive a bit deeper into Dromaeo as well to continue my quest to improve rendering large views in OpenUI.


Siebel / is Generally Available – October 17th!

Siebel / is Generally Available - October 17th!

Long awaited Innovation Pack 2013 has been made available for download on eDelivery. contains quite a bit of goodies on the function side – most of them related with Open UI. The IP2013 also contains the initial release of a new era in Siebel Mobile solution – Siebel’s Disconnected Mobile solution. Leveraging HTML5 ability to store data inside the browser – enabling Siebel to run off-line against a special kind of local database structure. Conceptually there are strong links with Siebel’s prior Handheld technical architecture (with regards how data is being extracted, synchronized) – though Disconnected Mobile offers a much better CX.

Further on the installation/upgrade side of things – IP2013 contains an improved IRM wizard – which is basically run through the Database Configuration Wizard – rather than invoked through Siebel Tools. It contains far less manual steps than the initial IRM implementation delivered with Oracle will soon offer a new Webcast discussing and demonstrating the changes with regards to IRM.