Enterprise Integration Patterns — Enterprise Integration Patterns in practice, part 1 of 24. Integration teams often discuss products before they agree on the problem. One architect says Service Bus, another says Logic Apps, and a Boomi developer starts drawing process shapes. All three may be right, but without a shared vocabulary the architecture becomes a collection of product features instead of an intentional system.

Enterprise Integration Patterns gives a technology-neutral language for the forces inside a messaging solution: how messages move, how they are routed, how formats change, how conversations are correlated and how failures are recovered. Azure and Boomi then become implementation choices. This separation makes design reviews faster and prevents a platform feature from being mistaken for the architecture itself.

Enterprise Integration Patterns: the architecture

Start each design with the message contract, delivery guarantee, ordering requirement, correlation key, failure path and operational owner. Only then map the pattern to Azure, Boomi or a hybrid of both. A strong design can explain why each platform owns a responsibility and what happens when any dependency is unavailable.

Implementation on Microsoft Azure

• Use Azure Service Bus for durable commands and business events that require queues, topics, subscriptions, sessions or dead-lettering.
• Use Logic Apps Standard or Durable Functions when a business flow needs explicit state, orchestration and recovery.
• Put Azure API Management at synchronous API boundaries; use Event Grid or Event Hubs only when their event-distribution or streaming semantics match the workload.

Implementation on Boomi

• Use Boomi connectors as channel adapters and keep transport configuration separate from mapping and business rules.
• Use Route, Decision, Map, Try/Catch and Process Call shapes to express routing, translation, recovery and orchestration deliberately.
• Choose a Boomi runtime topology for latency, data residency and availability; the visual process is not a substitute for runtime architecture.

Where the pattern earns its keep

The pattern creates value when it makes coupling, reliability or operational ownership explicit. Name the message boundary, define the contract and prove the failure path. Treat Azure resources and Boomi components as deployable implementations of that decision, with versioning and monitoring that follow the same business identifiers.

A pattern catalogue is not a checklist to implement in full. Every extra router, store and retry path adds latency and operational cost. Use the smallest set of patterns that makes the required reliability visible, testable and supportable.

Run an architecture workshop before choosing services

Start with a ninety-minute pattern workshop involving the business owner, Azure architect, Boomi lead, security representative and the team that will operate the flow. Put one real business message on the table and trace it from producer to final outcome. Capture the happy path, then interrupt every boundary: the broker is unavailable, the Boomi runtime restarts, the target commits but times out, a duplicate arrives and a contract version changes. This turns abstract reliability words into decisions the complete team can review.

The workshop should produce a compact architecture decision record, not only a platform diagram. Record message purpose, producer, consumers, contract owner, authentication identity, delivery and ordering guarantees, throughput assumptions, data classification, retry owner, dead-letter owner, recovery procedure and service-level indicators. Link each item to a named Enterprise Integration Pattern and its Azure or Boomi implementation. The record then becomes the basis for automated tests, deployment reviews and operational runbooks.

Use a deliberate decision sequence. First decide whether the interaction is synchronous, asynchronous or event-driven. Next choose channel semantics and the message contract. Then place routing, transformation and orchestration responsibilities. Finally add observability, idempotency and recovery. This order prevents an attractive connector or workflow designer from deciding the architecture by accident. It also exposes when a hybrid Azure and Boomi solution adds genuine capability and when it merely adds another hand-off.

Production checklist

• Name the business event or command, not the sending application.
• Document delivery, ordering and latency requirements.
• Define a stable message identity and correlation strategy.
• Assign ownership for poison messages and replay.
• Record why Azure, Boomi or both implement each responsibility.

Measure the outcome

Track end-to-end latency, successful business outcomes, retry attempts, duplicate prevention, queue or process age and unresolved failures. Platform availability is useful, but the real service level is whether the business message reached a correct, recoverable outcome inside the promised time.

Frequently asked questions

Is Pattern language an Azure or Boomi feature?

It is an architecture pattern, not a product feature. Azure services and Boomi components implement parts of the pattern. Keeping that distinction clear lets the team compare platforms, test the intended behavior and migrate an implementation without changing the business design.

Can Azure and Boomi implement this pattern together?

Yes. A hybrid design is often strongest when one platform owns each responsibility. For example, Azure can own a durable shared channel while Boomi owns application connectivity and translation. Correlation, security, retry ownership and the recovery path must cross that boundary explicitly.

What should we prove before production?

Prove the unhappy path: dependency outage, duplicate delivery, invalid contract, timeout, restart and controlled replay. Verify the same business identifier is searchable in both platforms and that an operator can recover work without editing payloads or bypassing governance.

Primary references

• www.enterpriseintegrationpatterns.com documentation
• learn.microsoft.com documentation
• help.boomi.com documentation

Continue the series: Message Channel: Azure Service Bus or Boomi Queue? →