An ‘Active Users’ view using Server Manager and a VBC

I’ve recently implemented a very interesting requirement using my old favourite, the Virtual Business Component (VBC). VBCs are great and allow you to build your own recordset beneath a virtual BC definition that behaves (almost) exactly like an old fashioned BC.

UserSessions

The steps to create a VBC are easy peasy:

  1. Create a new BC record, in Siebel Tools, specifying the class ‘CSSBCVExtern’. Call it ‘OLI – User Sessions VBC’
  2. Create a User Property on your new BC, called Service Name. Give it a value, ‘OLI – User Sessions BS’
  3. Create a couple of fields in your VBC: ‘CC Alias’ and ‘OM Login’, both as DTYPE_TEXT
  4. Create a new Business Service called ‘OLI – User Sessions BS’:
  5. You’ll need an ‘Init’ method:
  6. and you’ll need a ‘Query’ method:
  7. Create a new Applet and a new View using the Tools Wizards
  8. Add the view to a new or existing Screen
  9. Add the view to a Responsibility
  10. Job done!

I really, really like VBCs – you gain a lot of control over what you’re bringing into a record set.

Note you’ll need to set the ‘AdminRoles’ configuration parameter on Server Manager and set NSAdminRole in gateway.cfg and namesrvr.cfg, if you want users other than those with ‘Siebel Administrator’ Responsibility to see the results of your hard work!

Generate Correspondence from eScript / Workflow

A requirement I’ve come across time and again with clients is to automatically generate correspondence via a Workflow or eScript. When automation is the key time and money saver, it’s frustrating for users to have to manually generate correspondence merges using eDocument – why can’t it be automated?

Oracle have made things difficult by driving the generation and submission process from Applet class methods: OnGenerateHTML and OnSubmitHTML. The UI context implied by these methods and their Applet class (CSSFrameListFulfilment) all point to a lack of support for automation.

Generating and submitting a request, with logging turned up on the eDocument component, reveals some interesting information. Specifically, the document server invokes a number of methods on a “Document Generator” Business Service. Now, Oracle state that this is an undocumented Business Service and that it’s use outside of the OnGenerateHTML and OnSubmitHTML methods is “unsupported”. But we’ve never let that stops us messing around, have we?

Invoking the Business Services “OnGenerateHTML” method on its own kicks off the document generation process but immediately crashes the Object Manager. However, closer inspection of the eDocument component log shows an invocation of a parameterless “Start” method, prior to calling any other methods. In our Workflow, calling this prior to the other methods seems to prevent the crash and allows us to generate requests without user intervention:

GenerateCorrespondence

Automate Correspondence Generation in Workflow

Note that the “OnGenerateHTML” method has a single required parameter that is the ROW_ID of a “Correspondence Request” record. Simply use standard Siebel Operation steps in the Workflow to create a record, retrieve the Id and pass it to the method.

There are some great features in Siebel that can make life easier for the developer and improve the experience and ROI for the customer. It’s a real shame that Oracle chooses not to expose and document these for us to take advantage of in a supported solution. Still, it makes the discovery of these little gems all the more satisfying!

Siebel Tools Ate My Hamster

Okay, so Siebel Tools didn’t eat my hamster and I guess I don’t hate Siebel Tools – I’ve used it for over a decade now to design and develop thousands of customisation’s and solutions for customers.

What I really don’t like is it’s lack of progress and this was emphasised today when I read @lex’s post about a Siebel Tools “enhancement” to display line numbers in the eScript editor. If it’s headline news that the eScript editor can now tell you what line you’re on, it’s a sad day for Siebel Tools.

I started work with Siebel when the release version was 99.5 (Siebel 5, I guess). I’ve worked with every other version since then from 6.0, 6.3 to 7.0, 7.5, 7.8, 8.0 and 8.1. All these releases brought something new, especially the 6.3 to 7.0 and 7.8 to 8.1 releases. One thing has remained a constant: Siebel Tools.

6.3 Tools - Look Familiar?

Siebel 7 Tools – Look Familiar?

The version of Siebel Tools that shipped with 5.5, 6.0 and 6.3 is almost indistinguishable from the version shipped today. Sure, Oracle have wrapped it up in Oracle Universal Installer and added some tweaks but it’s almost identical. And it really hasn’t moved on in any useful way for the last 10 years.

I’m calling out to Oracle for the last time – give Siebel Tools some love! It’s an embarrassment – it’s a sad child locked in the cupboard since 1980 with no idea how the world looks or works now. It has a crap hair cut, is wearing a Red Dwarf T-shirt and can’t talk to girls. It needs revamping and here’s what I think we need:

  • Cross Platform – effectively tying Siebel Tools to Windows XP is becoming a massive constraint. It doesn’t work well with 64-bit Windows and it does not work at all with any OS running anything other than Internet Explorer 8. Having to downgrade a Windows 7 IE installation makes other web development tasks a bore and means no developer can unit test and target IE10 or 11 for OpenUI. Not to mention a complete lack of Linux or Mac based support – IntelliJ (even JDeveloper) are laughing at you from above
  • Version Control – do you remember Siebel 6.0? The check in / out process in those days was project level. That meant a single developer would have a whole raft of objects locked out while they tweaked an applet and it was a nightmare to run a large project with many developers. Later versions introduced object level locking but there is still no proper version control in place. Managing releases and multiple code streams is a nightmare in Siebel Tools. When will this nightmare end?
  • Refactoring / Developer Tools – refactoring is such a fundamental tool in any IDE, to allow developers to tweak, tidy and optimise code and configuration with no functional effect. No wonder countless projects end up with unmanageable quantities of eScript and inconsistent configuration as Tools has no such function. There is very little in Siebel Tools to make the developers life better – look at Visual Studio 2013 for examples of how code completion, refactoring, optimisation hints, code checking, automatic comment header generation and so on, can make a developers life so much easier. Better yet, look at the ReSharper plugin for Visual Studio – brilliant tools to allow a developer to focus on a creative solution – not wrestling with the complexities of the development environment
  • An Integrated Debugger – if Siebel is to offer cross functional solutions (eScript, custom class, configuration, Workflow) then a developer must be able to debug consistently across these technologies. If we’re to be encouraged to develop Workflow solutions, at least debug into sub-processes and eScript business services. It’s currently impossible to debug an entire functional area consistently and that is a massive drain on developer productivity.
  • Ditch the SRF – a move to this has already been mentioned but this needs to happen sooner rather than later. Everything in the SRF is in the Repository, so this age old concept of “compiling” some binary representation of the database Repository seems archaic. I wince every time I have to tell the client that their production system is going to be down for 2 hours while I add a list column to an applet. Microsoft Dynamics and SalesForce have beautiful, Web Based IDEs with “Deploy to Live” functionality that I’d give my hind teeth for.
  • Make Tools the IDE – the introduction of CSS, JS and other OpenUI technologies has opened up a world of customisation to Siebel. However, it’s all developed and managed outside of Siebel Tools. The disconnect between the IDE and code is a configuration and release management nightmare as well as a distraction to the developer. Everything needs to be brought back into the IDE with appropriate editors and debuggers. At the moment, it’s a hodgepodge of technologies where nothing is connected.
  • Fix the Workflow Editor – have I mentioned before that I hate the Workflow Process Editor? I’m sure I have. If not, let me reiterate how much I hate the Siebel Workflow Process Editor: I really, really hate it. It’s buggy, old fashioned and no longer fit for purpose. There, I said it. Please fix it!

That’s just a small brain dump of what I think needs to happen to Siebel Tools and it’s the tip of the ice berg.

Come on Oracle, step up and sort Siebel Tools out!

Reflecting on OpenUI and the life of the OpenUI Developer

I’ve spent the last two weeks patching, testing, fixing and tweaking OpenUI in our Public Sector 8.1.1.9 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 8.1.1.9 for now, until we’re authorised to test and deploy IP 2014. The impact of this is that we’re unable to deploy 8.1.1.11 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.

Cloning an Object Manager

Sometimes I look so hard at a problem, I miss the obvious solution. We’re getting ready to deploy OpenUI (yes, I know!) and I’m back trying to clone my Object Manager so as to have OpenUI and HI available to our pilot users.

I’ve messed around with the UI (copy record doesn’t work in Component Definitions and, even if you work around this, it doesn’t Deep Copy) and cfgmerge.exe (which only creates Server Manager scripts when a component exists in both environments) and have generally cobbled together a way to produce an exact copy my component definition.

So imagine my surprise when I happened to be looking in the Server Manager bookshelf pages the other day:

To copy a Siebel Server component definition:

dohAnd there you have it. No messing, no UI, no monkeying around with Server Manager scripts, just a simple way to duplicate your existing OM!

It’s always nice to find an easy way to do something you thought was hard, but on this occasion I’m quite embarrassed that I didn’t know this! Hopefully this will help someone in a similar situation when it comes to preparing for OpenUI pilot roll-outs!