Introduction

When it comes to orchestrations there are a couple of do's and don'ts. This article will provide you with useful information and resources on best practices for BizTalk orchestrations.

Best Practices

Eliminate orchestrations for messaging only patterns

BizTalk developers sometimes easily tend to use an orchestration to solve a problem or fulfill a requirement, while a messaging only solution would be more suitable. A rule of thumb for every developer should be to minimize the use of orchestrations when it comes to increasing the overall throughput of messages and reduce latency.

Always Use Multi-Part Message Types

You may wonder why should always use multi-part messages. Well when logical ports and Receive/Send shape are using multi-part message types, you can easily change the underlying schema if necessary without having to disconnect the port from the receive shape. This enhances productivity. See also one of best article's on BizTalk programming: 8 Tips And Tricks For Better BizTalk Programming.

Have performance in mind

With orchestrations you have to keep performance in mind when you expecting a large workload. There are some key considerations you have to bear in mind:

Persistence points, the higher number of persistence points the more impact it will have in performance (latency), see Persistence and the Orchestration Engine
Complexity, when orchestration is too complex it will be hard to debug, maintenance cost will high and decreases performance
Use Call Orchestration to improve performance (no round trip to the MessageBox), and enhance reuse of orchestrations.
Minimize the use of logical ports to psychical bound ports when using SQL Server, Oracle, HTTP, WCF, MSMQ, MQSeries, see Optimizing Optimizing Orchestration Performance.
Make appropriate use of .NET classes in orchestrations to maximize performance. Within orchestration you can for instance make use of helper classes. It is a best practice to always mark BizTalk Helper classes with the Serializable keyword, so that the state of the class can be serialized when a BizTalk orchestration is being dehydrated, and it will be properly stored in the MessageBox as well. See Optimizing Optimizing Orchestration Performance.
When you want to aggregate values within an orchestration, use distinguished fields with an orchestration variable to accumulate the result set and do not use a map for it.

Use Patterns

There are a number of patterns available that can help you create stable and robust orchestration, see Implementing Design Patterns in Orchestrations.

Design using direct-bound ports

With BizTalk you have a couple of options when it comes to configuring a port in the orchestration designer: Specify now, Specify later, Direct and Dynamic, see Port Bindings. Direct-Bound ports are an excellent way of sending a message from BizTalk to BizTalk. These ports are self-configured, without sacrificing flexibility or performance. No configuration is necessary to bind them to psychical ports, enhance re-usability and are easier to redeploy independently. There are three Direct-Bound port types: Message Box Routing, Self-Correlating, and Orchestration-to-Orchestration (also called Partner Ports). See MSDN Working with Direct Bound Ports in Orchestrations.

Apply exception handling

Handling exceptions inside orchestration is the similar of doing a “catch { }” block in C#, and it enhances the stability of the orchestration. It is recommended that you include all orchestration shapes in one or multiple scopes (non-transactional scopes whenever possible) and create at least the following exception handler blocks:

An exception handler block for handling a generic System.Exception error.
An exception handler block for handling a general exception in order to catch and handle possible unmanaged errors, such as COM exceptions.

Example of all exception handling options for an orchestration can be found on code gallery: Error Handling.

Separate internal schemas from external schemas

To achieve more loose coupling with your BizTalk solutions it is advisable to separate internal schemas (canonical schema) from external schemas. Latter are schema that you use to communicate with other systems or services. Canonical schema can also be viewed as an internal schema in BizTalk that can aid you in structuring your solution through best practice of creating separate projects for maps, orchestrations, internal and external schemas. It also enhances loose coupling as systems and/or services you are communicating with have no knowledge of each other. Besides that you have more flexibility with changing you orchestration without breaking contract with other systems/services. Mapping between internal and external schemas is best don in ports instead of inside an orchestration.

Properties and distinguished fields

Only promote properties in a schema that are used for message routing, filters, and message correlation. Distinguished fields can be used in an orchestration to set and retrieve values. See also sample Accessing and change message values inside orchestration.

Checklist when developing an orchestration

When you are developing an orchestration the following list can be useful to remind you of best practices applicable for orchestrations:

Each message and variable defined in the orchestration are used by the process
Transactions are used appropriately
All calls to external components are wrapped in an exception-handling Scope
No Expression shape contains an excessive amount of code that could alternately be included in an external component
The Parallel shape is used correctly
The Listen shape is not used in place of transaction timeouts
All Loops have clearly defined exit conditions
Where possible, message transformations are done at the “edges” (i.e. port configurations)
Calling one orchestration from another orchestration is done in a manner that supports upgrades
Correlation is configured appropriately
All messages are created in an efficient manner
The message is not “opened” in unnecessary locations
All variables are explicitly instantiated
No port operations are named the default “Operation_1″
Port Types are reused where possible
All Request/Response ports exposed as a web service are equipped with a SOAP fault message.
Orchestration has trace points inserted to enable debugging in later environments
Orchestration design patterns are used wherever possible