More on Script Assist

A great update on the Script Assist functionality I mentioned a while back. In a comment on my original post, Jake pointed out a “*huge* performance impact when the method listing and autocomplete options were enabled on scripted BCs in v8″.

Now, an anonymous commenter posts that this problem has been recently fixed and “should be available as a QF and in the FixPacks”. The comment also highlights some of the additional scripting improvements in 8.0 that I hadn’t come across – including “Fix & Go” debugging, Siebel’s version of Visual Studio’s “Edit & Continue” – and signposts an “upcoming 8.1 feature, Script Performance Profiler”.

I’m very (inordinately?) pleased with the additional information. Partly because the improvements are all good, legitimate changes that drag Siebel Tools towards with other fully featured development environments, but moreso because it’s great to see an employee of Oracle monitoring and feeding back directly into the development community. This is exactly the sort of thing I was hoping to see when I started the blog… may a thousand geeky conversations bloom

Dynamically Show/hide a Control

The browser script Control method ‘SetProperty’ is fairly limited: it only works at all with CheckBox, ComboBox, TextBox and TextAreas, and even with these controls I’ve found behaviour to be flaky. In my experience it’s more reliable to grab a handle to the control and access the DOM properties directly.

For instance, to conditionally show or hide a control using browser script, the code looks like this:

var ctrl = thisApplet.FindActiveXControl("My Control");

if( ctrl != null )

{

  if( myFlag )

    ctrl.style.visibility="visible";// show control

  else

     ctrl.style.visibility="hidden";// hide control

}

This approach can also be used to set other display properties – like the font and colors – but you have to be a bit more careful with interactive properties: the standard HTML property disabled does not work the same as Siebel’s Enabled control property, for instance.

The best reference I’ve found to the complete set of DOM properties is on MSDN, with the advantage that everything here should be available to Siebel’s IE-only environment.

Order of Events

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.

Enable Script Assist

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.

Navigating through the history thread

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”);

}

Client-side DLLs

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.

Popping up the Persistent Customer Dashboard

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();

Generating Browser Script

When I first needed to add some funky client-side functionality in Siebel 7.5 I was hit with a problem: how to get hold of the browser scripts for testing?

SupportWeb Alert 365 covers using the genbscript utility to build the scripts from the repository using the following format:

genbscript <config_file> <destination_dir> <language_code>

This is all well and good and works fine – I’d recommend the method outlined for migrating browser scripts up to a server.

What the alert fails to mention, though, is that the officially ‘deprecated’ method of letting Tools generate the scripts for you still works. When you compile an object in Tools, any associated browser scripts are generated in the default directory tools_root\public\language_code\srf_timestamp\. This srf_timestamp directory is the same one produced by genbscript – except it only includes scripts for objects you’ve compiled.

For local debugging and unit testing this avoids an extra step. The destination directory for browser scripts can be changed by going to View > Options > Scripting and changing the ‘Browser script compilation folder’. You’ll want to set this to your Mobile Client’s public directory (e.g. Siebel\7.8\client\PUBLIC\enu) .

Then if you also have the usual parameters on the Debug tab pointing at your mobile client, and the location of the Siebel Repository File on the Compile dialog correctly set, then unit testing of browser scripts is a simple Ctrl+F7 > Enter > F5 away…