There’s another Siebel User Group event coming up in Sydney. On Thursday 21st August we’re back at the Australia Graduate School of Management for a panel discussion on The Single View of a Customer – Myth or Reality?

I’m personally interested to hear the panellists’ experiences with building business processes around search. Being able to locate an existing customer record is such a fundamental part of maintaining that ’single view’ – yet it’s something Siebel hasn’t totally nailed. Fulcrum in Siebel 6 was limited, Hummingbird in 7 is only an incremental improvement and then in Siebel 8 we seem to have gone backwards again. In the age of Google and Spotlight and (even!) Vista Live Search, I think users should expect better results than come out of the box with Siebel. I wonder if the panellists agree, or if they’ve come up with solutions?

If you’re planning to attend then register now before spaces fill up.

Update Operation

For a simple update to a child entity use a Siebel Operation. When a Workflow Process has a Business Object then a Siebel Operation Update step defined for a child Business Component will update all records that are children of the selected record in the Primary Buisiness Component. The update can be filtered to specific records by specifying  a SearchSpec on the Update.

This technique can be expanded through the use of Runtime Events: define an Event on the child BusComp to catch a simple update operation and trigger further processing of the record.

Bear in mind that for this to work then the Object Id process property must specify a valid record in the Primary Business Component. Also, watch out for this gotcha if you’re trying to dynamically update a field.

Sub Process SearchSpec

An alternative way to process more complicated actions is to call a sub-process for multiple rows. In this case a Workflow Process is defined as normal to act on a single record specified through the Object Id. Then to have this workflow run for multiple rows, define a new ‘wrapper’ workflow and add a Sub Process step to call the original process. To this Sub Process step add the Input Argument SearchSpec, supplying a search specification through the Value in the normal way.

When the wrapper workflow is executed, the SearchSpec is applied to the primary Business Component of the sub-process and the child workflow is run once for each row returned.

I’ve never thought of this, and the key point is worth repeating: script entered into the address bar after a javascript tag is executed by the browser, in exactly the same way as browser script. This means that if you edit the address to be:

javascript:alert(theApplication().GetProfileAttr("Me.First Name"));

…then the browser will popup a message box with the value of the First Name attribute – exactly as you’d expect if this statement was in browser script. Much faster than navigating to Administration – Personalization > Test, plus it retains current context.

Nice quick-and-dirty hack to check (or set) the value of browser objects. Good work, Neel!

var objWSH = new ActiveXObject("WScript.Shell");
objWSH.Run("notepad.exe");

More detail on using the ActiveXObject is available in the post on Client-side DLLS.

This fancy footwork works nicely in the UI, (mostly) displaying numbers in the expected format for the current country. However, imagine a standard Integration Object defined on business component Account, with a component field mapped to the Main Phone Number . Invoke an EAI Siebel Adapter Query for this integration object and the phone number result will be the database value – rather awkwardly including that unpleasant format string.

In older versions of Siebel, the only way around this ‘feature’ was to pass the integration object through a custom business service, stripping those format strings and rendering the phone number as desired: effectively, re-coding the function that Siebel apply at the UI. This was a pain.

Fortunately, Siebel 7.8 saw the introduction of the Integration Object User Property UseFormattedValues to force the EAI Siebel Adapter to use formatted values. If we add this undocumented user property to our Account Integration Object and set the value to Y, then the Siebel Adapter uses formatted values and Main Phone Number will contain exactly what you see in the UI. This eases the pain nicely.

If you’re more familiar with Siebel Scripting, this UseFormattedValues property forces the EAI Adapter to use Get/SetFormattedFieldValue-type requests, rather than Get/SetFieldValue. One restriction is that the User Property can only be applied to the whole Integration Object, not to individual fields – the property doesn’t work as an Integration Object Component User Property, nor as an Integration Object Component Field User Property. That’d be a feature request for future versions…

MetaLink mentions of UseFormattedValues are sparse, but there is a thin definition, plus a complaint about the inbound error handling.

Problem: If a buscomp has code on WriteRecord and the runtime event fires on WriteRecord, which occurs first?
Solution: WriteRecord runtime event is in essence a Post-WriteRecord event and will be fired AFTER the buscomp code is executed.

That statement’s in direct opposition to my assertion that:

…the Runtime Event occurs before the equivalent Server Script event for the same object…

As I responded in the comments, this highlights a mantra I’ve learnt through painful experience: never trust the documentation! However, since my writing here is really just more documentation, it might be useful to explain how I arrived at my list. To get the order of events published previously, I took a random object (BusComp Account Note, as it happens) and modified each browser script and server script event to log the event to a file. For example, the PreWrite looks like this:

function BusComp_PreWriteRecord ()
{
   var f = Clib.fopen("C:\\events.txt", "at");
   Clib.fputs("BusComp_PreWriteRecord\n", f);
   Clib.fclose(f)
   f = null;
   return (ContinueOperation);
}

A similar script on each event gives me an ordered list of script events. To add in the Runtime Events, I created a client-side business service to log to the same file. So in Admistration – Business Service > Details I created the Events business service, then added the Log method using a very similar script. This Log method takes a single parameter: the event string, which is appended to the file.  In Administration – Runtime Events > Events, I can now add every event I want to log, with an action for each to call the Events.Log method with the name of the event. In no time at all, I have a complete, ordered list of  events, as published. Given my testing, I’m inclined to assume the documentation is incorrect. However, all of my testing was only on Siebel 7.8, so there’s a slim chance of variations between versions. Anyone want to verify?

The challenge was in the screen’s List view: here we have the form applet, which works as elsewhere, but also a list applet for the same business component. The behaviour should be the same for both applets. Easy enough, I figured: just copy the form’s browser script across to the list. And this approach appeared to work well enough.

An alert tester picked up the gap: if the operation was started in the list applet, but then completed in the form applet (or vice-versa), then the browser script wasn’t executing. In the first applet the state variable was set, but in the second applet not. What I needed was for the state to be shared across the two applets.

The usual way to share variables across objects is to use Profile Attributes or Global Variables, but neither solution was an option. Global variables simply aren’t available through browser scripts, while the getting and setting of profile attributes requires a round-trip to the server – too much of an overhead in this case. I thought I was going to have to resort to some sort of hidden control and FindApplet then FindControl methods, but the solution was much simpler.

Turns out that variables declared in the general declarations section of Browser Script are shared for all the applets in the view. Who knew? (See the note about halfway down.) Okay, quite possibly everyone except me, but now I won’t forget.

For my little problem, I was able to prescribe that this list applet be only used alongside the form applet, which meant that in the list’s browser script I could simply set and get state using the form’s variable. The applets now share state and everything works as expected.

I spend a lot of time with Workflow: EAI work kind of forces that on you. Any moderately complicated workflow process always ends up needing a stack of workflow process properties. The vanilla processes Siebel provide are good examples of this phenomenon. This is understandable, and equivalent to a scripted function justifiably defining a bunch of local variables. So here’s the thing: when working with processes, why do I always see all the process properties defined to be ‘In/Out’? This is equivalent to a scripted function putting every local variable into the function definition. Crazy talk!

For those who don’t know, the In/Out parameter on a process property defines the purpose of the property. The values are In for input properties, Out for outputs, In/Out (the default) for properties that both accept and return a value, and None for those variables just used internally by the process. Pretty clear cut. Setting this parameter properly makes the workflow easier to understand – particularly helping when calling the workflow as a sub-process. Leaving it as the default In/Out value is lazy config, and I’ve seen too much of it. So there. Someone pass the message on to the developers inside Siebel, please.

P.S. While we’re at it: how about using process property types other than ‘String’ and ‘Hierarchy’ – and that ‘Integration Object’ parameter is pretty useful too…

I’ve moved the new URL at the same time as moving the blog off wordpress.org and onto my own Wordpress installation. Apologies for any difficulty you’ve had while the changes have gone through, but hopefully the TNS and NameServer changes have now circulated around the internet and all your bookmarks and RSS readers have silently adapted to the change. If not, then do update to the new URL. In theory all permalinks etc should be maintained, so please let me know if you see any problems.

I’m seriously impressed with Wordpress. It’s no simple bit of software, yet installation took five minutes and the export & import from Wordpress.org was (I think!) seamless. If only all software installed so easily…

To be honest, a lot of the griping is down to the usual sour grapes that accompany any software release that exposes users to change. I can’t help but be amused by all these enterprise software developers wandering around grumbling about having to deal with a new system that’s “obviously” far inferior from the one they’re used to… these would be the same developers who spend the rest of their time grumbling about the “stupid” users of their systems who can’t cope with the “simple” differences between Siebel 6 and 7… A salutary lesson, perhaps

Forgetting the comparison of the merits of the two systems, I do think it’s a shame that we now have another example of Oracle moving Siebel away from the traditional policy of eating it’s own dogfood. (This is a term for software companies actually using the software they build internally, a practise that is well regarded in the software industry due to it adding internal pressures to improve the product.) Not only do Siebel (the Oracle-subsidiary) no longer use Siebel (the product) as their main CRM system, they also no longer use it for tracking customer service requests. It will be interesting to see whether this change has any impact on the quality and relevance of future Siebel features.

A direct impact the change to MetaLink has had on me is that my stack of SupportWeb deep-links no longer work, including the ones on this blog (thanks Oracle – a redirect would have been nice!). I’ve now been through the site and updated all the links I could find, please let me know if you spot any links that don’t work.