Five Rules to Simplify Large Scale BizTalk Orchestration Development

Many times on larger BizTalk projects developers need to share working inside Projects and Orchestrations. This means at some point you will have conflicts. While Visual Studios offers the option to Auto-Merge files, I have not seen this done successfully with BizTalk Orchestrations.

Here are 5 simple rules for simplifying and streamlining large scale BizTalk Orchestration Development.

  • Rule #1 – Do not use the default Operation Name on Orchestration Ports
    • When using Direct Routing Port out of an Orchestration, by default only two properties are routable. Those are MessageType and Operation. If you leave Operation as the default value of Operation_1 all the Ports created will be the same.
    • Operation is one of the most important properties that can be used for routing so make sure it is useful.
  • Rule #2 – Always set up Port Types the right way the first time around
    • If using Direct Routing, always use Direct Routing locally. I see a lot of Specify Now or Specify Later that turns into Direct Routing later on. This causes Binding File changes and could mask errors in routing.
  • Rule #3 – Define all your messages as Multi-Part messages
    • Eventually, the message type of a message used inside the Orchestration will need to change. Ensuring all Messages are setup as Multi-Part messages will make this change trivial as compared to having to change break port connections, change port types, update and message variables.
  • Rule #4 – Ensure each developer has the same folder structure for testing locally
    • This helps simplify changes to binding files. If all the developers use the same structure, a common set of development binding files can be stored in TFS.
  • Rule #5 – Smaller units of work
    • Try to break Orchestrations into small units of work and leverage the Call Orchestration shape. This allows more than one person to work on larger processes and ensures simplified testing. Just ensure the performance hit of using the Call Orchestration is going to be acceptable. While I have not done the testing myself, I think it is a very optimized call and not something I would be worried about in most cases