Biztalk Best Practices

We recently finished a Biztalk Project with one of our client. It was a 4 week project with tight deadlines. Our team did a great job to deliver quality product on time. I joined the project midway after 2 weeks and finished error handling and fine tuning. The overall architecture of the project was straight out of “Biztalk Best Practices” book. This was one of the reasons it turned out to be successful. I would recommend everyone this approach as documented by Marty.

Scenario:

1. Main Orchestration A will be kicked off by a web service or a File Drop (as back up)
2. Orch A will send Email informing users using Orch B (Email Orch).
3. Orch A will then trigger 5 Different Orchestration (C,D,E,F and G) in a pre-defined sequence. 4. This sequence will be set up during design time. Some of these orchestrations will execute in
parallel.
5. Each of these orchestrations (C, D,E,F and G) will call Orch B after each call before control
goes to next orchestration in sequence.
6. Users will click on Email and that will trigger web application. This web application will send a "correlation" ID back to one of the orchestration (C,D,E,F and G) and that will complete the orchestration. Thus sending control to next orchestration.

Our approach:

1. Use Multipart messages
2. Use Direct Binding through Message Box to link multiple orchestrations.
3. Use separate project Internal and External Schemas
4. Never expose Internal Schemas directly to entities outside Biztalk.

Great deal of information can be found at:

http://msdn.microsoft.com/msdnmag/issues/07/05/BizTalk/default.aspx

We could have also gone with the (Partner Port) approach. This approach would have reduced some of the Orchestration code we had to put for changing the promoted values to eliminate the chances of "infinite loop". But then we would have lost on "flexibility". and client demanded flexibility.