This is for all of you who work with Runtime Events and Action Sets in Siebel CRM. Action Sets allow you to define one or more actions to be executed when the associated event occurs. There are three action types: Attribute Set: Set a profile attributeInvokeMethod: Invoke a method on the event objectBusService: Call a business service methodThere are many examples in bookshelf which describe creating an action set to call a built-in business service such as Workflow Process Manager. However when it comes to calling your custom written business service method, then you find a note that you have to use the "Context" property to pass the arguments. What happens when the action is executed is that the Siebel framework creates a property set which contains information about the runtime event and the content of the context field as a string. We can use the EAI XML Write to File business service and its WritePropSet method to send the input property set to a file. This is what the file looks like when your business service is called from an action set: click to enlarge The action set passes the following information: Object Name: The name of the object experiencing the eventBusiness Component Name: The current active BCContext: The content of the Business Service Context fieldAction Set: The name of the action setEvent Type: The type of event (BusComp, Applet or Application)EventId: The ROW_ID of the eventSub Event: The content of the Sub Event field (usually a method or field name)Action: The name of the actionEvent Name: The name of the event such as PreWriteRecord, etc....The developer can now write appropriate code to peruse this information in the business service. Usually you would be most interested in the Context property which normally contains something like the following: "Param1", "Value1", "Param2", "Value2" This is how it is used for standard business services like Workflow Process Manager. Note that the syntax contains strings in double quotes and they are separated by a comma and a space. Of course, for your custom written business service, you could use any other syntax but this may not be "close to the standard" and could cause problems in larger projects where other developers would not be aware of a different context string syntax. So basically you have to split the string into the distinct values. Here is a code snippet which gives you the general idea: //read the string from the input property set var context_string = Inputs.GetProperty("Context"); //the split method creates a char array, we use comma and space as the delimiter var context_array = context_string.split(", "); //now we can get the parameters and values, the odd indexes contain the values //use for() loops for larger arrays... var param1 = context_array[1]; var param2 = contaxt_array[3]; //use the replace() function to cleanse the double quotes from the string //the replace() function uses regular expressions which are a little tricky //see examples here param1 = param1.replace(/\"/g,''); param2 = param2.replace(/\"/g,''); happy scripting ;-)...
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. have fun...
If you use an RSS reader, you can subscribe to a feed of all future entries tagged 'Runtime Events'.