BizTalk coding and design practices - some thoughts

I am sharing some generic points based on my learnings, one should keep in mind while coding and designing BizTalk solutions. Here we go:

·     Follow standard naming conventions for BizTalk artifacts: This is one area which may seem a minor point in the beginning but as the solution grows larger it plays an important role in maintaining the solution. It is a good idea to maintain a guidelines document that everybody on the development team must walkthrough so that there is a consistency across the project in terms of maintaining a standard.

·     Encourage reusability: Before you start writing code, it is advisable to check if the code already exists in BizTalk SDK or somewhere on the internet as an open source e.g. on CodePlex etc. Keep in mind that for each additional line of code, you are also adding an additional maintenance effort. Also in large solution, it is always to check with the other developers whether the utility functions already exist to meet a desired functionality.

·     Before adding any new artifact in the BizTalk solution, check if this is really required? I have seen solutions having multiple message schemas when the functionality could be met with very few of them. E.g. consider using multi part messages for situations where a message needs to exist which is only a combination of two other messages.

Or avoid creating maps where you could construct a simple XML or XLangMessage message in the user code. Just because you need to create another message, you don’t need to use a map. There exist different ways to do this, see Constructing Messages in User Code for more information.

·     Do lot of tracing in the code: Do not hesitate to instrument your code enough. This really helps debugging the problems without getting into the code in many situations. Use features in System.Diagnostics class library to enable tracing your code. With this it becomes easier to turn on/off at run time using configuration. It will also be possible to switch a particular level of tracing on e.g. verbose, error, info etc. Ideally each function should have some tracing enabled with the function duration, passed parameters and how far you did get in your function.

·       Leverage pub-sub architecture of BizTalk: It is very important to understand the way BizTalk server works. Build your systems loosely coupled as much as possible. BizTalk orchestration designer built into VS.Net provides an easy way to drag-drop shapes and define your business processes. But before doing that take some time to really think about how the business process may look like in future? Are there any possibilities of adding any new systems in the future to participate in the current process? Is it easy to plug-in new components to existing process without changing the design too much? Really think hard about the extensibility, and maintainability of the solution. Think about the people who are going to maintain the solution after you build it.

Also, here is a nice code review checklist compiled by Richard Seroter.

Please do leave comments, if any questions or issues or suggestions. Thanks!