biztalk thoughts

I've been working with BizTalk 2006 R2 for the last few months on a new project and I have to say I'm not a fan. I recognise the advantages of a guaranteed messaging system and business process modelling tool but just can't learn to love it.

As an agile developer who does not use a designer I find the point and click, drag and drop to be anathema to my usual working practices. Rather than develop code you primarily build a set of UI components in a designer to model business processes (using orchestrations), drag and drop links between two schemas (with maps) and provide integration points via administration settings have to be configured and settings tweaked to get the system lined up to integrate the messages.

When it works, it is pretty intuitive - a beginners BizTalk training course sets you in the right direction and you can achieve rather a lot. But where I feel it falls down are the pain points it causes when you want to do something slightly more advanced. Take consuming a java web service as an example - not only was the feasibility spike work for this excruciatingly long but it was frustrating and a severe blow to morale.

I thought the days of empirical trial and error programming were far behind me but that it just what was required with the black box that is BizTalk - when one approach didn't work, we had to think of a new way... trying this led to further pain points and yet another idea of a different direction to go in after searching for similar woes on google.

The kind of thing I'm talking about is generating items via the WCF wizard when pointing at a web service wsdl where 20+ xsd files are created but then won't compile because of incorrect schema locations caused by a namespace split across multiple files. It didn't even work out of the box.

On top of this, using web service references caused mysterious NullReferenceExceptions in the WCF Marshaller classes with very limited stack trace information in the event log.

Not only is this pain energy sapping but it eats into productivity. I'm sure BizTalk experts would have sailed through our problem and could offer us some real insight into how to solve our problem... but most likely only because they have been through the same trial and error process. I'm all for problem solving as that is precisely what we do as developers but building your craft on black box error resolution is definitely not for me.

I haven't had the time to look at other messaging solutions such as NServiceBus, but I hope to do so in the future - relinquishing the fine detail code level control over what I develop is not something I want to buy into and this is precisely what I've had to do with BizTalk.



2 comments:

  1. esntrk1 May 29, 2009 at 7:33 PM

    Justin,

    You are correct. Although you can build solutions based on the SDK samples quickly, it takes some time to develop custom solutions. That is still just the beginning. There's the Business Rules Engine and Business Activity Monitoring. These are advanced concepts that most BizTalk developers don't use on a day-to-day basis. As a result most are weak in these areas. Also there are BizTalk performance and scalability concepts that you must master in order to deploy solutions that do not become maintenance nightmares and/or run slowly while placing an excessive load on SQL server. These are all tricks of the trade that are acquired through both research and experience.

    About your problem, most likely it is caused by the WSDL of the Java web service. The web service wizard is based on the WSDL for a .Net web service. If the Java web service does not render the WSDL in the same way, you will have problems. As a work around you can wrap the Java web service in a .Net web service and run the wizard against the .Net web service. It adds a layer of processing but the performance hit should be neglible. I had the same problem with a Java web service in 2005.

     
  2. Justin Davies June 3, 2009 at 7:23 AM

    Thanks for your comments enstrk1 (and for the advice on the Java service).
    I totally agree that tricks of the BizTalk trade are picked up through research and experience and that was my main point... success through trial and error isn't for me; if it was my choice I wouldn't use it and would certainly try lower level messaging systems that aren't so black box.