Select Page

Siebel Code Challange – #12

It’s been a while since I ran a Code Challenge. Times are busy, kids are growing, life is hectic. However, I came across some behaviour that was begging to be made into a challenge. As such, I give you this mighty slice of eScript delight!

As usual, no prize of a pint to the first to spot the problem with the following code:

Answers below, please!

Spoiler Inside: Reveal Answer SelectShow

InfoPath Integration And Base64 Decoder

I’ve been working on some functionality within Siebel to “integrate” Microsoft InfoPath. The premise of the requirement is to export an instance of an entity, Account for example, using Siebel EAI and allow a 3rd party, non-Siebel user to view the data in a convenient and useful manner.

InfoPath allows you to define templates based on an XSD. This template can be modified to present an XML instance, using this XSD, in a friendly and readable manner. Perfect for my requirements! However, there’s a snag – isn’t there always? The problem is with File Attachments.

Siebel EAI is really helpful when it comes to extracting file attachments in XML – it will base64 encode the binary file and stick it in a node in the XML. InfoPath does the same thing with file attachments, but it expects a 24 byte header within the base64 encoded file string. This is not something that Siebel does out of the box.

So I wrote a business service that creates that InfoPath header and presents a base64 encoded string that InfoPath is happy with. This business service is invoked in a Data Map that is used to extract the data to my InfoPath XSD.

The solution to building this byte stream header, and encoding everything in a way InfoPath expects, used some eScript functions that I haven’t used before. Specifically, String.fromCharCode() came in really handy as a way of building up an arbitrary byte stream.

For example, InfoPath has a fixed, 4 byte identifier as part of the header. This can easily be created using:

The same principal can be used to create the header size, version and reserved blocks – they are all 4 bytes long. The file size, name and terminator can be constructed using similar principals, using data supplied via EAI in the XML.

The final element of the solution is to decode the Siebel encoded string, append the header, then re-encode. The result is a Base64 encoded string that InfoPath will be happy with.

Here’s the code I used to decode the Siebel encoded attachment string. I pinched the basis for this from Stack Overflow. Thanks to Sniper and broc.sieb for these snippets. Feel free to use this in your own projects, with the usual caveats of course!

That’s it for another post – until next time!

Code Challenge – Improving the Aurora Toolbar

As a quick deviation from messing around with Siebel 15, I thought I’d pose a little challenge to blog readers. Now, this is not in direct competition with the Siebel Hub’s “Coding Challenge” but is in a similar vain. I hope the Siebel Hub Team will forgive me.

Take a look at the screenshot below:



Let me ask you one question: what the hell is with that god-awful toolbar?

“Grey”, “Tangerine”, “Aurora” and “Synergy” have continued to improve both the UI experience and enhance the classes and structures allowing developers to fine tune and customise the look and feel of OpenUI. But what is it with that toolbar? It looks like something from a Windows 95 application of old:


Wordpad in Windows 95

So here’s the challenge:

What changes could you make, or have you made, to make the Aurora toolbar look a little less rubbish?

I’ve enabled the ability to add image attachments to comments, so upload your screenshots below. The best entry will win a voucher for a free* Siebel Hub Trucker Hat. Now could be your time to bridge the infamous gap between the trucker and Siebel communities. This be be your only chance.

Note that simply removing the offending toolbar is not an acceptable entry into the competition.

(* not free)

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!

The Future of Siebel Tools

I’ve worked with Siebel for 15 years now. I started off working for Siebel Systems UK towards the end of 1999. Man, I feel old! I completed “Siebel Bootcamp” using Siebel 6.0 and in those days we were also still supporting customers on Siebel 98 and below. It was a great time and I learned so much from some really talented and clever people.

Times have changed and things have moved on leaps and bounds – though not always in the right direction! Siebel 7 came along, then 7.5 and 7.8. Siebel 8 brought some changes and new functionality and we’re now obviously in the thick of OpenUI and the next generation of Siebel implementations using that technology.

But what of Siebel Tools?

I'm not the only one that feels old

I’m not the only one that feels old

Well, as I say I’ve been working with Siebel for 15 years. I’ve also had the pleasure of working with other tools and languages, including Java and C#. I’ve worked on a number of platforms, including desktop, web and mobile devices. During that time I’ve worked with some awesome IDE’s: Microsoft Visual Studio, Eclipse, Android Studio, Netbeans, Xcode. These toolsets have one thing in common – they make your life easier while working with the technologies and languages that they support. MS VS in particular gets updated regularly with some amazing tweaks and additions – it’s one of the most comfortable, stable and enjoyable working environments that I’ve come across.

And then there’s Siebel Tools.

Okay, I don’t mean to be too harsh but Siebel Tools has not aged well. In fact, it’s hard to pinpoint exactly what changes and improvements, if any, have been implemented in it’s fairly lengthy lifetime. It continues to offer a “front end” to the Repository Tables but that’s really it – it’s missing key components that really make an IDE.

I thought I’d have a go at compiling a list of enhancements for Siebel Tools and ask you guys to add your own. Who knows, maybe one day Larry will come across this blog, spot a good idea and help make the lives of all Siebel Developers out there just a little bit easier? Here’s hoping.

Version Control / Configuration Management

The “Check In / Check Out” functionality in Siebel serves a purpose but the lack of object version control is almost unbelievable. Not being able to track changes, baseline object versions (a la SVN) or revert / diff previous versions is a real challenge. There are some interesting 3rd party tools out there (Enterprise Beacon’s “Object Hive” Tool being one of particular interest) but this should be an integral part of the IDE.  Anyone that dares mention the current “batch file integration” can get to the back of the class. 😉

Oracle also need to provide a better mechanism for providing repository based fixes and enhancements.  If you’ve done an upgrade you’ll know where I’m coming from – Incremental Repository Merge simply adds an unacceptable amount of time, effort and risk to what should be a simple patch upgrade.

Finally, for this section, I’d really like to see packaging and deployment taken seriously. “Application Deployment Manager” still feels incomplete and too clunky to effectively migrate all relevant changes between environments in a controlled way. We need an ANT or a Gradle equivalent. Automation company “Automic” have a product that claims to achieve this goal but I’ve never seen it work in practice nor confirmed that it is “all encompassing”.

Complete Control

Ever since Siebel 7, configuration and code have started to slip away from Siebel Tools. CFG files, Web Templates – there are a number of elements relating to customization and configuration that happen outside of the IDE. Clearly this is appropriate for some elements, but for code items in particular this just seems like a backward step. And no, an option to “set the web template editor to notepad.exe” is not the solution I’m looking for!

This is further compounded, to an unacceptable degree in my opinion, by the introduction of custom JavaScript and CSS with OpenUI. The link there, between IDE and code, has been severed completely while Server Script and Browser Script (whatever that means now in the grand scheme of OpenUI) remain in the Repository. Editing and management of this code has to be brought in to the IDE – not “crowbarred” in with manifest files, application administration and manual deployment of files across various directories and components. How can Oracle enforce standards, ensure compatibility and generally help developers write good code when that code is developed and maintained in utter separation from the development environment?

Emulation / Debugging

The mechanism for testing and debugging still feels incredibly clunky. Having to ensure all my browser windows are closed before debugging is annoying. I’m not able to interrogate the running instance in any way while debugging – aside from the basic watch window and break points in eScript.

The separation of the Workflow and Script debugging tools makes end to end debugging impossible. And don’t get me started on the instability of the workflow simulator – I’ve wasted weeks of my life trying to kick that thing into touch. Why can’t we “step into” sub processes and business service methods? It’s infuriating and time consuming to have to micro test each component and then just hope it all fits together in the end to end process.

Having to compile eScript and relaunch the browser just to test script each time is a pain. We need an integrated debugging and testing environment, where we are in control. If Jason can build “The Harness“, why can’t Oracle do something similar?

Code Completion / Intellisense / Code Management

Siebel 7 introduced syntax highlighting and “Script Assist”, which was a step in the right direction from Siebel 6. However, Script Assist just doesn’t work in a coherent manner. Compared to IntelliSense, it’s a bit of a joke. I want to be able to understand the context of objects that I create and validate my code as I write it. Look at any of the other IDE’s I mention above for examples of how useful such functionality can be. I find it a hindrance in Siebel Tools and often just turn it off.

None of the usual “nice to haves” are present here either – such as refactoring. If you look at Visual Studio again, you’ll also see that the declarative code elements are also supported by visual aids (anchoring, for example, or colour pickers) and validation. Siebel Tools needs to do more to help developers build the right solution, first time.

The Siebel SRF

Ah, the Siebel SRF. Some of you may be old enough, like me, to remember the Siebel 6 days when every client installation of Siebel required the deployment of an SRF. Siebel Remote provided functionality to help you “push” SRF releases out to such clients but it was a nightmare at best – carnage at worst. Imagine having half your user base on a different version of configuration to the other half. Makes you shudder. So, Siebel 7 really helped that with a change requiring that only each Siebel Server require an SRF – you still have to shut everything down, though, and generate browser script manually. However, in this day and age, why are we compiling and deploying files across physical locations at all? There is one certainty in the Siebel world – The Siebel Repository. Everything that makes up the SRF is here – so why “compile” it when every Siebel Component that ever was can connect and read it’s source? If you’ve worked with Microsoft Dynamics CRM, you’ll know how awesome deploying changes from the database can be: one click and your changes are live. To all appropriate users. There has always been the excuse that the SRF is a “performance thing” but this really shouldn’t be the case any more – someone just hasn’t come up with a better way to do it.

Phew! I think that’s enough moaning for one day. Don’t worry, I’ll soon get back to posting more positive and helpful articles as soon as I vent my OpenUI induced grumpiness!

Do you have any suggestions for how Siebel Tools can become the IDE that you’ve always wanted? Do feel free to post your comments and suggestions below.