The background

I've been working with an external customer recently, on a reasonably small integration component of a Groove deployment. There's an Oracle database, populated nightly from SAP and Siebel systems, which needs to drive some activity in custom tools in Groove spaces; and some of the information being used in Groove should be sent back to the Oracle database, where it'll be directed onward to SAP, Siebel or wherever.

So far, so good. The outline requirements are clear, and reasonably straightforward; I'll use Groove EIS ("bot server") to build a single integration point, 24/7, and the bot will be a member of all the relevant spaces. Since I've worked with EIS before, it was quite straightforward to build out the skeleton of my application: a scheduling strategy, some "space lifetime" management, that sort of stuff.

The actual data transfer (being the raison d'etre of the bot) was a bit more murky, though. To build the bot I'll need: the Oracle table schemas, the Groove tool schemas, and a map of how the data moves from A to B. None - repeat, none - of this information was available.

Frameworking

It quickly became clear that the schemas - and the mechanics of the data transfer - will only be absolutely frozen a few days before this system goes into production. That's not anyone's fault; there are at least four different groups working on the pieces of this, and everyone's working hard.

My bot, sitting pretty on the critical path, needs to be able to accommodate changes quickly. I suspect that there'll be customer-driven changes even after we roll this thing out; and I definitely don't want to be rebuilding and redeploying code for each change.

So, of course, I set to building a framework. My bot reads a configuration file (XML), which specifies exactly how to connect to the database, how to find the tools, and any number of "jobs" which move data from one to the other. There's a mapping table, to take field X into field Y. There's a primitive transformation syntax, to calculate things which aren't a simple field transfer.

So, you can edit the configuration file without even shutting the bot down; changes will take effect immediately. Code become data. But now, the configuration file almost looks like a programming language of its own... state, loops...

Configuration editing

I've used a similar strategy a few times, and it's usually worked pretty well. One downside is that a sufficiently powerful configuration syntax (in XML - so it's verbose and not necessarily too readable) becomes really really difficult for a "non technical user" to maintain.

On the other hand, I couldn't justify the time and expense of writing a full "configuration editor wizard".

Maybe InfoPath would do that job really well, though. It's worth considering for next time. (That link URL says "preview", but I'm sure it's RTM already...!)

So...

One lesson: if you're going to build a framework, decide it early. That way you'll get a good, flexible, road-tested framework. Plan for re-use. And make it easy to use right...