Siebel IP14 – Plugin-wrapping your Text Area controls using popBox

In the “old” days of the high-interactivity client editing data captured within a text area was possible by means of a simple popup control. Clicking the ellipsis et voilá you got yourself a popup control to comfortably edit and save back your data.

With the introduction of the Open UI this feature ceased to exist. It was deemed by Siebel development staff unnecessary to have a like-for-like feature since browsers allow expansion of text area controls.  Well, this is not true for all browsers. Internet Explorer does not allow text area control expansion…

Personally – but I did get the same remark from different customers too – editing by means of a popup gives in many cases a better user experience. So, I started Googling for existing solutions out there in the wild. Pretty quickly I stumbled across popBox. A tiny JQuery based framework which does exactly that I was looking for. By injecting a bit of code associated with a TextArea control by simply clicking inside that same TextArea control it shows a more appealing “popBox” control. The popBox control displays again a re-sizable TextArea. The popBox comes at a default size, but of course that is adjustable. 

This is what it could look like:


And this is how it actually works:

Now, where did I start? First of all by trying to manually inject the sample code provided by the distributor of the code. That was quickly done, and functional. I just injected the code through the developer tools of my browser of choice. Just find any TextArea control in Siebel and identify it by its name attribute.


Next execute the JQuery selector followed by the popBox() JQuery function call.

popbox3Afterwards check what happened to the DOM. Hey, it did insert a couple of new <div>. Hooray!


So popBox did pass the initial test with flying colors. Well, flying colors? After clicking the control the popBox control displayed and was more or less functional. I say “more or less” because although the value entered in the popBox control was send back to the originating TextArea control, Siebel did not save it. Well, something to worry for at a later moment!

Next step, how to decently integrate it in Open UI. With the introduction of Innovation Pack 2014 “plug-in wrappers” have been introduced along. @lex spent some posts already explaining the backgrounds. Plugin-wrappers, which can be explained as the most narrow version of a physical renderer. The beauty is that you can attach a specific (control) plugin-wrapper and extent the behavior of the standard class for the given control, be it a plain text control, a dropdown or what have you more. And you can do so selectively using the “AttachPW” method of the plugin builder class.

Alright, it would be my first Plugin wrapper control – so it would not be bad to use some boilerplate code from @lex´s “Slider Control” example. I have to admit it was not that straight forward to get things working. First of all I was struggling to get the code loaded in the right order, such that the plugin base class would be available prior to extending it in the plugin wrapper renderer code.

Huh? Well, this line took me quite some time and collaboration with collegues:

define("siebel/MyPW", ["siebel/basepw"], function ()....

Until now I never had to use it as such, but in the define() statement you can pass other classes which are required. In this case “siebel/basepw”, the base plugin-wrapper class.

This is what the Bookshelf has to say about the Define method:

The Define method identifies the modules that Siebel Open UI uses to determine the location of the presentation model file or physical renderer file that Siebel Open UI must download to the client. It uses the following syntax:

define (module_name ,list_of_dependencies,function);

Defining the dependencies did the job.

The next challenge I faced was the fact that Siebel injects a lot of <span> throughout the DOM. But the moment it injects <span> elements is after any plugin wrapper code executes. That in itself should not have to be a big issue. But for the default popBox code it was. The popBox code is expecting that its sibling element is the TextArea element. But Siebel injects a <span> in between both just after the plugin wrapper code executes. Mmm… I changed the popBox code slightly for that matter. There might have been cleaner alternatives (I’m open for those).

Final challenge was to actually save back the data to Siebel. I more or less was able to re-use @lex code for that. What I needed to to was raise from the popBox code an “on close” event. That was pretty simple since I found the solution here. It meant just adding one more line of code to the popBox code.

Here is the final code I came up with:


Downloadable files can be grabbed here:

All together, the solution shows the power of the control plugin wrapper architecture again. Just a couple of lines of real code, leveraging what has already been developed by others. Enjoy!

– Jeroen


A simple upgrade to IP14 I guessed…

… how could I have been more wrong 🙂

One of my customers took the challenge to upgrade from to Innovation Pack 2014 almost the day it became available for download. They did run a successful sandbox upgrade to Innovation Pack 2013 a couple of months back. The killer feature for them was the Java-enabled “on-the-fly” inline editing solution for attachments in Open UI. Well, essentially bringing back pre-existing like-for-like functionality from the High Interactivity client.

So a couple of weeks back the the AIX-centric Siebel Enterrprise got upgraded and patched with PS1 and we ran the Incremental Repository Merge. So far so good. The Aurora themed tab-style upgraded application does look decently enough. And functionality-wise no big issues at first sight.

Next step was to upgrade the Windows-based Document server. And well, that turned out to be a painstaking exercise. Ough! I expected this to go down smoothly and simple, after the AIX upgrade and repository merge went fine. But in the end this took quite a bit of effort and Tech support involvement before the server was up and functional.

What happened? Well the Siebel Server did start-up fine after the IP14 PS1 upgrade. The only Component which was initially not getting online was the…. Document Server. All other system components were running just fine. From the DocServer_xxx logs little supporting evidence of what could be the culprit. The enterprise log did seem to point towards a crash of the component seconds after it got started.

This was all in the DocServer log:

ObjMgrSRFLog Open 5 0004dff754850044:0 2014-12-11 15:35:23 Begin: OpenSRF
ObjMgrSRFLog Open 5 0004dff754850044:0 2014-12-11 15:35:25 End: OpenSRF
ObjMgrLicense Load 5 0004dff754850044:0 2014-12-11 15:35:25 Begin: LoadLicenseManager
ObjMgrLicense Load 5 0004dff754850044:0 2014-12-11 15:35:25 Encoding successful

And this was seen in the Enterprise log:

ServerLog ProcessExit 1 00000b3654890b14:0 2014-12-11 16:12:20 DocServer 4676 0xc000037408 Process 4676 exited with error - Exception code 0xc000037408

GenericLog GenericError 1 00000b3654890b14:0 2014-12-11 16:12:20 (schedule.cpp (928) err=1376352 sys=6) SBL-SMI-00096: The maximum number of restarts (1) for MinUpTime has been reached. The component DocServer will not be restarted again.

But there was no crash.txt nor a .fdr file in the /siebsrvr/bin directory.

Initially Tech support hinted that we should not override the Password at the component level, but should rather use the Enterprise password. After deleting the parameter override to revert back to an Enterprise level set password for the DocServer, the situation became worse:

ServerLog LstnObjInherit 3 000bb1fb548b00dc:0 2014-12-22 11:31:34 Inherited listening object for port 49156
ServerLog LstnObjPrivCreate 3 000bb1fc548b00dc:0 2014-12-22 11:31:34 Created port 49166 for Document Server
GenericLog GenericError 1 000bb1fc548b00dc:0 2014-12-22 11:31:58 (ccfom.cpp (492) err=4522127 sys=0) SBL-SCL-00143: Internal: input disassembly failed.
SmiLayerLog Error 1 000bb1fc548b00dc:0 2014-12-22 11:31:58 Terminate process due to unrecoverable error: 4522127. (Main Thread)

So, reverted back to a Component-level set Password.

Ok, back to the Enterprise log. It hinted on a crash. And yes, after disabling “Windows Error Reporting” on the box and installing the Windows Debug Diagnostic Tool we were able to move forward. We created a simple rule to take effect on a crash of any “siebmtshmw” (a Siebel multi-threaded) process and enabled it.


Ah! Now we got a crash.txt and the coredump was saved as well.

Immediately the root-cause became apparent:

ntdll +0x332b0 = RtlImageNtHeader() +0x11c
ntdll +0x335b7 = RtlImageNtHeader() +0x423
ntdll +0x334a2 = RtlImageNtHeader() +0x30e
kernel32 +0x114ad = HeapFree() +0x14
MSVCR110 +0xdac2 = free() +0x1a
sslcosd +0xb197 = UTLOsdRealloc() +0x67
sslcrsa128 +0x1106
sslcrsa128 +0x62eb = AllocateRC2CrypterAdpt() +0x333b
sslcrsa128 +0x603b = AllocateRC2CrypterAdpt() +0x308b
sslcrsa128 +0xc5bd = AllocateRC2CrypterAdpt() +0x960d
sslcrsa128 +0x4da4 = AllocateRC2CrypterAdpt() +0x1df4
sslcrsa128 +0x5783 = AllocateRC2CrypterAdpt() +0x27d3
sslcrsa128 +0x3a1b = AllocateRC2CrypterAdpt() +0xa6b

Mmm… related with encryption…

Looking further down the call stack…

10000000-10043000: O:\sba81\siebsrvr\BIN\sslcrsa128.DLL,

Huh?! For those unfamiliar with the “Siebel Strong Encryption Pack”, well, this file is used to increase the encryption key-strength used by Siebel. The standard key-strength is 56 bits, by copying this file from the \siebsrvr\bin\ssep directory the key-strength can be increased to 128 bits.

So what happened during installation?

The Siebel IP14 feature which copies “Customer Modified Files” during a software migration, also copied this library… Instead it should have copied the same file from the \siebsrvr\bin\ssep. Overwriting the file with the IP14-seeded \siebsrvr\bin\ssep\ version did the trick. But at the expense of numerous hours of analysis.

So – a clear bug in the IP14 installer for which a Bug will be raised. This might affect your customer too, if they are using SSEP on their current release. Be forewarned!

– Jeroen

IP14 – Manifest Administered View Transitions

To be honest I was a bit disappointed that we could still not control the View Transition through manifest administration. Although we can with IP14 default a theme by either manifest administration or object manager parameter the out-of-the-box View transition defaults to… well “null”. And really setting it to “Fade In” will make the overall user experience so much better! Alright maybe tweaking (lowering) a bit the transition times which default to .5s. Or set the transition time to nearly zero in which case the Fade In transition prevents you seeing “moving parts” in the view while you navigate around.


I wrote a brief article about how View Transitions work when this became available in IP13. It is quite a nifty feature. Well, I guess it would have been better if Oracle would have seeded the shipped “Fade In – Fade Out” transition as the default for earlier mentioned reasons. But then still you would have to cater for upgrades where one would ideally as much as possible maintain user preference settings.

So I thought – along the lines of Theme defaulting using manifest administration, could we do the same for View transitions too? And yes, we can. And it turned out to be so damn simple too.

For that I created a new Transition called “Manifest Controlled” for which you simply have to create an LOV entry for Type = PAGE_TRANSITION.



Next I created a separate fadeinout.css which contains the Fade In Fade Out classes. To make life easy I just copy-pasted it from the theme-aurora.css.uncompressed which comes with IP14. I modified it such that the language independent value I created for the LOV is referenced by the four classes. Again, to understand how View Transitions work look at my previous post.


Finally administering the custom fadeinout.css in the Manifest Administration does the trick. To keep things simple for now I just added it to the exiting “Theme” which also enables loading the theme-aurora.css itself. But you will ge the point. I do not see real use cases to use expressions actually. Just to ensure that every user has the “Fade In Fade Out” transition by default. And… if the user decides otherwise, the user preference will simply override.


Voilá, you have a Manifest Administered transition 🙂

– Jeroen

Using “DefaultFocus_Edit” Applet User Property to maintain drilldown enabled after a query

Have you found this annoying too? You query on a any list applet using a list column which has a drill-down and you want to drill-down once the results are returned. Default behavior is that the List Column you used for your query will remain focus once the data is returned. Drilling-down requires you to step out of the control which re-enables the drill-down again.


A simple solution turns out to be effective:

Configure on the affected list applet a “DefaultFocus_Edit” applet user property by specifying an non-existing list column as its value


The net effect will be as shown below – the drill-down remains available.


The side effect obviously is that you cannot use DefaultFocus_Edit for what it was originally designed…

– 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