Orchestrations
The first question every BizTalk architect asks: where do my orchestrations go? The answer has three parts, most of them were never really orchestrations, the serial ones have a pattern today, and the genuinely stateful ones map to Correlation, which is under active development. Here is the triage.
Every BizTalk shop carries the same scar tissue: orchestrations that one person understood, debugging sessions inside a black box that swallowed messages and state, a designer surface that made the first version fast and every change after it slow. Orchestrations are closed boxes, expensive to design, opaque to operate, brittle to evolve. Art2link ESB excludes them deliberately and composes instead: the same outcomes built from primitives you can see, ports, subscriptions, maps, promoted values, the bus, where every intermediate step is a tracked message you can watch and replay.
Open each orchestration and ask one question: what state does it actually hold between messages? The answer sorts your whole estate:
| Pile | You see | It becomes | Available |
|---|---|---|---|
| 1, Messaging in a trench coat | Receive → transform → send. Maybe a decide shape on a payload value. No waiting, no second message. | A receive port, a map, a send port. No state was ever needed. | Today |
| 2, Routing logic | Decide shapes branching on message content; recipient lists. | Subscription expressions, content-based router, recipient list, filters. | Today |
| 3, Serial iteration | A loop shape walking a collection; debatching with per-item processing. | Splitter / multi-type splitter for fan-out; the countdown loop when items must process strictly in series. | Today |
| 4, Stateful correlation | Correlation sets, parallel convoys, scatter-gather with a timeout, compensation blocks, week-long waits. | Native Correlation and the patterns built on it, below. | Under development |
Estates differ, but the consistent finding when shops actually count is that piles 1–3 dominate, orchestration was the default canvas in BizTalk, so plain messaging flows ended up drawn there. Pile 4 is real but small, and it is the only pile with a timing dependency.
The countdown loop deserves a special mention because it is the orchestration replacement available today for strictly serial work: a per-instance counter variable and a self-republishing send port walk a collection one item at a time, each iteration a visible, tracked message, no engine, no black box. Its one constraint is honest and documented: one loop of a given type runs at a time.
Around it, the shipping catalogue covers the rest of piles 1–3: publish-subscribe, content-based routing, splitting and mixed-envelope splitting, normalization onto canonical types, competing consumers, retry with backoff, dead-lettering, and poison-message handling. Multi-step processes chain through the bus: each stage subscribes to the previous stage’s output type, and the “process” is the visible sum of its messages, normalized, tracked, replayable.
Pile 4 is where BizTalk’s correlation sets earned their keep: hold state for a business key, wake when the matching message arrives, time out when it does not. Native Correlation is under active development as a first-class platform feature, and the patterns built on it are already designed and published as under-development pages so you can evaluate the target architecture now: process manager, correlation convoy, scatter-gather, aggregator, saga / compensation, long-running state, human-in-the-loop, resequencer, request-reply, and async callback. All share one backbone: state lives as messages correlated by key and woken by events, transparent, tracked, replayable, rather than inside an engine.
For migration planning this gives pile 4 two honest options: wait, keep those flows on BizTalk last in your cutover order, well inside the 2028/2030 support window, or redesign, because some convoys exist only to serialize updates or batch by time, and countdown loop or a Scheduler-driven batch flow already covers the need without correlation at all. Triage before you wait.