Posts filed under 'Siebel'
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?
March 30th, 2008
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.
March 27th, 2008
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…
March 3rd, 2008
Don’t we all love MetaLink, Oracle’s replacement for Siebel SupportWeb? Judging from everyone I’ve spoken to, the answer’s a resounding ‘No’!
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.
February 15th, 2008
For all Sydneysiders reading: the next Siebel User Group event will take place on the 21st February. We’re back at the AGSM for a panel discussion on The Role That Siebel Plays In Your Enterprise, after which there’ll be the usual opportunity to catch up with past and future colleagues.
It’s a good broad topic with excellent panellists who I expect them to make my moderating role largely redundant. The last two SUGA events have been oversubscribed well in advance, so get on and register now.
February 7th, 2008
Next Posts
Previous Posts
