Select Page

I’ve spent the last two weeks patching, testing, fixing and tweaking OpenUI in our Public Sector environment. We’re in an interesting situation here in that our client workstations are so tightly locked down, we’re unable to deploy any software changes to them – and that includes any updates to the HI client ActiveX control. This means we’re stuck on for now, until we’re authorised to test and deploy IP 2014. The impact of this is that we’re unable to deploy and a handful of Quick Fixes and Fix Packs that would otherwise have allowed us to resolve some OpenUI issues. As it is, we’re having to make do.

Forgotten your own name? All of this code will help!

Forgotten your own name? All of this code will help!

So, how is it going? Well, it’s going really well as it happens! Once you get over the initial awe of seeing Siebel in a different browser and then the horror of uncovering some of the bugs, it’s really just business as usual. We’ve been testing against our UAT test scripts, raising internal bugs and working through them. Not unlike any other major release of our code and what we’ve got is a really nice, speedy and functional application that we’re deploying to new users of Google Chrome, Firefox and IE10.

One thing that has struck me so far is that I’ve resolved all of the fixable OpenUI issues with Siebel Configuration. There are a number of Siebel defects that require DLL changes, and we’ve had to park those, but the rest have had fixes or workarounds that were declarative. At no point have we had to mess around with JavaScript and PRs or PMs. There has certainly been a lot of CSS required to brand our application, and fix a few layout and display issues that are present in the base application, but trusty Tools configuration (and a bit of eScript and a web template tweak) have seen us through everything else.

Which leads me to a conclusion that I’ve come to that may interest you: developing Siebel is still all about declarative configuration. You’ll see blogs and web sites talking about how the OpenUI Siebel Developer is nothing without JavaScript and JQuery. How “old school” web developers have no chance as they’re stuck in the dark ages of HTML and tables. Well, they’re wrong – simple as. In delivering your shiny Siebel solution to your client, you’ll stick to the mantra that’s been in place since day one of Siebel: configuration before customisation. Making use of the swathes of out of the box functionality that Oracle have built on over the decades is still the number one weapon in the Siebel Developer’s arsenal. Convincing business stakeholders and users to tweak their business process to take advantage of that functionality is still the best way to deliver a solution on time and under budget. Leaping straight into building new Physical Renderers may be existing and challenging, but you’ve got to take a step back and think: is it necessary?

Look at the example of the infamous “Salutation Applet” problem. For many years, Siebel has prompted its users with the cheery message on the homescreen: “Welcome back, Casey Cheng. Today is Monday the 6th of October”. Now, I can’t speak for you but my users know their own name and what day it is: they don’t need Siebel to tell them. And yet, the clamour to fix the lack of display of this useless message in OpenUI is scattered across the forums. There are numerous examples of Physical Renders, amounting to hundreds of lines of JavaScript code, all to solve this “problem”. Our solution? One conditional expression in personalisation to hide the applet for OpenUI users. There was no requirement for this functionality, so why try to fix a problem that doesn’t exist? And the complexity of those PR solutions to display a simple greeting message – that worries me. Talk about using a sledge hammer to crack a nut…

Now, it’s not the case that JS and JQuery skills will not prove useful here. There will always be a situation, as there always has been in the Siebel world, where your customer absolutely, positivity must have that bespoke functionality and you might have to resort to JS code to resolve it. But those of you, and myself included, who are not JS whizzes need not despair. The world still needs good Siebel developers and you don’t need to be a JavaScript guru to be one.