Event Handling in Siebel CRM

By @lex on Oct 06, 2008

a great expedition... The following is a subject that has been on my mind ever since I started working with Siebel Scripting, a technique to extend (yes - scripting in Siebel is treated as an "extension language") the functionality of Siebel CRM. Of course many Siebel consultants are familiar with (or have at least several years of exposure to) Siebel Scripting. Sometimes they take it too far and the project is in danger of becoming a house of pain. But let's not delve into details and the horror of bad code, what I really want to show you today is the Siebel event handling model. This is something that every script writer in Siebel is exposed to because the only place where you can write your code are the provided event handlers for scripting, such as PreInvokeMethod on a business service. Hopefully, you heard about Runtime Events, another technique to track events in Siebel in a far more elegant manner than script (sorry about that - I know, I frequently step on your programmers toes). In my classes, I usually do a flipchart drawing on the event model and the so called event flow (which event handler comes first, etc.). It usually looks like this.

click to enlarge I am quite happy with this chart as it points out that the first opportunity to track the event (and execute custom code) is the browser script, then comes the server side with runtime events first(!), then server scripts, etc. But the above flipchart drawing does not tell the whole truth, as there is another way to execute custom code when a method is invoked. Namely named methods (pun intended), user properties you can set on the applet or business component level to invoke other methods or business services.

click to enlarge So it was time for a little experimental setup, which involved creating a small helper business service which allows us to write messages to a trace file. Then I added script code to the applet and business component layer, added named methods and administered runtime events, all of which had the same target: the tracing business service. Below is a code snippet of the tracing helper service, so you get the basic idea. There is some more code than just TheApplication().Trace() because of the fact that action sets in runtime events encode their context in the property set, so you have to unwrap it (which is nice stuff for yet another post, I think).

click to enlarge Now we can place a button control on an applet and use it to invoke our method. Once we have compiled everything and click the button, a trace file is written which contains one line per call of our helper business service thus giving us a clear picture of the event handler execution flow inside Siebel.

click to enlarge Now we can put that information into a nice chart, hopefully useful for all of you who have to extend Siebel functionality with either Scripting, Runtime Events or Named Methods.

click to enjoy ;It wouldn't be Siebel CRM if this would be a complete picture. Of course there are...yes...Signals. This special way to invoke business services as a response to a method invocation has been developed by the team that created the Siebel Order Management module in version 7.8. Signals are only supported by business components that use a special class.