Enterprise Integration Patterns with Azure
Enterprise Integration Patterns with Azure
Posted inAzure Integration Services

Part 1: Messaging Fundamentals – Blog Series: Enterprise Integration Patterns with Azure

No Comments

In this first post of our blog series on Enterprise Integration Patterns (EIPs) with Azure Integration Services, we’ll explore foundational messaging patterns. These patterns form the backbone of any enterprise integration architecture by defining how information is packaged, transported, accessed, and filtered between decoupled systems.

Whether you’re building an e-commerce platform, banking application, or healthcare data hub, mastering these messaging fundamentals ensures your architecture remains scalable, secure, and reliable.

Each pattern is explained with:

  • ✅ Scenario: What the pattern addresses.
  • 📘 Use Case: A real-world example.
  • 🔄 End-to-End Flow
  • ⚙️ Component Roles in Azure
  • 🛠 Implementation using Azure Services

1. Message

✅ Scenario: A Message is the atomic unit of communication in messaging systems. It encapsulates the data being transferred between systems, along with metadata required for routing, transformation, and processing.

📘 Use Case: An e-commerce application sends order details from its front-end website to a backend ERP system. Each order is encapsulated as a message.

🔄 End-to-End Flow:

  • The web application creates a structured message (JSON/XML) with order details.
  • The message is pushed to a Service Bus queue.
  • A Logic App or Azure Function picks up the message, processes it, and posts it to the ERP system.

⚙️ Component Roles:

  • Web App (Sender): Generates and sends the message.
  • Service Bus (Channel): Carries the message reliably.
  • Logic App/Azure Function (Receiver): Processes and consumes the message.

🛠 Azure Implementation:

  • Use ServiceBusMessage with custom headers.
  • Attach metadata like correlation ID, message type, etc.
  • Handle message retries, dead-lettering, and poison message detection.
[Web App] → [Service Bus Queue] → [Logic App → ERP System]

2. Message Channel

✅ Scenario: A Message Channel is a logical conduit for message delivery between a sender and one or more receivers. It decouples the communication and provides asynchronous delivery.

📘 Use Case: A billing system asynchronously sends invoice generation requests to a print service.

🔄 End-to-End Flow:

  • Billing system sends invoice metadata to a Service Bus Queue.
  • Print Service polls or triggers based on queue messages.

⚙️ Component Roles:

  • Billing System (Sender): Publishes to the queue.
  • Service Bus Queue (Channel): Persists and delivers messages.
  • Print Service (Receiver): Triggers on message arrival.

🛠 Azure Implementation:

  • Use Azure Service Bus Queue for one-to-one delivery.
  • Use Service Bus Topics and Subscriptions for one-to-many pub-sub.
  • Leverage Event Grid for reactive event-driven architectures.
[Billing System] → [Service Bus Queue] → [Print Service (Function or Logic App)]

3. Message Endpoint

✅ Scenario: Message Endpoints are interfaces for applications to send and receive messages. They abstract the messaging infrastructure from business logic.

📘 Use Case: A customer support app exposes an endpoint to receive incoming support requests.

🔄 End-to-End Flow:

  • External systems call the endpoint.
  • Request is validated and routed through integration logic.

⚙️ Component Roles:

  • API Management: Defines and secures endpoints.
  • Logic App or Function App: Implements business logic.
  • Service Bus: Stores message if downstream system is unavailable.

🛠 Azure Implementation:

  • Use Azure API Management to expose HTTP endpoints.
  • Backend Logic App processes the request.
  • Supports retries, authentication, and transformation.
[External Client] → [APIM] → [Logic App] → [Service Bus] → [CRM System]

4. Message Router

✅ Scenario: Directs incoming messages to the appropriate destination based on message content or metadata.

📘 Use Case: A supply chain platform receives product updates and routes them to inventory or shipping systems depending on the product type.

🔄 End-to-End Flow:

  • Product update message arrives.
  • Message Type = ‘InventoryUpdate’ or ‘ShippingUpdate’.
  • Routed accordingly.

⚙️ Component Roles:

  • Logic App/Function App: Implements routing conditions.
  • Service Bus Topics + Subscriptions: Use filters to distribute messages.

🛠 Azure Implementation:

  • Add routing logic in Logic App using Switch or Condition.
  • For more scalability, use Service Bus Topic with SQL Filters.
[Message] → [Logic App → Condition] → [Queue A | Queue B | Queue C]

5. Message Translator

✅ Scenario: Translates a message from one format/schema to another to ensure compatibility between systems.

📘 Use Case: An insurance aggregator needs to convert XML-based claim data from one partner into JSON expected by another partner’s API.

🔄 End-to-End Flow:

  • Receive XML message.
  • Apply transformation.
  • Send as JSON to next system.

⚙️ Component Roles:

  • Logic App: In-built data operations like XML→JSON.
  • Function App: Use custom mapping logic.
  • Mapping API: Use Liquid Templates in API Management.

🛠 Azure Implementation:

  • Use @xml() and json() expressions in Logic Apps.
  • Create reusable mapping functions for complex transformations.
  • Store transformation rules in Azure Blob/Key Vault.
[Partner A] → [Logic App (XML → JSON)] → [Partner B API]

6. Message Filter

✅ Scenario: Filters out irrelevant or unnecessary messages before processing.

📘 Use Case: A fraud detection engine only processes transactions above €1,000.

🔄 End-to-End Flow:

  • Receive transaction.
  • Apply filter condition.
  • Process only qualifying transactions.

⚙️ Component Roles:

  • Logic App: Use conditions to filter.
  • Service Bus Subscription Rule: Use SQL-like filters.

🛠 Azure Implementation:

  • Define Condition in Logic App (e.g., @greater(triggerBody().amount, 1000)).
  • Alternatively, set filter rules on Service Bus Subscriptions.
[Logic App] → If Amount > 1000 → Process → Else → Drop

7. Envelope Wrapper

✅ Scenario: Wraps the core message with metadata required for delivery, routing, security, or versioning.

📘 Use Case: A logistics company wraps package information with tracking metadata.

🔄 End-to-End Flow:

  • Create message body.
  • Add header with version, auth info, tracking ID.
  • Send to downstream system.

⚙️ Component Roles:

  • Logic App: Constructs complete envelope.
  • Function App: Adds security tokens or signs envelope.

🛠 Azure Implementation:

  • Use Compose actions to build structured envelope.
  • Secure with Azure Key Vault-stored tokens or keys.
{
  "Envelope": {
    "Header": {
      "Version": "v2.1",
      "TrackingId": "abc123",
      "Auth": "Bearer XYZ"
    },
    "Body": {
      "PackageId": "PKG001",
      "Destination": "NL"
    }
  }
}

8. Claim Check

✅ Scenario: Separates message payload from metadata by storing large content externally and passing only a reference.

📘 Use Case: A document management system sends a reference to a large legal document stored in Blob Storage instead of the actual file.

🔄 End-to-End Flow:

  • File uploaded to Blob Storage.
  • Logic App sends only a reference (URL + metadata).
  • Receiver fetches document using secure SAS token.

⚙️ Component Roles:

  • Blob Storage: Stores large content.
  • Logic App: Constructs claim check reference.
  • Receiver App: Retrieves full payload.

🛠 Azure Implementation:

  • Generate SAS URL for blob.
  • Include reference in Service Bus message.
  • Receiver validates and downloads from Blob.
[Uploader] → [Blob Storage + SAS URL] → [Queue with URL] → [Receiver downloads blob]

9. Content Filter

✅ Scenario: Removes unnecessary or sensitive data before forwarding a message downstream.

📘 Use Case: A healthcare API removes PII like SSNs before forwarding patient info.

🔄 End-to-End Flow:

  • Receive message with sensitive fields.
  • Remove fields.
  • Send filtered message to target.

⚙️ Component Roles:

  • Function App: Filters out properties based on config.
  • Logic App: Uses Select or Parse JSON to extract required fields.

🛠 Azure Implementation:

  • Use Logic App Data Operations.
  • Maintain filter schema in config (e.g., Blob or Table Storage).
Input: { "SSN": "123-45-6789", "PatientId": 123 }
Output: { "PatientId": 123 }

10. Normalizer

✅ Scenario: Normalizes different data structures or formats into a unified model.

📘 Use Case: A multi-vendor aggregator receives customer orders in varied schemas and normalizes them for internal processing.

🔄 End-to-End Flow:

  • Receive order from Vendor A, B, or C.
  • Identify schema and map to unified structure.
  • Continue downstream processing.

⚙️ Component Roles:

  • Function App: Detects format and transforms.
  • Logic App: Uses conditional logic and mapping templates.

🛠 Azure Implementation:

  • Maintain normalization rules.
  • Use Logic App Switch with transformations.
  • Use Liquid templates in APIM or Logic Apps.
[Vendor A or B or C] → [Normalizer] → [Unified Format Processor]

👉 Up next: Part 2 – Routing Patterns covering Splitter, Aggregator, Resequencer, Routing Slip, and more.

Stay tuned for the full series covering all 65 EIPs with Azure-native designs!

Tags:

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *