Funky Town: Non blocking UI

This post is part of the Funky Town series of articles, where we take ridiculous User Centric Design (UCD) requirements and put them into practice.

Imagine that the user

1. Clicks on a button that kicks off a long running report on the server and gets back immediate control of the UI

2. Navigates to another view that fires off several interfaces to get data back

3. As soon as each interface call completes, the screen refreshes with the new data

4. Minutes later the report finishes and the user is presented with a real time browser notification

If the advantages dont jump at you, this list will make it obvious

1. Non blocking UI
2. No nasty polling to maintain
3. Reduced network traffic
4. Less waiting time
5. Real time server to browser notification
6. Parallel processing

This sounds like some modern website, but with a bit of engineering, we can transform Siebel into a more feature rich application.

Basics

Siebel executes code in two modes
1. Synchronous
2. Asynchronous

Synchronous

Server processes invoked by a users session eg. eScript/WFs run synchronously. In other words, you cannot have two pieces of code run in parallel. Synchronous execution freezes the users screen (including any browser side animation) and forces the user to wait until one process has completed before it runs another process.

Asynchronous

Processes can be made to run asynchronously, by dispatching the execution to a background process. This mode provides control back immediately, but a callback is not provided when that process finishes.

However with a little fancy footwork, we can get the best of both worlds. Dispatching code asynchronously with a callback.

Implementation

We will build a button that fires a piece of code that runs on the server for a 10 seconds. The user will be free to do what they choose, and when the server process is complete, a sexy message slides into view, displaying to the user the number of seconds the code took to run.

Ingredients

1. Ajax

Allows us to execute code in the background and get a callback. We will use javascript to launch our background process and listen for the response.

2. Interface

Since the code is triggered client side, we need a browser accessible Siebel interface that allows us to execute code and return some values.

Pick one of the following or come up with your own

A. SWE Querystring
B. XML Command Block
C. SOAP

3. Read Results

I'm going to pick option A. Options B and C will also work, but require dealing with XML payloads and using HTTP POST in javascript, which I'll leave for EAI developers to play with.

The solution entails using Ajax, which dispatches a call to a background process, essentially running synchronous code in a separate session. The user is free to move on and perform other tasks, when the background process finishes, it returns to the browser which registered a callback, the callback function can then notify the user of the results of the process.

4. Proxy

The proxy BS will act as a wrapper to call the intended process, and add the HTTP response headers. These headers are required because invoking a business service using the query string kicks off a server process, which dosnt return a property set to the browser. The proxy business service will convert the outputs into headers that the browser can understand.

5. Session

If we run Ajax calls against our active session, it will still block our UI, so to get around this problem we need a separate Application to offload and invoke our interface. Your second Application can be SI or HI, as long as its different from your active UI session.

The interaction sequence looks like this



There are two key pieces of code that is required for this to work.

1. Ajax Call

The following code is initiated from a button on the browser, and makes a HTTP GET request, using the SWE Querystring API. This querystring calls a Proxy BS, passing in the destination Business Service, Method, and arguments.

It also registers a callback routine to handle the result from the background process. This callback function can take summary data from the server business service and display the results to the users session or it can detect the users view, and refresh data that has been loaded in the background.

var reqUrl = "/Application2/";
reqUrl+="start.swe?SWECmd=ExecuteLogin&SWESetMarkup=XML&SWEDataOnly=1"+
"&ParamBS="+sBS+
"&ParamCallMETH="+sMeth+
"&SWEAC=SWECmd=InvokeMethod&SWEMethod=test&SWEService=MyProxyBS";

var xmlHttp = new XMLHttpRequest();
xmlHttp.open('HEAD', reqUrl, true);
xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {
if (xmlHttp.status == 200 || xmlHttp.status == 204) {

var sResp = ""+
",Status: "+xmlHttp.status+""+
",Result: "+xmlHttp.getResponseHeader("time elapsed");
alert(sResp);
}
}
}


2. Proxy BS

This Proxy BS written in eScript, handles the invokation of the destination Business Service, and creation of the custom HTTP headers. Once this piece of eScript finishes, it returns to the onreadystatechange handler in the code above.

var oBSWeb = TheApplication().GetService("Web Engine HTTP TXN");
oBSWeb.InvokeMethod("GetAllRequestParameters", Inputs, Outputs);

//Get parameters from querystring
var sBSToCall = Outputs.GetProperty("ParamBS");
var sMethToInv = Outputs.GetProperty("ParamCallMETH");          

//Call your BS
//processing time here....
var sElaspedTime="1000";

//set response headers for the browser to read
Inputs.SetProperty("time elapsed",sElaspedTime);
oBSWeb.InvokeMethod("SetResponseHeaders",Inputs,Outputs);


The example above just uses an alert, but an imaginative developer can implement a sexier dialog, or invoke a refresh on the current view

Summary

I've demonstrated usage of the SWE API, but Siebel provides a similar more supportable architecture in the form of an EAI Object manager, making the SOAP interface a more suitable fit.

This is no simple piece of configuration, and it is not recommended that you attempt it without the consultation of your local Siebel Architect. The intention of this article, is to illustrate how Siebel and browser technologies can come together to achieve a solution that was written off as impossible.

This concept was POC'd for client who needed real time notifications for bulk processing, it allowed the user to continue on, and get a fancy notification once the process was completed.

To satisfy our Funky town series, we have to ask ourselves

1. Will it perform well?
Yes, code can be distributed in parallel, and run in the background

2. Is it maintainable?
Yes, if the code is put into a framework, and maintained by an experienced professional

3. Can it be upgraded?
Yes, the solution can be built using a supported architecture, and abstracted through a business services. and

4. Is it sexy?
Yes, its what Siebel Open UI promises to be, except Open UI dosnt do server side callbacks! (Confirmed with Siebel in 4th Qtr 2011)