Maps

Maps are a common place to put a lot of logic in a BizTalk solution and it can be a good place. The problem comes, however, with scalability in terms of the growth of large maps and the extension of logic placed within them. It can be hard to track down where a logical decision is being made in BizTalk, when it takes place in a map. Appropriate uses of pages, notations, and documentation can alleviate this, but maps are mostly meant for translation, not for the embodiment of business logic. In fact, avoiding placing business logic in maps is really considered a best practice within the BizTalk community. One benefit to putting logic in maps is that fixes can be made by simply GAC-ing a new assembly and restarting the affected host instances. This can provide low (or no) downtime patching. This generally is not a good enough reason to place logic in maps. Maps are really intended only to perform translation between formats.

Orchestrations

Being graphical, workflows that have similarities to flowchart's orchestrations often seem very familiar to us as developers, even more so with Windows Workflow now in the marketplace, but stuffing too much logic into orchestrations is not a good practice. Orchestrations are focused on message handling, but the decision and looping shapes providing familiar programming constructs to work with and many programmers quickly, equate these with decision and looping constructs in programming languages. The greatest downside of overusing these is that your orchestration canvas grows very large very quickly and making changes becomes cumbersome. Even working in a team environment becomes more difficult in these circumstances. This is similar to creating large methods in C#; it's just not a good practice. Orchestration is not the programming language of BizTalk and should not be treated as a programming language; it is one part of the entire platform that is BizTalk.

Business rules

Not a lot of people use the Business Rules Engine (BRE) in BizTalk and I cannot say I know why, but it could be due to a lack of real world examples and cryptic documentation. I don't believe this tool ever lived up to its original promise of a business analyst friendly tool, but it certainly lives up to my expectations of an effective way to encapsulate logic into a solution in a loosely coupled manner. This is because the rules themselves are deployed independently from the BizTalk solutions that use them. This means they can be updated without changing the solutions that use them. If you have complex decision logic, this is a great tool to implement it. Used correctly, BRE can help you create extensible solutions that can be extended without recompiling your entire solution.

The BRE is an ideal place for logic that is used for routing, and business decisions such as pricing or discounts. There is also the classic example of credit scoring. The BRE is meant to address more rapidly changing logic than orchestration shapes would provide. My favorite way to use BRE is to call rules with XML documents; ideally providing them with all the information they will need, so that they do not need to make external lookups. This focuses the rules on business rule logic rather than on lookup or database logic.

Pipelines and pipeline components

Pipelines are one of the least understood areas of BizTalk, but deserve a lot more credit and attention than they often receive. Almost any .NET component can be called in a custom pipeline component such as BAM and BRE, but great care must be taken not to interfere with the memory model used by BizTalk. Pipeline components can also be used to promote properties or check for duplicate messages. Almost the entire ESB Toolkit for BizTalk is implemented via pipeline components. This allows the developer to use these already created components for a variety of tasks throughout BizTalk from mapping to itinerary processing. Even in the included tool set, pipelines can be used to determine parties and promote or demote properties. Pipeline components are a good example of real reuse in BizTalk, but unfortunately pipelines themselves often are not reused. The parameters for a pipeline can be set in the BizTalk Administration console and they can be set separately for specific receive locations or send ports. This allows us to create a single pipeline that can be reused in multiple places by simply changing the configuration. If less is indeed more, this is a great way to achieve it.

General concept

Ultimately, I believe the downfall of any part of a BizTalk solution is complexity. You should never try to put too much logic into a single place. This is a design tenant well known in OOP—Single Responsibility Principle—but it is one that is easy to lose sight of when working on any platform and BizTalk is no different. BizTalk's graphical focus can actually make this more difficult to avoid at first, as well as the fact that it is not as granular as OOP by nature. Often, if a design is too complex, it should be broken into smaller designs. This advice serves well for maps, orchestrations, rules, and even pipeline components.