Posts filed under 'Scripting'
A quick list, for reference:
- Runtime Applet.PreInvokeMethod
- Browser Applet_PreInvokeMethod
- Server WebApplet_PreInvokeMethod
- Runtime BusComp.PreInvokeMethod
- Server BusComp_PreInvokeMethod
- Runtime BusComp.InvokeMethod
- Server BusComp_InvokeMethod
- Runtime Applet.InvokeMethod
- Server WebApplet_InvokeMethod
- Browser Applet_InvokeMethod
Essentially, the Runtime Event occurs before the equivalent server script event for the same object, plus the Applet browser script events ‘wrap’ all server side events.All of which makes perfect logical sense, but it’s sometimes handy to see it written down in a list.
July 19th, 2007
Siebel 7.7.2.3 and 7.8.2 introduced a new eScript engine called the ST eScript engine. The engine supports strong typing, which offers performance improvements at the cost of offending some weak-typing-fundamentalists. Even without rewriting script to define your variables, the new engine is supposed to offer performance and scalability advantages over the old T-eScript engine.
More importantly for the day-to-day life of a hard-coding Siebel developer, the new engine (finally!) offers method listing (known elsewhere as ‘typedown’). This is the feature common to all modern IDEs that pops up a list of child methods of a known-type object, so that the poor developer doesn’t have to remember the precise format of ‘PropertySet.InsertChildAt’. One of those little modern innovations that lets developers get on with concentrating on the flow of their script, rather than the irrelevancies of syntax. Now, Siebel’s implementation is hardly Visual Studio IntelliSense, but it’s useful nonetheless.
To switch on method listing, go to View > Options in Tools, then the Scripting tab, and tick the ‘Enable Method Listing’ checkbox: the associated IDE-improvements ‘Enable Auto Complete’, ‘Enable Warnings’ and ‘Deduce Types’ are also worth having. If you can set all these flags then you’re good to go.
If these settings are all disabled, then you’re not using ST eScript engine. This is an enterprise-wide setting that you might have to sell. Details of the whys and hows are on SupportWeb. In brief: for 7.8 & 8, set the System Preference ‘Enable ST Script Engine’ to TRUE, for 7.7.2.4, change your cfg file to set EnableCLIScripting to TRUE.
July 4th, 2007
Quick question: how do you go about navigating ‘back’ or ‘forward’ in a Siebel 7 application?
Quick answer: use the JavaScript history object.
In Siebel 6 there was the ‘GoBack’ method, but that never made the journey across the thin client chasm. I’ve come across a couple of different methods for Siebel 7, but the history object is by far the most robust and reliable. It’s browser script only, because you’re accessing the native JavaScript object, but that drawback is far outweighed by its simplicity.
To navigate back one step in the history, the code might be:
function Applet_PreInvokeMethod (name, inputPropSet)
{
if( “GoBack” == name )
{
history.go(-1);
return (”CancelOperation”);
}
return (”ContinueOperation”);
}
June 26th, 2007
The Siebel 7 thin-client is marvellous for many reasons, but sometimes it’s necessary to integrate with an old-fashioned, locally installed thick-client application. In Server Script it’s possible to access any DLL by using the eScript SElib.dynamicLink() function, but browser script doesn’t give us the same flexibility.
What we have in the browser is JScript’s ActiveXObject function, which creates an instance of an ActiveX component. For instance, to get the installed version of Microsoft Word, we do:
var wdApp = new ActiveXObject("Word.Application");
alert(wdApp.Version);
No problemo. (Although note that for the function to work, the ActiveX component must be successfully registered).
The big limitation of this function is in the name: it will only talk to OLE Automation (i.e. ActiveX/COM) components. If your client-side object is an old C library then you’ll have no luck. There is a solution, however: open up any installation of Visual Studio (or similar) and whip up a COM wrapper for your old school object. Performance will take a hit, but it saves rewriting applications from scratch.
Siebel’s explanation of ActiveXObject is buried in the upgrade guide - and is missing from some versions of Bookshelf. Find it here. They’ve also got a good technote on creating a COM wrapper, but note that they’re linking the DLL from eScript using COMCreateObject: for browser script use ActiveXObject as above.
April 17th, 2007
A while ago I was implementing the Persistent Customer Dashboard in Siebel 7.8. Generally, the dashboard is linked into CTI and auto-populates customer details when successfully matching an incoming phone number, after which all the customer info remains visible to the user no matter where else they navigate in the application. Some variation of the functionality is standard in most call centres.This particular client wanted to use the functionality in a more manual scenario though, with the users querying for the customer before manually populating the dashboard. That’s pretty easy to do, invoking the ‘Update Dashboard’ method on the Persistent Customer Dashboard business service.
The first complication was that the client didn’t want the dashboard visible by default - I needed to have it open up and populate on demand. That turned out to be also not too tricky: there’s an ‘OpenDashboard’ method on the same Persistent Customer Dashboard business service that does exactly what is says on the tin. [Note: 'OpenDashboard' (no space) and 'Update Dashboard' (with space). Intuitive, non?]
The tricky thing was that we needed to open the dashboard, update the dashboard details and update the source applet - all from a single button click. Problem: the dashboard and the source applet are in different frames, and only one frame can be updated from one UI event. So if I updated the Dashboard, the update to the source applet didn’t happen. And if I updated the source applet…
The solution was to create a second button on the applet to trigger dashboard update in a server script. Add in a browser script to handle the method for the first button, opening up the dashboard from there - and allowing the source applet updates to happen - before using FindActiveXControl to programmatically ‘click’ the second button - giving us a second UI event and the opportunity to populate the dashboard.
Code below…
Server script ‘Update Dashboard’
// Populate the persistent customer dashboard
var bsDashboard;
var psInputs;
var psOutputs;
var AccountId;
bsDashboard = TheApplication().GetService("Persistent Customer Dashboard");
psInputs = TheApplication().NewPropertySet();
psOutputs = TheApplication().NewPropertySet();
AccountId = this.BusComp().GetFieldValue("Account Id");
if( AccountId != "" )
{
psInputs.SetProperty("Source Name","Base View");
psInputs.SetProperty("Buscomp Name", "Account");
psInputs.SetProperty("RowId", AccountId);
bsDashboard.InvokeMethod("Update Dashboard", psInputs, psOutputs);
}
Browser script ‘Select Customer’
// Open up the Persistent Customer Dashboard
var svc = theApplication().GetService('Persistent Customer Dashboard');
var inputs = theApplication().NewPropertySet();
var outputs =theApplication().NewPropertySet();
outputs = svc.InvokeMethod('OpenDashboard', inputs);
// Click the custom 'To Dashboard' button
var obj = this.FindActiveXControl("UpdateDashboard");
// obj.all[0].all[0] locates the Anchor tag.
obj.all[0].all[0].click();
March 2nd, 2007
Next Posts
Previous Posts