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.

Using Correlation in Loop

Using Correlation set within a Loop is not a straightforward process in biztalk. One way around this is to define a Scope and within the scope define the correlation sets . This scope will be within the loop . With each iteration of Loop, correlation set will be instantiated again. This approach can lead to overheads due to addtional persistence points in form of transactional scope. Another approach that I recently used in a direct binding scenario is use of "Null Adapter". Have a dummy send shape outside the loop that initiate the correlation set. Use "Null Adapter" with this send port.

DebugViewer in Biztalk

"DebugViewer" is another cool feature that comes with Biztalk 2006. Actually it is part of Studio 2005. Simple steps to use it:

1) Download and Install the tool from http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx.

2) Use System.Diagnostics.Debug.WriteLine ( " Write the Message Here") inside Orchestration to display the message.
3) Check the capture menu on tool to ensure that all options are check marked except the last one (Log Boot). By default they are.
4) You can even filter the events on the viewer. Add a prefix before the message and use this Prefix to filter. Example: Use System.Diagnostics.Debug.WriteLine ( Prefix +" Write the Message Here") . Filter gives both "include" and "exclude" options.

PS: Ensure that you are using "Development/Debug" mode while deploying the assembly. Debug command does not work with"Release/Deployment" mode. This is added benefit of using Debug namespace. There is no need to remove these lines of code while moving from development to deployment version. These lines will be supressed in the deployment version by design. Not quiet the case if System.Diagnostics.EventLog.WriteEntry namespace is used. In that case, these lines will have to be removed when moving from development to deployment version. Else there will be performance hit.