Wednesday, May 6, 2026

Microsoft Azure Integration Services Complete Guide

Microsoft Azure Integration Services — Complete Guide

Logic Apps · Service Bus · API Management · Event Grid · Event Hubs · Integration Patterns · Scenarios · Cheat Sheet

Core Concepts — Basics
Azure Logic Apps — Deep Dive
Azure Service Bus — Deep Dive
Azure API Management — Deep Dive
Integration Patterns — Event Grid & Event Hubs
Scenario-Based Questions
Cheat Sheet — Quick Reference

1. Core Concepts — Basics

What are Azure Integration Services?

Azure Integration Services is a suite of cloud-native services connecting applications, data, and processes across Azure, hybrid, and multi-cloud environments.

Service	Purpose
Azure Logic Apps	Workflow automation and orchestration — visually connect 1,000+ services
Azure Service Bus	Enterprise message broker — reliable, ordered, durable messaging
Azure API Management	API gateway — publish, secure, transform, monitor APIs
Azure Event Grid	Event routing — react to state changes with pub/sub
Azure Event Hubs	Big data streaming — high-throughput event ingestion

Tip: Focus on the "Integration Trinity" — Logic Apps + Service Bus + APIM. Know which service to use for which scenario.

Logic Apps vs Power Automate vs Azure Functions

Logic Apps:
→ Target: IT pros and developers
→ Use: enterprise integration, B2B workflows, system-to-system
→ Hosting: Consumption (serverless) or Standard (dedicated)
→ Connectors: 1,000+ managed connectors (SAP, Salesforce, Oracle)

Power Automate:
→ Target: business users (citizen automators)
→ Use: personal/team productivity, Office 365 automation
→ Hosting: Microsoft-managed SaaS (same engine as Logic Apps)

Azure Functions:
→ Target: developers
→ Use: custom code execution — C#, Python, JavaScript, PowerShell
→ No built-in connectors — write your own integration code

Combined pattern:
Logic App orchestrates workflow → calls Azure Function for complex logic

Logic Apps Consumption vs Standard

	Consumption	Standard
Pricing	Pay per action	Fixed App Service Plan
Scaling	Serverless (scales to zero)	Manual/auto within plan
Workflows per resource	One	Multiple
VNet integration	Not supported	Supported
Built-in connectors	Managed only	Free local execution
Best for	Simple, variable workloads	Enterprise, VNet, regulated

2. Azure Logic Apps — Deep Dive

Logic Apps Workflow Structure

Trigger → Actions → (Conditions/Loops/Scopes) → Response/Output

Common triggers:
Recurrence    → schedule (every 15 min, daily at 9am)
HTTP Request  → webhook URL (push trigger)
Service Bus   → message arrives in queue/topic
Event Grid    → Azure resource events
SharePoint    → list item created/modified
Email         → email received matching criteria

Common actions:
HTTP          → call any REST API
Service Bus   → send/receive messages
SQL/Cosmos    → database read/write
Transform XML → XSLT transformation
Parse JSON    → extract values from payload
Condition     → if/else branching
For Each      → loop over array
Scope         → group actions (error handling)
Terminate     → end workflow (success/failure/cancelled)
Response      → return HTTP response

Error Handling in Logic Apps

1. Retry policies on actions:
Default:     4 retries, exponential backoff (7.5s → 15s → 30s → 60s)
Fixed:       retry every N seconds for N attempts
Exponential: configurable base + max interval
None:        no retry

2. Scope + Run After (try/catch pattern):
Scope: "Try"
  → Action A → Action B

Scope: "Catch"
  RunAfter: "Try" has Failed OR TimedOut OR Skipped
  → Send Teams notification with error + run ID
  → Log to Application Insights
  → Terminate: Failure

3. Run After on individual actions:
Each action configurable: Succeeded | Failed | Skipped | TimedOut
Use: cleanup action that runs even if previous step fails

4. Dead-letter queue monitoring:
Messages failing max delivery → DLQ
Separate Logic App reads DLQ → sends Teams alert → manual reprocess

Tip: The Scope + Run After pattern = try/catch/finally. Every production workflow needs a Catch scope. An uncaught failure with no notification is unacceptable in production.

Logic Apps Connectors

Type	Execution	Cost	Examples
Built-in (Standard)	Local (in Logic Apps runtime)	FREE	HTTP, Service Bus, SQL, Functions, Recurrence
Managed standard	Microsoft-managed	Included	Office 365, SharePoint, Teams, Azure services
Managed premium	Microsoft-managed	Extra cost/execution	SAP, Oracle, MQ, Salesforce
Custom	Microsoft-managed	Managed cost	Any REST/SOAP API via OpenAPI spec
On-premises	Via Data Gateway	Extra	SQL Server on-prem, file shares, SAP

Integration Accounts and B2B

Integration Account stores B2B artefacts:
Trading partners → business entities exchanging EDI/AS2
Agreements       → AS2/EDIFACT/X12 protocol settings
Schemas (XSD)    → validate inbound/outbound messages
Maps (XSLT)      → convert one format to another
Certificates     → X.509 for AS2 signing and encryption

B2B example — EDI X12 850 Purchase Order via AS2:
1. Receive AS2 message
2. Decode AS2: verify signature, decrypt
3. Decode X12: parse EDI envelope → transactions
4. Validate against XSD schema
5. Transform X12 850 → internal JSON order (using Map)
6. Insert to SQL order management system
7. Send 997 Functional Acknowledgement back to supplier

3. Azure Service Bus — Deep Dive

Core Components

Namespace → top-level container (contoso.servicebus.windows.net)

Queue     → point-to-point messaging
           Producer → Queue → ONE consumer
           FIFO ordering within sessions
           Use: order processing, task distribution

Topic     → publish/subscribe
           Publisher → Topic → multiple Subscriptions
           Each subscription gets its own copy of every message
           SQL/Correlation rule filters per subscription
           Use: event broadcasting, multi-system notification

Subscription → logical receiver on a Topic
  Example: Topic "orders"
  → "high-value": filter WHERE amount > 10000
  → "eu-orders":  filter WHERE region = 'EU'
  → "all-orders": no filter

Message properties:
  MessageId      → unique ID (for duplicate detection)
  CorrelationId  → request-reply correlation
  SessionId      → FIFO session grouping
  TimeToLive     → message expiry
  UserProperties → custom key-value metadata

Key Service Bus Features

At-least-once delivery: every message delivered at least once. Consumers MUST be idempotent.
Dead-letter queue (DLQ): messages failing max delivery count preserved for analysis.
Message sessions: FIFO ordering for messages with the same SessionId.
Scheduled delivery: enqueue message for future availability.
Duplicate detection: deduplicate by MessageId within configurable window (up to 7 days).
Transactions: group multiple Service Bus operations atomically.
Message deferral: set aside for later retrieval by sequence number.

Service Bus Tiers

Tier	Features	Use Case
Basic	Queues only, 256 KB, no sessions	Dev/test only
Standard	+ Topics, sessions, transactions, duplicate detection	General integration
Premium	+ 100 MB messages, VNet, Availability Zones, Geo-DR, dedicated MUs	Enterprise, regulated

Choose Premium when: message size > 256 KB, VNet required, compliance needs dedicated infrastructure, or high predictable throughput.

Service Bus vs Azure Storage Queues

	Service Bus	Storage Queues
Max message size	256 KB (Standard) / 100 MB (Premium)	64 KB
Ordering	With sessions	No guarantee
Dead-letter queue	Yes	No
Sessions/Transactions	Yes	No
Pub/Sub (Topics)	Yes	No
Cost	Higher	Very low

Decision:
Need ordering, DLQ, sessions, pub/sub, transactions → Service Bus
Need simple queue, massive volume, minimum cost      → Storage Queues

Competing Consumers Pattern

Service Bus Queue
  ↓ ↓ ↓
Consumer 1 | Consumer 2 | Consumer 3
(each gets a different locked message)

Message lock: prevents other consumers seeing locked messages
Lock duration: configurable (default 60s, max 5 min)

Consumer pattern:
receive message → lock acquired
  try:
    process(message)
    message.complete()    // permanently remove from queue
  catch:
    message.abandon()     // return to queue immediately
  if slow:
    message.renewLock()   // extend before lock expires

4. Azure API Management — Deep Dive

Core Components

API Gateway:
→ Receives all API calls from consumers
→ Validates keys/JWT tokens/certificates
→ Applies rate limits and quotas
→ Transforms requests/responses
→ Routes to backend services
→ Caches responses
→ Logs to Application Insights

Developer Portal:
→ Auto-generated customisable developer website
→ API documentation from OpenAPI spec
→ Interactive Try It testing
→ Self-service API key requests

APIM entities:
APIs          → imported from OpenAPI, WSDL, Functions, Logic Apps
Products      → bundle of APIs with policies (Starter, Professional, Unlimited)
Subscriptions → API key issued to access a Product
Groups        → Administrators / Developers / Guests
Backends      → target services APIM routes requests to

APIM Policies

Four policy execution points: Inbound → Backend → Outbound → On-Error

<policies>
  <inbound>
    <base />
    <!-- Rate limiting per subscription key -->
    <rate-limit calls="100" renewal-period="60" />

    <!-- JWT validation from Entra ID -->
    <validate-jwt header-name="Authorization">
      <openid-config url="https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration" />
      <required-claims>
        <claim name="aud"><value>api://myapi</value></claim>
      </required-claims>
    </validate-jwt>

    <!-- URL rewrite -->
    <rewrite-uri template="/v2/internal/orders" />

    <!-- Add correlation ID -->
    <set-header name="X-Correlation-Id" exists-action="skip">
      <value>@(Guid.NewGuid().ToString())</value>
    </set-header>
  </inbound>

  <backend>
    <base />
    <retry count="3" interval="5" first-fast-retry="true">
      <forward-request />
    </retry>
  </backend>

  <outbound>
    <base />
    <set-header name="X-Powered-By" exists-action="delete" />
    <cache-store duration="60" />
  </outbound>

  <on-error>
    <base />
    <return-response>
      <set-status code="500" reason="Internal Server Error" />
      <set-body>{"error": "An unexpected error occurred"}</set-body>
    </return-response>
  </on-error>
</policies>

Tip: Know the most common policies: rate-limit, quota, validate-jwt, set-header, rewrite-uri, cache-lookup/cache-store, mock-response, return-response, retry, ip-filter.

APIM Tiers

Tier	SLA	VNet	Scale	Best For
Developer	None	No	No scale	Dev/test only
Basic	99.95%	No	1 unit	Low-traffic production
Standard	99.95%	External only	4 units	Moderate traffic
Premium	99.99%	Internal + External	10 units/region	Global, HA, regulated
Consumption	99.95%	No	Serverless	Event-driven, variable traffic

Self-hosted gateway: deploy APIM gateway on-premises as a container — manages local APIs while config stored in cloud APIM. Use for data residency/low-latency requirements.

Products, Subscriptions, and Rate Limiting

Products: bundle APIs with access policies
  Starter:      5 calls/min, 100/day
  Professional: 50 calls/min, 10,000/day
  Unlimited:    no limits

Subscriptions: key passed as Ocp-Apim-Subscription-Key header

Rate limiting policies:
<!-- Per subscription -->
<rate-limit calls="100" renewal-period="60" />

<!-- Per IP address -->
<rate-limit-by-key calls="50" renewal-period="60"
  counter-key="@(context.Request.IpAddress)" />

<!-- Daily quota per subscription -->
<quota calls="10000" renewal-period="86400" />

Throttled response: HTTP 429 + Retry-After header

5. Integration Patterns — Event Grid & Event Hubs

Enterprise Integration Patterns

Pattern	Azure Service
Message Queue (point-to-point)	Service Bus Queue / Storage Queue
Publish/Subscribe (fan-out)	Service Bus Topic / Event Grid
Event Streaming (high-volume)	Azure Event Hubs
Orchestration (central coordinator)	Logic Apps / Durable Functions
Choreography (independent reactions)	Event Grid + independent services
API Gateway	Azure API Management
Saga (distributed transactions)	Logic Apps + Service Bus

Azure Event Grid

Event Grid: push-based pub/sub for state change events

Characteristics:
→ Push-based: events pushed to subscriber webhooks
→ Delivery: at-least-once, HTTP webhooks or Event Hubs endpoint
→ Event size: max 1 MB per event
→ Retention: 24 hours (retry with exponential backoff)
→ Throughput: up to 10 million events/second
→ Cost: pay per event

Built-in event sources:
→ Blob Storage: BlobCreated, BlobDeleted
→ Resource Groups: ResourceWriteSuccess, ResourceDeleteSuccess
→ IoT Hub: device connected/disconnected
→ Key Vault: SecretNearExpiry, SecretExpired
→ Container Registry: ImagePushed
→ Service Bus: ActiveMessagesAvailableWithNoListeners

Use Event Grid when:
→ Reacting to Azure resource state changes
→ Fan-out to many subscribers quickly
→ Serverless event-driven architecture
→ Discrete, low-frequency events

Azure Event Hubs

Event Hubs: big data streaming pipeline (Apache Kafka compatible)

Characteristics:
→ Partitioned log model
→ Throughput: millions of events/second
→ Retention: 1-7 days Standard / up to 90 days Premium
→ Consumer groups: independent readers tracking own offsets
→ Protocol: AMQP, HTTPS, Apache Kafka

Key concepts:
Partition:      ordered event sequence (ordering guaranteed within partition)
Consumer group: independent reader with own position tracking

Use Event Hubs for:
→ IoT telemetry / device readings
→ Click-stream and log analytics
→ Real-time dashboards (feed Stream Analytics / Fabric)
→ Event sourcing (replay from retained log)
→ Apache Kafka migration

Use Service Bus instead when:
→ Need DLQ and message completion acknowledgement
→ Need session-based FIFO ordering
→ Need duplicate detection and transactions
→ Processing must be reliable (order processing, finance)

Rule:
Event Hubs: streaming, analytics — events CAN be missed
Service Bus: messaging, transactions — events MUST be processed

Event Grid vs Event Hubs vs Service Bus

                   Event Grid      Event Hubs       Service Bus
Model:             Push pub/sub    Partitioned log   Pull queue/topic
Max size:          1 MB            1 MB              256 KB / 100 MB
Retention:         24 hours        1-7 days          14 days
Ordering:          No guarantee    Within partition   With sessions
DLQ:               Yes             No                 Yes
Throughput:        10M events/s    Millions/s         Thousands/s
Use for:           State changes   Streaming/analytics  Reliable messaging

6. Scenario-Based Questions

Scenario: Order processing integration between e-commerce and ERP.

E-commerce → Service Bus Topic "orders": publish order JSON with properties: region, order-value, customer-tier.
Topic subscriptions with filters:
- "high-value": order-value > 5000 → approval workflow Logic App
- "eu-orders": region = 'EU' → EU ERP Logic App
- "us-orders": region = 'US' → US ERP Logic App
- "all-orders": no filter → analytics/audit pipeline
Logic App per subscription: receive → transform (JSON→ERP XML via Integration Account map) → call ERP API → complete message on success, abandon on failure.
APIM in front: e-commerce calls single APIM endpoint. APIM abstracts backend Service Bus topology.
DLQ monitoring: Azure Monitor alert on DLQ depth > 10. Operations Logic App reads DLQ, sends Teams alert.

Scenario: API gateway strategy for external partners.

APIM as single entry point: all partner APIs go through APIM — backend microservices never directly exposed.
Products per tier: Basic (100 calls/min, read-only), Standard (500/min, read+write), Premium (unlimited, all APIs).
Security policies: validate-jwt (Entra ID tokens), ip-filter (partner IP allowlist), check-header (X-Partner-Id required).
Transformation: rewrite-uri (partner-friendly → internal paths), json-to-xml (support SOAP partners).
Mock responses: mock-response for APIs under development — partners integrate against contract before backend is ready.
Monitoring: Application Insights — alert on error rate > 5% or P95 latency > 2s.

Scenario: Logic App is failing intermittently on external API calls.

Diagnose: Logic Apps → Run history → expand failed action → inspect status code, error message, request/response body.
Common fixes:
- 429: add exponential retry (5 retries) + delay action before HTTP call
- 408 Timeout: increase HTTP timeout, consider async callback pattern
- 401/403: reference secrets from Key Vault, use Managed Identity
- 400 Bad Request: log request body to Application Insights, verify dynamic expressions

Configure retry policy:

{ "type": "exponential", "count": 5, "interval": "PT10S", "maximumInterval": "PT1H" }

Add Scope + Catch block: log to Application Insights with run ID, send Teams notification.

Scenario: Migrate from BizTalk Server to Azure Integration Services.

BizTalk	Azure Equivalent
Orchestrations	Logic Apps workflows
Maps (XSLT)	Integration Account maps
Schemas (XSD)	Integration Account schemas
Trading partners / EDI	Integration Account partners + agreements
MessageBox	Azure Service Bus
Adapters (SQL, FTP, SAP)	Logic Apps connectors
BAM	Application Insights + Power BI

Strategy: strangler fig — migrate integrations one at a time. Use On-Premises Data Gateway during transition for hybrid connectivity. B2B: recreate trading partner agreements in Integration Account (AS2/EDIFACT/X12 fully supported).

7. Cheat Sheet — Quick Reference

Service Selection Guide

Need to...                                        → Use
Connect services with visual workflow              → Logic Apps
Long-running orchestration / B2B EDI              → Logic Apps + Integration Account
Reliable point-to-point message delivery           → Service Bus Queue
Pub/sub fan-out to multiple consumers              → Service Bus Topic
React to Azure resource state changes              → Event Grid
Ingest millions of telemetry/log events            → Event Hubs
Single secure entry point for all APIs             → API Management
High-volume simple queue (cheapest)                → Storage Queue
Apache Kafka workloads on Azure                    → Event Hubs (Kafka-compatible)
APIs for on-premises systems                       → APIM + Self-hosted gateway
Private/regulated integration workflows            → Logic Apps Standard + VNet

Logic Apps Quick Reference

Trigger types: Recurrence | HTTP | Service Bus | Event Grid | Storage | Email
Error handling: Retry policy + Scope (try/catch) + Run After settings
Connectors:    Built-in (free in Standard) | Managed Standard | Premium | Custom
B2B:           Integration Account (maps, schemas, partners, agreements)
Development:   VS Code + Azure Logic Apps extension (Standard)
Monitoring:    Run history + Application Insights

Service Bus Quick Reference

Tiers: Basic (queues only) | Standard (+ topics) | Premium (+ VNet, 100MB msgs)
At-least-once delivery → consumers must be idempotent
DLQ → failed messages preserved, requires separate monitoring
Sessions → FIFO ordering by SessionId
Duplicate detection → deduplication by MessageId (up to 7 days)
Transactions → atomic multi-operation groups

Message operations:
complete()    → successfully processed, remove permanently
abandon()     → return to queue (retry)
defer()       → set aside for later (retrieve by sequence number)
renewLock()   → extend lock for slow processing
dead-letter() → explicitly move to DLQ

APIM Policy Reference

Inbound:    rate-limit, quota, validate-jwt, ip-filter, check-header,
            rewrite-uri, set-header, cache-lookup, mock-response
Backend:    retry, forward-request, set-backend-service
Outbound:   cache-store, set-header, json-to-xml, find-and-replace
On-Error:   return-response, set-status, set-body

Policy scope hierarchy (most → least specific):
Operation > API > Product > Global
<base /> inherits from parent scope

Top 10 Tips

Know when to use each service — Logic Apps = orchestration. Service Bus = reliable messaging. APIM = API gateway. Event Grid = event routing. Event Hubs = streaming. Mixing these up is an immediate red flag.
Standard Logic Apps for enterprise — if the question involves private networks, regulated environments, or multiple related workflows, always recommend Standard over Consumption.
At-least-once delivery = idempotent consumers — Service Bus guarantees delivery but not exactly-once processing. Always state this constraint when discussing Service Bus consumer design.
APIM policy execution order — Inbound → Backend → Outbound → On-Error. Know which policies go in which section. validate-jwt in Inbound. cache-store in Outbound. This order is always tested.
Service Bus Premium for VNet and large messages — Standard cannot join a VNet. Premium supports 100 MB messages and private endpoints. Know when to recommend Premium.
DLQ needs monitoring — DLQ is not a black hole. Design a monitoring alert + reprocessing workflow for every Service Bus queue/topic in production.
Event Grid for discrete state changes, Event Hubs for streaming — Grid delivers individual events (blob created, resource changed). Hubs ingests continuous high-volume streams. Never confuse these.
Mock responses enable contract-first development — APIM mock-response lets partners integrate before the backend exists. A sign of mature API design.
Scope + Run After = try/catch in Logic Apps — every production Logic App needs a Catch scope. Demonstrate this in any Logic Apps design question.
Know the BizTalk migration mapping — orchestrations → Logic Apps, MessageBox → Service Bus, maps → Integration Account maps, adapters → connectors. This is a senior staple for Microsoft enterprise integration roles.

Wednesday, May 6, 2026