How Task Automation/Navigation Should Be...

Any .Net programmer of late has heard of the Enterprise Library from Microsoft. It's a collection of code blocks that can automate and harden your code in many different ways. I've used it for over a year, and most of it is great. Most of these are abstractions of the GoF (Gang of Four) patterns that can be used in contemporary programming models.

One of these is the UIP (User Interface process) block provides automation of task and navigation methodologies. It also works in step and flow with the other parts of the EL to provide a common fluid way to automate the user to software interaction and navigation. I can see where in complex business applications this can be handy. I have two problems with this though:

1. It is extremely complicated to use. It involves several "moving" parts that have to be coded in conjunction in order to work.
2. Because of its complexity it takes a long time to implement.

I have written about a piece of software here before that I wrote for my current employer. Its called the Web Scripting System. The nice thing about it is that it completely separates the code from the UI (I'll explain a little later on). The other nice thing is once it is fully mature (right now it is too simplistic to realize its full potential, but it could be sooo powerful) it can be used in so many ways.

The architecture works like this: There is a web service (the Web Scripting Processor). The WSP uses xml files from a database that are called by a simple code. The code can be anything as long as it is unique. The XML file is a "script configuration" of sorts. It contains information about what to do in a normal flow, a disconnected flow and an exception flow. It also contains information about what to display to the end user UI. The latter part is what is simplistic right now.

The flow steps are where the power lies. The Scripting Engine (what the WSP runs in) is a state machine. That means that it is really good at processing states until it hits a state that is has to display something to the user, then it stops processing and sends XML to the caller. The caller then can do with the XML what he needs to in order to display the content. The reason I built it this way is to allow any UI use the system. Primary we had clients that would use both HTML and traditional green screens.

There are 5 main types of states:

1. Display Page: as it describes, this state simply sends parsed XML back to the caller. More about parsing later on.
2. SetVariables: This state performs an evaluation and if it returns true, then it sets a variable.
3. Switch: This state performs both SetVariables and Case Statements. The case statements only go to another state if the evaluation returned true.
4. Command: This performs a remoting call to a script server, passing variables in and then the script executes and returns variables back.
5. Code: This checks to see if the assembly is loaded, and if not it loads the assembly into the app domain and processes a blind method call passing parameters in and getting a result back.
6. Control: Performs a system level command control.

The Command and Code states are the powerful parts. The Command that calls scripts actually uses an "Object Engine" ( a home grown script processor that uses WSH to process COM based JScripts dynamically loaded from a database. It's extremely powerful because it can do just about anything: Make SQL calls, make HTTP Request, Send Mail, File System and so on). The Code state can load a .Net assembly and essentially keep it cached. You can then have access to any .Net component you want. So, if you have some funky logic that you want to execute when a user presses that little button, then you write a small stub and let reflection handle the rest.

So, when you look at the UIP and it talks about tasks and navigation management and switching between UI's, just remember that you have to write, test and deploy compiled code, no matter what you want to do. The Scripting Engine works off a state machine that is for the most part controlled by an XML configuration file for that "task" or set of tasks. What can it be used for?

Examples:
1. A call center needs a script to get "popped" when a call comes in. The pop can be a call to a web server or terminal screen server. The script can be processed and depending on the actions that the agent selects go down certain paths and can provide the agent with content to repeat back to the caller and fields to collect data.

2. A post web chat survey. This would provide everything from a simple flat path set of questions to a complex branching logic set of questions.

3. An IVR engine(almost). An IVR can make request to the web service and process commands and the xml coming back can tell the IVR what prompt to play next.

4. A corporate web site could use the engine to provide either basic navigation and page display to specific task embedded in the script (such as registration or checkout and credit card processing).


What happens to the data? That the ever-so-nice part. You see, every new request creates a session XML file on a centralized file server (NAS in fact). Each response sent back out carries with it your session id. On the return trip the Engine picks up your session data which contains all the variable data you have during that session. The UI's I've written also take advantage of a Heartbeat method in the web service that let's us know the user is still there, but has not click on the page yet.

Once the user hits the last possible state the Engine closes out the session and all the users session data gets logged to a vertical table. That data can be flattened at any time and exported or reported on.

If the heartbeat misses after 10 minutes, we consider the user has aborted and process his session data.

By writhing this article I am not bashing what the EL team at MS has done. The block is impressive, but I think the Scripting Engine can provide something they can't. Once the system is in place, and you have a UI in place then anyone who understands the flow logic they are trying to implement can do so in an exaggerated pace. We had a new developer come on staff and in a few hours was able to start writing a script. It was an extremely complex script that included over 100 "pages" of display, almost all of which contained forms to collect information, and several hundred states of logic flow. He completed the script in less than a week. He admitted that if he had to write asp.net pages and logic to do the same thing it would have taken him over a month.

I don't know if my employer will ever want to sell the system as a stand alone, but I would :).