Select Page

The Wonderful Workspace

I’ve been around Siebel for nearly 20 years now. Yes, I know I don’t look old enough, but that would be the fresh Scottish air. Siebel has evolved over that time but never to any sort of degree that truly made life better for a Siebel developer. Now, with the release of IP 2017, and just in time for me to move away to do other things, Oracle have given us a game changer: Siebel Workspaces and the SRF’less World.

The clear goal, though a goal that’s not quite achieved, of Web Tools in IP 2017, is to allow configuration of the Siebel Application through the thin client UI. For simple changes, this is largely successful, though Oracle has a lot of work to do to do away with Siebel Tools altogether.

Here’s a walkthrough of the steps to add a new field and expose it on an applet, just to show you how neat Web Tools can be.

  1. Log into Siebel Web Tools
  2. Click the “Workspaces” icon in the top right
  3. From the “Main” branch, click “Create” to create a new Workspace instance, giving it a name and a description
  4. Close the Workspace window, with the big “X” in the top right
  5. Click on “Business Component” and query for “Contact”. Note that, now you have an active Workspace, everything is now editable in Web Tools
  6. Click “Fields” and add a new field:
  7. Now go to “Applets” and query for “Contact List Applet” and click “List” then “List Column” and add a new record:
  8. Go to “Applet Web Template”, click on “Edit List” and click the “Edit” button
  9. Drag our new list column to placeholder 540
  10. Our changes are done – easy peasy!
  11. Now to publish the changes
  12. Go to the Workspace page again
  13. Select your “In Progress” workspace and click “Version” – now this is actually called “Checkpoint” in Siebel Tools but it doesn’t the same thing
  14. Give the checkpoint a name and click the “Version” button
  15. You’re ready to deploy the change!
  16. With your “In Progress” Workspace selected, click the “Submit” button then click the “Deliver” button
  17. Give the delivery a name and click “Deliver” – Web Tools will do its thing!
  18. Now get into your Siebel application, Siebel Call Center in my case
  19. Navigate to “Site Map”, then “Contacts” and finally “Contact List”
  20. Behold your new field – all without an SRF or server restart in sight!

Web Tools is finally on the right path to deliver agility in Siebel development. It’s very clunky in places and you’re still bound to Siebel Tools for many tasks. However, this is a massive leap forward and I can’t wait to see what IP 2018 brings in this space.


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.


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:


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