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.
- Log into Siebel Web Tools
- Click the “Workspaces” icon in the top right
- From the “Main” branch, click “Create” to create a new Workspace instance, giving it a name and a description
- Close the Workspace window, with the big “X” in the top right
- Click on “Business Component” and query for “Contact”. Note that, now you have an active Workspace, everything is now editable in Web Tools
- Click “Fields” and add a new field:
Name: OLI Life After Siebel Flag
- Now go to “Applets” and query for “Contact List Applet” and click “List” then “List Column” and add a new record:
Name: OLI Life After Siebel
Field: OLI Life After Siebel
Display Name String Override: Life After Siebel?
HTML Icon Map: CHECK
HTML Type: CheckBox
- Go to “Applet Web Template”, click on “Edit List” and click the “Edit” button
- Drag our new list column to placeholder 540
- Our changes are done – easy peasy!
- Now to publish the changes
- Go to the Workspace page again
- Select your “In Progress” workspace and click “Version” – now this is actually called “Checkpoint” in Siebel Tools but it doesn’t the same thing
- Give the checkpoint a name and click the “Version” button
- You’re ready to deploy the change!
- With your “In Progress” Workspace selected, click the “Submit” button then click the “Deliver” button
- Give the delivery a name and click “Deliver” – Web Tools will do its thing!
- Now get into your Siebel application, Siebel Call Center in my case
- Navigate to “Site Map”, then “Contacts” and finally “Contact List”
- 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.
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:
- Create a new BC record, in Siebel Tools, specifying the class ‘CSSBCVExtern’. Call it ‘OLI – User Sessions VBC’
- Create a User Property on your new BC, called Service Name. Give it a value, ‘OLI – User Sessions BS’
- Create a couple of fields in your VBC: ‘CC Alias’ and ‘OM Login’, both as DTYPE_TEXT
- Create a new Business Service called ‘OLI – User Sessions BS’:
- You’ll need an ‘Init’ method:
function Init (Inputs, Outputs)
// Initialise the VBC row property set
Outputs.SetProperty("CC Alias", "");
Outputs.SetProperty("OM Login", "");
- and you’ll need a ‘Query’ method:
function Query(Inputs, Outputs)
// Init the 'Session' VBC
var oSessionBO = TheApplication().GetBusObject("Server Admin - Sessions");
var oSessionBC = oSessionBO.GetBusComp("SA-VBC Session");
// Query for OM Sessions
SetSearchSpec("CC_ALIAS", "LIKE '*ObjMgr*'");
var bIsRecord = FirstRecord();
// Get field values
sUserLogin = GetFieldValue("OM_LOGIN");
sOMAlias = GetFieldValue("CC_ALIAS");
sUserLogin = sUserLogin.toUpperCase();
if (sUserLogin != "SADMIN") // Would have this in SetSearchSpec, but it's ignored by the class underlying 'SA-VBC Session'
// Create new child instance
psSessionRec = TheApplication().NewPropertySet();
// Populate the new child instance
psSessionRec.SetProperty("CC Alias", sOMAlias);
psSessionRec.SetProperty("OM Login", sUserLogin);
// Append 'record' to output PS
bIsRecord = NextRecord();
- Create a new Applet and a new View using the Tools Wizards
- Add the view to a new or existing Screen
- Add the view to a Responsibility
- 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!
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!
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.
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!
I’ve spent the last two weeks patching, testing, fixing and tweaking OpenUI in our Public Sector 126.96.36.199 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 188.8.131.52 for now, until we’re authorised to test and deploy IP 2014. The impact of this is that we’re unable to deploy 184.108.40.206 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!
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.