Summary
Microsoft BizTalk Server has been around for decades, quietly running mission-critical integrations for banks, hospitals, factories, and governments.
While the product is stable and mature, one of the biggest challenges for solution architects is choosing the right implementation pattern for each scenario.
In this post, we’ll explore three key BizTalk solution patterns:
- Pure Messaging solutions
- Orchestration-based solutions
- Custom pipeline component–driven solutions
We’ll look at when to use each, what to avoid, and finish with an at-a-glance recommendation table.
1. Pure Messaging Solutions
What it is:
A BizTalk solution that uses only receive/send ports, custom schemas, and maps.
No orchestrations, no custom pipeline components — just messaging with transformation and routing.
Typical building blocks:
- Custom XML schemas (XSD)
- Maps (XSLT or Functoid-based)
- Static or dynamic send ports
- Port-based filtering (no orchestration shapes)
When to use it:
- Straight-through processing (STP): Input → Validate → Transform → Output.
- No complex decision logic beyond what port filters and maps can handle.
- High-throughput, low-latency scenarios.
- You want minimal maintenance and maximum speed.
Pros:
- Blazing fast compared to orchestration-heavy flows.
- Simpler deployment and debugging.
- Lower CPU/memory footprint.
Cons:
- Limited conditional routing options.
- No long-running stateful processes.
- No advanced exception handling beyond send port retries.
Example:
Receiving an XML purchase order, transforming it to a supplier-specific format, and sending it directly to the supplier’s endpoint.
2. Orchestration-Based Solutions
What it is:
A BizTalk solution with orchestrations that implement business workflows, decision trees, correlation sets, and potentially long-running processes.
Typical building blocks:
- Custom schemas and maps.
- Orchestrations with Receive/Send shapes, Decision shapes, Loops, Parallel processing.
- Correlation sets for stateful processes.
When to use it:
- Multiple sequential steps that depend on intermediate results.
- Complex routing and branching logic not easily handled by filters.
- Long-running processes (hours, days, or weeks).
- Scenarios requiring compensation logic for failures.
Pros:
- Excellent for modeling business processes visually.
- Built-in persistence and dehydration for long-running workflows.
- Easier to apply complex business rules.
Cons:
- More overhead than pure messaging.
- Harder to change without redeploying orchestrations.
- Orchestration persistence can impact throughput.
Example:
A loan approval process where documents arrive, are enriched with customer data from another system, undergo a decision step, and wait for human approval before continuing.
3. Custom Pipeline Component–Driven Solutions
What it is:
Extending BizTalk’s default pipelines with custom receive or send components for specialized processing — often to preprocess messages before mapping or orchestration.
Typical building blocks:
- Custom pipeline components in C#.
- BizTalk standard pipeline stages: Decode, Disassemble, Validate, Resolve Party, Pre-Assemble, Assemble.
- Integration with security, compression, encryption, or protocol-specific formats.
When to use it:
- Non-XML formats requiring specialized parsing (e.g., binary, fixed-width, proprietary).
- Pre-validation, enrichment, or decryption before orchestration.
- Large message optimization (streaming, chunking).
- Logging or auditing that must happen before BizTalk processes the body.
Pros:
- Extreme flexibility for custom protocols and formats.
- Can integrate preprocessing directly into message flow.
- Reduces the need for external preprocessors.
Cons:
- More complex to develop and test.
- Must follow strict streaming and exception handling rules.
- Adds to deployment and maintenance overhead.
Example:
Receiving a compressed binary telemetry file, decompressing it in a custom pipeline component, and passing the decompressed XML into a map.
Choosing the Right Pattern
| Pattern | Use When | Avoid When | Complexity | Performance Impact |
|---|---|---|---|---|
| Pure Messaging | Simple transformations and routing | Long-running or complex workflows | Low | Best |
| Orchestration-Based | Stateful, multi-step business processes | High-volume STP scenarios | Medium-High | Medium |
| Custom Pipeline Components | Specialized preprocessing/parsing | Simple XML scenarios | High | Varies (depends on component) |
Recommendations
- Default to pure messaging whenever possible — it’s faster, simpler, and easier to maintain.
- Introduce orchestrations only for stateful, multi-step processes that cannot be expressed in port filters and maps.
- Use custom pipeline components sparingly — only when standard BizTalk adapters, pipelines, or maps can’t handle your format or preprocessing needs.
- Always consider supportability: BizTalk may run for years without change, so future maintainers must understand your chosen pattern.
Summary
BizTalk is like a toolbox — not every job needs the power drill (orchestration) when a simple screwdriver (pure messaging) will do.
By choosing the lightest pattern that meets your requirements, you keep your integration solutions fast, maintainable, and reliable.
Remember:
Start simple, grow only when the business process truly demands it.
Views: 7
