In the early days of the dynamic web a standard called Common Gateway Interface (CGI) emerged as an effective way to augment the static delivery capabilities of the web server via external programs.  The web server would hand the request off to the program, the program would generate the HTML and pass it back to the web server for delivery to the client.

As a proof of concept I've taken this idea and turned it into the 'Workflow Gateway Interface (WGI)'.  I affectionately pronounce it 'woogie'.  Anyway, the idea is to use an external program as the implementation of an action.  LiveCompare packages up the input parameters (including table datasets), invokes the external program and processes any output parameters generated by the program turning them into workflow data types (including table datasets).

A new action has been added to the palette called 'Generic WGI Call'. It starts out with a single parameter - Executable - where the name of the external program is entered. Should we make this a production-grade feature we'll add the necessary administration functionality that will mean you'll pick the program from the list of registered woogies (catchy name eh?). You use the 'Define Action Parameters' wizard to add the program's input and output parameters.  Then it's just a simple matter of running the workflow.

I've written two sample programs.  The first let's LiveCompare interact with the micro-blogging site Twitter.  The program is called TWEET.EXE.  It was written using Microsoft's .NET platform and the Twitterizer library.  So that LiveCompare can find the program I need to copy it to the <ROOT>/WEB/BINN/WGI directory on the LiveCompare server.  All woogies go in this special directory.  Now I add three string input parameters: Username, Password and Message.  For the interface to work I need to make sure the names and types match what the program expects. When I run the workflow, TWEET.EXE sends the value of the Message parameter to Twitter.  You can follow what my LiveCompare installation is up to at: http://twitter.com/livecompare.

The second example offers more practical benefits.  It invokes Yahoo Search returning the top 10 hits (title, summary and URL) for any given search term.  Why might this be useful?  Imagine using LiveCompare to identify the top standard used SAP transactions.  As part of a training/support package you might want to develop a knowledge base of web materials covering these transactions.  Simply pass each transaction in a workflow loop construct to the Yahoo Search woogie and collect the results.  You now have a complete knowledge base for the most used SAP transactions produced automatically.  Set the workflow to run every month so the knowledge base is updated regularly as your SAP usage evolves.

WGI is an experimental feature right now. We need to figure out how best to use it to the advantages of our workflow runners and builders. I'd love to hear your ideas for connecting LiveCompare to the wider world.