A little history

I'm currently working in an application integration department of a medical software company. We're using Microsoft BizTalk to hook up our applications with other apps and external vendors. The "usual" vendor uses HL7 as a protocol for which we use the NeoTool HL7 accelerator.

Our software is all windows based which does simplify the matters a bit. The app I'm involved in most is a standard asp based web app. The asp pages call into my teams framework which takes an Xml document, beefs it up with some extra information from a database and passes it on to BizTalk.

This is all well and good, but I have always found this to be a bit heavy handed. In truth it has been rare that we've actually found some functionality in BizTalk that has justified is large price tag (and learning curve.) I have felt from the beginning that BizTalk is a solution looking for a problem.

Here's my biggest beefs:
- the price. I know that it's not out of my pocket, but I like to think I'm corporate minded.
- the learning curve. You just can't jump into the environment without picking up a fair amount on the various tools.
- the shear number of tools you need to use to get a solution going:
- NeoTool DocSpec generator
- BizTalk Editor
- Mapper
- Messaging Manager
- System Administrator/Receive functions
- the lack of integration with SourceSafe
- the clunkiness of the orchestration module
- the inability to have a port deliver back to a channel (or least I can find a way.)
- the brutal Messaging Manager interface
- It looks like a web based app, but doesn't behave like any I've ever seen. There's no way the Microsoft GUI evangelists have seen that thing.
- If you have to change something on the last property page you have to click next on each page
- You create a docspec/port/envelope/organization from the docspec/port/envelope/organization screen, but you create a channel from the port screen. This is inconsistent plus you can't see the other channels when you are creating a new one. If you have a non-trivial naming convention (which we do) you have to remember to copy an existing channel name aside or run a second instance.
- the mapper
- the inability to re-use code
- can't copy/paste
- the hoops you have to jump through just to do something that would be trivial in a normal XSLT file. (Just try to get 2 of a particular output nodes.)
- the focus on the GUI way of building maps. There's no way a B.A. would ever be able to use this tool. Have you ever made a non-trivial map without some custom functoids or some script?
- just let me stuff in some xslt. I had to write an AIC to do so.
- If can't see an error from the suspended items queue. You only get "see the event viewer for error." So you have to hop over to the event viewer and try to find the entry by the timestamp.
- Document tracking is awful. You have to click so many controls on that page just to see some trivial information.
- There's no easy way to script a configuration. The only easy way they give you is to export an existing configuration. How likely is it that you'll have a duplicate of production somewhere? At some point to have to slog through the implementation using the messaging manager and server administrator.
- You can't parameterize an orchestration except from the document itself.

As you can tell I have my opinions on this tool.

As I thought about the problem that BizTalk solves I began to believe (in my own misdirected sort of way) that it doesn't need to be that complicated.

That's where HookUp came from. That's my working title for a application integration system that focuses on the needs of the developer that will be putting these integrations together:
- No fancy GUIs to edit transformations. Odds are that the developer using this system will have their own favourite: XML Spy, Visual Studio, Notepad or like me, CodeWright.
- Focus on the building block approach. Define some blocks and then string them together abitrarily.
- .Net. Admittedly this is more for my benefit (and my resumes) but if it works well for me then it should be helpful for others too.
- Extensibility. You don't like my implementation of an XSLT transformation or a database checkpoint then write your own.

Lofty? Yes. Doable? I think so. We'll know more soon.

Next time: What hookup is now. What it can do. The tools and technologies.