Notes On Siebel

Order of Events revisited

SKV commented on my Order of Events post from July pointing out a contradiction he spotted in TechNote 581. On page 20 of that document, point 4. states:

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?

Add comment March 30th, 2008

Shared Browser Script variables

I had a problem the other day where I needed to share a value between two applets. On a form applet there’s a browser script method that executes on the WriteRecord event, but it’s designed to only fire if certain other events have already run. To control the ’state’ (execute or not), there’s a boolean variable declared in the general declarations of the browser script. This form is used in a number of different views and works as designed.

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.

2 comments March 27th, 2008

Defining Workflow Process Properties

Okay, time for a rant. This is bugging me.

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…

3 comments March 3rd, 2008