Making Spaghetti with BizTalk

Last week I went out to assist a client that needed some BizTalk help.  This sounded pretty harmless and from the overview of the system, the job of BizTalk was to accept a request, perform some transformations, validate that certain fields were populated and then communicate with a back end system.  For this type of scenario, a fantastic place to use BizTalk!

I was a little surprised at what I found.  An initial map with 357 functoids and an Orchestration with 44 Sends, 28 Receives, 24 Transformations, 9 Decisions, 2 Loops, 2 Calls to the Business Rules Engine, 8 Request/Response Ports and 10 Request Ports.....wow!  I wasn`t real sure that I could find spaghetti code in a BizTalk Orchestration, but it looks like I just found it.  I printed out the Orchestration...all 27 pages and it reminds me of when I was a kid and mastered the art of the Spirograph.

So how does something that seems so simple turn out to be such a mess  After looking through some of the artifacts, it looks like it`s just a matter of education.  If a developer is new to BizTalk, they just keep adding functoids and orchestrations shapes and eventually they get something working.  The problem is that this becomes a maintenance nightmare and BizTalk becomes the scapegoat.

I`ll try and make some postings in the next few weeks with the following topics:

• Where do I put ConnectionString Information
• How to make reuse of an Orchestration
• What happens if the Legacy system is down  We don`t want the Orchestration to fail
• How can I debug in Production
• How can I use the Business Rules Engine to keep from hardcoding values

Wow, it looks like I have my work cut out for me....hopefully I can answer some of the above questions...check back and see!