Wednesday, April 29, 2026

Azure Integration Services Complete Guide

Azure Integration Services — Complete Guide

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

Azure Integration Services Overview
Azure Logic Apps — Deep Dive
Azure Service Bus — Deep Dive
Azure API Management — Deep Dive
Azure Event Grid
Integration Patterns & Architecture
Scenario-Based Questions
Cheat Sheet — Quick Reference

1. Azure Integration Services Overview

What are Azure Integration Services and what problems do they solve?

Azure Integration Services is a suite of cloud services for connecting applications, data, and processes across cloud and on-premises environments.

Service	Purpose
Azure Logic Apps	Workflow orchestration — automate processes and integrate systems using a designer-based workflow engine
Azure Service Bus	Enterprise message broker — reliable, ordered, durable message queuing and pub/sub
Azure API Management (APIM)	API gateway — publish, secure, transform, and monitor APIs
Azure Event Grid	Event routing — reactive, event-driven architecture at scale
Azure Event Hubs	Big data streaming — high-throughput event ingestion (millions/sec)

Key positioning: Logic Apps = orchestration (do things in sequence). Service Bus = decoupling (reliable async messaging). APIM = API facade (secure and manage). Event Grid = events (react to things that happened). Event Hubs = telemetry streaming.

What is the difference between Logic Apps and Power Automate?

Logic Apps and Power Automate share the same underlying engine and connector library.

	Logic Apps	Power Automate
Audience	Developers, IT, enterprise architects	Business users, makers
Hosting	Azure subscription	Microsoft-managed SaaS
Pricing	Pay-per-execution (Consumption) or App Service Plan (Standard)	Per user/flow licence
VNET/private endpoints	Yes (Standard and Premium)	No
Source control / IaC	ARM/Bicep templates, workflow JSON	Solution packages
B2B EDI	Yes (Integration Account)	No
Local development	Yes (VS Code, Standard tier)	No

Tip: Same engine, different audience and infrastructure control. Enterprise integration with VNET, IaC, and B2B = Logic Apps. Business user automation = Power Automate.

What is the difference between Logic Apps Consumption and Standard plans?

	Consumption	Standard
Infrastructure	Shared multi-tenant	Dedicated App Service Plan
Pricing	Pay per action execution	Fixed plan cost
VNET integration	No	Yes
Private endpoints	No	Yes
Workflows per resource	One	Many
Local development	No	Yes (VS Code)
Stateless workflows	No	Yes (much faster)
Best for	Low-volume, simple, quick deploy	Enterprise production, high-volume

What is Azure Event Grid and how does it differ from Service Bus?

	Event Grid	Service Bus
Model	Pub/sub event routing	Message broker
Delivery guarantee	At-least-once	At-least-once with acknowledgement
Ordering	Not guaranteed	FIFO with sessions
Message retention	24h (default, max 7 days)	Up to 14 days
Throughput	10M events/sec	Up to 1000 msg/sec (Premium)
Use for	Something happened — notify subscribers	Message MUST be processed exactly once
Dead letter	Yes	Yes (DLQ)

Use Event Grid when:
→ Azure resource events (blob created, VM deallocated)
→ High-volume, low-latency event fan-out
→ Fire-and-forget is acceptable
→ Many subscribers need the same event

Use Service Bus when:
→ Message MUST be processed exactly once
→ Order of processing matters (sessions)
→ Consumer may be temporarily offline
→ Transactional messaging required
→ Complex routing with filter rules

2. Azure Logic Apps — Deep Dive

What are the key components of a Logic Apps workflow?

Component	Description
Trigger	Starts the workflow. Types: polling, push (webhook), recurrence, manual (HTTP)
Actions	Steps after trigger. Each is a connector operation.
Connectors	Wrappers around APIs. 400+ built-in. Custom connectors via OpenAPI.
Control flow	Condition (if/else), Switch, For Each, Until, Scope
Variables	Mutable state within a workflow run
Expressions	`@{body('action')}`, `@{utcNow()}` — same syntax as Power Automate

What is the difference between stateful and stateless workflows in Logic Apps Standard?

Stateful workflow: each step's input/output persisted in Azure Storage. Full run history available. Can pause for external callbacks or approvals. Supports long-running workflows (days/weeks). Higher latency, higher cost.

Stateless workflow: data kept in memory only — not persisted. No run history. Cannot pause/resume. Maximum duration: minutes. Much faster (no storage I/O). Much lower cost. Best for high-volume synchronous processing.

Tip: Use stateless for high-volume, fast API transformations (hundreds per second). Use stateful for long-running processes, human-in-the-loop approvals, and workflows needing audit trails.

How does error handling work in Logic Apps?

Logic Apps uses the same Run After and Scope patterns as Power Automate:

Try-Catch-Finally pattern:

[Try Scope]
  → Main workflow steps

[Catch Scope]  ← Run After: Try scope → Failed
  → Alert via email/Teams
  → Log to Application Insights
  → Access error: @{result('Try_scope')[0]['error']['message']}
  → Access failed action: @{result('Try_scope')[0]['name']}

[Finally Scope]  ← Run After: Try + Catch → all states
  → Cleanup (always runs)

Retry policy per action:
→ None / Fixed / Exponential
→ Count: 1–90, Interval: configurable
→ Auto-retries on HTTP 408, 429, 5xx

What is an Integration Account in Logic Apps?

An Integration Account is an Azure resource providing B2B EDI integration capabilities.

Feature	Description
Trading partners	Define business partners and their identities
Agreements	Message exchange agreements (send/receive settings)
Schemas	XML schemas for validating/transforming EDI messages
Maps (XSLT)	Transform message formats between partners
Certificates	Message signing and encryption
EDI protocols	AS2 (secure HTTP), X12 (US EDI), EDIFACT (international EDI)

Tip: Integration Account is the answer to any question about B2B EDI, trading partners, or AS2/X12/EDIFACT in Logic Apps .

How do you implement Logic Apps in a DevOps CI/CD pipeline?

Consumption plan (ARM templates):

# Export workflow as ARM template
# Store in Git
# Deploy via Azure CLI or DevOps ARM task
az deployment group create \
  --resource-group myRG \
  --template-file logicapp.json \
  --parameters @params.dev.json

Standard plan (workflow JSON — like Azure Functions):

# GitHub Actions deployment
- name: Deploy Logic App Standard
  uses: Azure/functions-action@v1
  with:
    app-name: my-logic-app-standard
    package: ./src/logicapp

Environment-specific config:

App Settings per environment (dev/test/prod):
→ Connection strings
→ API endpoints
→ Feature flags

Key Vault references for secrets:
@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/apikey)

What are managed connectors vs built-in connectors in Logic Apps Standard?

Managed connectors: run in Microsoft's shared cloud infrastructure. Make outbound calls to external services (Salesforce, SAP, ServiceNow). Subject to connector throttling limits. Same as Power Automate connectors.

Built-in connectors (Standard only): run inside the Logic App's own host process. Faster, no throttling limits. Include: HTTP, Service Bus, Event Hubs, Azure Blob, SQL, Dataverse, B2B operations. Use built-in over managed where available for better performance.

3. Azure Service Bus — Deep Dive

What is Azure Service Bus and what are its key components?

Component	Description
Namespace	Top-level container. Unique hostname: `contoso.servicebus.windows.net`
Queue	Point-to-point. One sender, competing consumers. Each message processed once.
Topic	Pub/sub. One publisher, multiple subscriptions each receiving a copy.
Subscription	Named receiver on a topic. Has its own queue + filter rules.
Message	Body (256KB Standard / 100MB Premium) + system + custom properties

Queue (point-to-point):
Producer → [Queue] → Consumer A (competing)
                   → Consumer B (competing)
→ ONE consumer processes each message

Topic/Subscription (pub/sub):
Publisher → [Topic] → [Sub A: filter Region='EMEA'] → Consumer A
                    → [Sub B: filter Priority='High'] → Consumer B
                    → [Sub C: no filter]              → Consumer C
→ EACH subscription gets its own independent copy

What are Service Bus tiers and which should you use for production?

Tier	Queues	Topics	Max Msg Size	VNET	Best For
Basic	✓	✗	256KB	✗	Dev/test only
Standard	✓	✓	256KB	✗	Low-criticality workloads
Premium	✓	✓	100MB	✓	Enterprise production

Premium features: dedicated capacity units, geo-disaster recovery, VNET/private endpoints, predictable performance, availability zones.

Warning: Always use Premium for enterprise production — dedicated resources, VNET integration, and predictable latency. Standard has noisy neighbour risk and no network isolation.

What is the Dead Letter Queue (DLQ) and when are messages sent to it?

The DLQ is a sub-queue storing messages that cannot be processed. Every queue and subscription has its own DLQ.

Messages are dead-lettered when:

Max delivery count exceeded — consumer abandons (nacks) message more than MaxDeliveryCount times (default: 10)
TTL expired — message not consumed before Time-To-Live expires (if dead-lettering on expiry enabled)
Subscription filter error — filter expression throws an exception
Consumer explicitly dead-letters — calls deadLetterAsync() for unprocessable messages

DLQ message properties:
DeadLetterReason            → WHY it was dead-lettered
DeadLetterErrorDescription  → Detailed error message
EnqueuedTimeUtc             → When original message was sent
DeliveryCount               → How many times delivery was attempted

DLQ path:
Queue: myqueue/$DeadLetterQueue
Subscription: mytopic/mysubscription/$DeadLetterQueue

Critical: An overflowing DLQ means data loss. Always monitor DLQ counts with Azure Monitor alerts and have a process for reviewing, resubmitting, or archiving dead-lettered messages.

What are Sessions in Service Bus and when do you use them?

Sessions enable FIFO ordered processing of related messages. A session groups messages by SessionId — all messages with the same SessionId are processed in order by the same consumer instance.

Without sessions (no ordering guarantee):
Producer sends: Order-123-Created, Order-123-Paid, Order-123-Shipped
3 competing consumers → may process Shipped before Paid → wrong state

With sessions (SessionId = "Order-123"):
→ All messages with SessionId="Order-123" locked to ONE consumer
→ Processed in order: Created → Paid → Shipped
→ Other sessions (Order-456, Order-789) processed in parallel by other consumers
→ Scale: number of concurrent sessions = throughput

Enable sessions on queue/subscription:
RequiresSession = true (must be set at creation time)

Send with session:
message.SessionId = orderId;

Receive with session:
var session = await receiver.AcceptNextSessionAsync();

Tip: Sessions are the answer to "how do you guarantee message ordering in Service Bus." Without sessions, ordering is not guaranteed even with a single consumer.

What is the difference between peek-lock and receive-and-delete?

Peek-Lock (recommended):

Consumer receives message — it is locked (invisible to others) for lock duration
Consumer processes and calls Complete() → deleted from queue
Or calls Abandon() → released back to queue for retry
Or calls DeadLetter() → moved to DLQ
If consumer crashes — lock expires, message re-queues automatically
Guaranteed at-least-once delivery

Receive-and-Delete:

Message deleted immediately on receive
If consumer crashes after receive but before processing → message is permanently lost
Use only for non-critical, idempotent scenarios (metrics, logging)

Warning: Always use Peek-Lock for business-critical messages. Receive-and-Delete risks data loss if the consumer fails between receiving and completing processing.

What is duplicate detection in Service Bus?

Duplicate detection allows Service Bus to discard messages with a previously seen MessageId within a configurable time window (1 min – 7 days).

// Enable at queue/topic creation:
new CreateQueueOptions("myqueue") {
  RequiresDuplicateDetection = true,
  DuplicateDetectionHistoryTimeWindow = TimeSpan.FromMinutes(10)
};

// Set MessageId on the sender side:
var message = new ServiceBusMessage(body) {
  MessageId = $"{orderId}-{timestamp}"
};

Use when producers may retry sending on network failure — prevents double-processing of the same business event.

4. Azure API Management — Deep Dive

What is Azure API Management and what problem does it solve?

Azure API Management (APIM) is a fully managed API gateway between API consumers (clients) and API backends.

Core capabilities:

Capability	Description
Security	OAuth 2.0, JWT validation, subscription keys, client certificates, IP filtering
Rate limiting	Rate limit and quota per subscription, IP, or custom key
Transformation	Modify requests/responses without touching backend code
Versioning	Manage multiple API versions, route to different backends
Developer portal	Self-service API documentation and subscription management
Caching	Cache responses to reduce backend load
Analytics	Request logs, metrics, tracing via Azure Monitor + Application Insights

Key value: Decouple API consumers from backends. Backend can change without consumers knowing — APIM handles the translation.

What are APIM policies and what are the most important ones to know?

Policies are XML-based rules applied in four sections: inbound, backend, outbound, on-error.

<policies>
  <inbound>
    <!-- Validate JWT (Entra ID) -->
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
      <openid-config url="https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration"/>
      <required-claims>
        <claim name="aud"><value>api://my-api-id</value></claim>
      </required-claims>
    </validate-jwt>

    <!-- Rate limit per subscription: 100 calls/60s -->
    <rate-limit-by-key calls="100" renewal-period="60"
      counter-key="@(context.Subscription.Id)"/>

    <!-- Add internal key to backend request -->
    <set-header name="X-Internal-Key" exists-action="override">
      <value>{{internal-api-key-named-value}}</value>
    </set-header>

    <!-- Route to different backend based on header -->
    <choose>
      <when condition="@(context.Request.Headers.GetValueOrDefault('X-Version','v1') == 'v2')">
        <set-backend-service base-url="https://v2.api.backend.com"/>
      </when>
      <otherwise>
        <set-backend-service base-url="https://v1.api.backend.com"/>
      </otherwise>
    </choose>
  </inbound>

  <outbound>
    <!-- Remove internal header from response -->
    <set-header name="X-Powered-By" exists-action="delete"/>
    <!-- Cache successful responses for 5 minutes -->
    <cache-store duration="300"/>
    <!-- Transform XML response to JSON -->
    <xml-to-json kind="direct" apply="always"/>
  </outbound>

  <on-error>
    <return-response>
      <set-status code="@((int)context.Response.StatusCode)" reason="@(context.Response.StatusReason)"/>
      <set-body>@("Error: " + context.LastError.Message)</set-body>
    </return-response>
  </on-error>
</policies>

What are APIM tiers?

Tier	SLA	VNET	Multi-region	Scale Units	Best For
Developer	None	No	No	1	Dev/test only
Basic	99.95%	No	No	2	Small, non-critical
Standard	99.95%	No	No	4	Medium volume
Premium	99.99%	Yes	Yes	31	Enterprise production
Consumption	99.95%	No	No	Serverless	Very low volume, serverless

Tip: Premium is the only tier with VNET integration and multi-region deployment. Required when backends are in private networks or when global availability is needed.

What are APIM Products, APIs, and Subscriptions?

API: a backend service exposed through APIM
  → Has operations: GET /orders, POST /orders, DELETE /orders/{id}
  → Has policies applied at API or operation level

Product: a bundle of one or more APIs
  → Controls access: who can subscribe
  → Applies shared rate limits and quotas
  → Types: Open (no approval needed) | Protected (subscription required)

Subscription: a consumer's access key to a Product
  → Primary and secondary keys (for key rotation without downtime)
  → Passed in header: Ocp-Apim-Subscription-Key: {key}
  → Can be scoped to: All APIs | Product | Single API

Example:
APIs: Orders, Inventory, Customers, Analytics

Products:
  "Developer Tier" → Orders API only, 10 calls/min, free
  "Standard Tier"  → Orders + Inventory, 100 calls/min
  "Enterprise"     → All APIs, 1000 calls/min, SLA guaranteed

Consumer A subscribes to "Standard Tier":
→ Gets subscription key
→ Can call Orders and Inventory up to 100 calls/min
→ Cannot call Customers or Analytics

How do you implement API versioning in APIM?

Three versioning schemes:

Scheme	URL Format	Example
URL path	`/v{version}/resource`	`/v1/orders`, `/v2/orders`
Query string	`/resource?api-version={ver}`	`/orders?api-version=2024-01-01`
Header	`Api-Version: {version}`	Header: `Api-Version: 2024-01-01`

Each version can point to a different backend, have different policies, and be independently documented. A version set groups all versions together in the developer portal.

Tip: Always create a version set when deploying v1. Retrofitting versioning to an existing API with consumers is painful and disruptive.

What are Named Values in APIM and why are they important?

Named Values (formerly Properties) are key-value pairs stored in APIM and referenced in policies using {{name}} syntax.

<!-- Instead of hardcoding: -->
<set-header name="X-API-Key"><value>abc123supersecret</value></set-header>

<!-- Use Named Value: -->
<set-header name="X-API-Key"><value>{{backend-api-key}}</value></set-header>

Types:

Plain: static string value
Secret: encrypted, not visible after saving
Key Vault reference: value retrieved from Azure Key Vault at runtime

Best practice: Always use Named Values (preferably Key Vault-backed) for secrets and environment-specific values in APIM policies. Never hardcode secrets in policy XML.

5. Azure Event Grid

What is Azure Event Grid and what are its key components?

Event Grid is a fully managed event routing service for building reactive, event-driven architectures.

Component	Description
Event source	What emits events: Azure resources (Blob Storage, Resource Groups, Service Bus) or custom apps
Topic	Endpoint where events are sent. System topics (Azure resources) or custom topics
Event subscription	Maps a topic to an event handler with optional filter rules
Event handler	What processes the event: Azure Functions, Logic Apps, Event Hubs, Service Bus, Webhooks

Azure Blob Storage (event source)
  → BlobCreated event published to System Topic
  → Event Grid routes to:
    Subscription 1 (filter: blobType=image) → Azure Function (resize image)
    Subscription 2 (no filter) → Logic App (archive to cold storage)
    Subscription 3 (filter: container=reports) → Power Automate (notify team)

When should you use Event Grid vs Event Hubs vs Service Bus?

Event Grid:
→ Discrete events (something happened)
→ Azure resource events (blob created, VM stopped)
→ Low volume, reactive architecture
→ Fan-out to many subscribers
→ Events expire after 24h–7 days

Event Hubs:
→ High-throughput streaming (millions/sec)
→ Time-series data, telemetry, logs
→ Replay capability (retention up to 90 days)
→ Big data pipelines (Spark, Stream Analytics)

Service Bus:
→ Reliable transactional messaging
→ Message must be processed exactly once
→ Order matters (sessions)
→ Consumer may be offline
→ Complex routing with business rules

6. Integration Patterns & Architecture

What is the Competing Consumers pattern?

Multiple consumer instances process messages from a single queue concurrently — scaling throughput horizontally. Each message processed by exactly one consumer.

Service Bus Queue with 3 consumers:
Producer → [Queue: 1000 messages]
  Consumer 1 (Azure Function instance) ← picks up messages
  Consumer 2 (Azure Function instance) ← picks up messages
  Consumer 3 (Azure Function instance) ← picks up messages

→ Each message processed by EXACTLY ONE consumer
→ Scale out by adding consumers
→ Azure Functions + Service Bus trigger auto-scales based on queue depth

What is the Saga pattern and how do you implement it?

The Saga pattern manages long-running distributed transactions without a central transaction coordinator. Each step publishes an event; compensating transactions undo completed steps if a later step fails.

Order Processing Saga — Orchestration (Logic App):

Step 1: Reserve Inventory API
  → Success: continue
  → Failure: STOP (nothing to compensate)

Step 2: Charge Payment API
  → Success: continue
  → Failure: call Inventory API to RELEASE reservation (compensate Step 1)

Step 3: Create Shipment API
  → Success: Saga complete
  → Failure: call Payment API to REFUND (compensate Step 2)
           + call Inventory API to RELEASE (compensate Step 1)

Choreography (Service Bus Topics):
  Each service subscribes to its trigger event
  Publishes result event → triggers next service
  Compensating events flow in reverse on failure
  No central orchestrator — fully decoupled

What is the Claim Check pattern?

Offloads large message payloads to external storage and sends only a reference in the Service Bus message.

Problem: Message payload = 5MB → exceeds 256KB Service Bus limit

Solution:
Producer:
  1. Upload full payload to Azure Blob Storage
  2. Get SAS URL (time-limited access token)
  3. Send small message: { "claimCheck": "{sasUrl}", "type": "OrderCreated" }

Consumer:
  1. Receive small message from Service Bus
  2. Download full payload from Blob using claimCheck URL
  3. Process the full payload
  4. Delete the blob after successful processing

How do Logic Apps, Service Bus, and APIM work together in enterprise integration?

External systems / Trading partners / Mobile apps
        ↓ HTTPS
[APIM] ← API Gateway (North-South traffic)
  → Authenticate: validate JWT/OAuth/mTLS
  → Rate limit external callers
  → Route to correct backend version
  → Transform: REST→SOAP, JSON→XML
        ↓
[Logic Apps] ← Orchestration layer
  → Receives HTTP request from APIM
  → Calls multiple backend services (SAP, D365, SQL)
  → Handles retry, error handling, compensation
  → Sends responses back and notifications
        ↓
[Service Bus] ← Async decoupling layer (East-West traffic)
  → Decouples Logic App from slow backend systems
  → Reliable delivery to downstream consumers
  → Topics/subscriptions fan out to multiple consumers
        ↓
Backend services (SAP, Dynamics 365, SQL, Custom APIs)

Design principle:
APIM    = North-South gateway (external ↔ internal boundary)
Service Bus = East-West bus (internal service ↔ service decoupling)
Logic Apps  = Orchestration across both layers

What is the Throttling / Rate Limiting pattern in APIM?

<!-- Rate limit per subscriber: 100 calls per 60 seconds -->
<rate-limit-by-key calls="100" renewal-period="60"
  counter-key="@(context.Subscription.Id)"
  increment-condition="@(context.Response.StatusCode >= 200
    and context.Response.StatusCode < 300)"/>

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

<!-- Weekly quota (business tier limit) -->
<quota-by-key calls="50000" bandwidth="102400"
  renewal-period="604800"
  counter-key="@(context.Subscription.Id)"/>

<!-- Spike arrest: max 10 calls/second to protect backend -->
<rate-limit calls="10" renewal-period="1"/>

When limit exceeded:

Returns HTTP 429 Too Many Requests
Include Retry-After header
Custom error body via policy

Tip: Implement both rate-limit (short window, protect from spikes) and quota (long window, enforce business tier limits) for complete throttling strategy.

7. Scenario-Based Questions

Scenario: Design a reliable order processing system using Service Bus for 10,000 orders/hour.

Service Bus Premium namespace: dedicated capacity, ~1000 msg/sec throughput, VNET integration
Topic: orders with subscriptions:
- inventory-sub: filter OrderType = 'Physical'
- payment-sub: no filter (all orders), sessions enabled (SessionId = OrderId)
- analytics-sub: no filter (all orders)
Azure Functions consumers with Service Bus trigger: KEDA-based auto-scaling
Dead Letter Queue monitoring: Azure Monitor alert when DLQ count > 0. Logic App notifies ops team.
Duplicate detection: MessageId = OrderId + SubmissionTimestamp — prevents double-processing on producer retry
Geo-Disaster Recovery: paired secondary namespace in secondary region. Failover RTO < 1 minute.
Message TTL: 24h — orders not processed in 24h → DLQ alert for manual review

Scenario: A backend API averages 3 second responses. How do you use APIM to improve consumer experience?

Response caching for stable reference data (product catalogue, lookup tables):

<cache-lookup vary-by-developer="false">  <vary-by-header>Accept</vary-by-header></cache-lookup><!-- In outbound: --><cache-store duration="300"/>

Circuit breaker pattern: on repeated backend failures, return cached last-good response or a meaningful error:
```
<retry condition="@(context.Response.StatusCode >= 500)"  count="3" interval="2" first-fast-retry="true"/>
```
Async pattern for operations > 1s:
- APIM accepts request → sends to Service Bus → returns 202 Accepted + jobId
- Backend processes async → stores result
- Consumer polls GET /jobs/{jobId} for status
Mock response for dev/test environments — no backend call
Backend timeout policy: set explicit timeout so slow responses don't exhaust APIM threads
Backend load balancing: configure multiple backend pool members — APIM round-robins or health-checks

Scenario: How do you expose an on-premises SAP API securely to external partners via APIM?

APIM Premium with Internal VNET mode: APIM deployed inside a VNET. SAP reachable via ExpressRoute/VPN into the same VNET.
Application Gateway in front of APIM: AG provides public endpoint, WAF, SSL termination. Forwards to internal APIM only.
Partner authentication: mutual TLS (client certificates) or OAuth 2.0 client credentials. APIM validates certificates against trusted CA store.
Request transformation: APIM policy transforms REST JSON → SOAP for SAP. Partners never see SAP's native SOAP interface.
Rate limiting: per-partner subscription limits prevent any partner overwhelming SAP.
Schema validation: APIM validates request payloads at gateway — bad requests rejected before reaching SAP.
Logging: all partner API calls → Azure Monitor + Application Insights for audit compliance.

Scenario: Design a Logic App that syncs orders from e-commerce to Dynamics 365 every 15 minutes with deduplication.

Trigger: Recurrence — every 15 minutes
Fetch new orders: HTTP GET ?modifiedAfter=@{addMinutes(utcNow(),-15)}
Parse JSON: extract orders array
For Each (concurrency 5): parallel processing of 5 orders at a time
- Query D365 by external order ID → does it exist?
- No: create new D365 record
- Yes: compare modifiedOn → if changed, update
Try-Catch per order: wrap each order in a Try scope. Catch: log failed orderId + error to Azure Table Storage. Continue to next order — don't fail entire run on one bad record.
Summary notification: Teams message after loop: "Sync complete: X created, Y updated, Z failed. See log for details."
Persist last sync timestamp: update a D365 config record with current timestamp for next run's filter query.

Scenario: How do you implement a pub/sub notification system where different teams receive different order events?

Architecture:
Order Service → publishes to Service Bus Topic: "order-events"

Subscriptions with SQL filter rules:
inventory-team-sub:
  Filter: OrderStatus = 'Confirmed' OR OrderStatus = 'Cancelled'
  Action: Set RouteTo = 'inventory-queue'

finance-team-sub:
  Filter: OrderTotal > 1000 AND PaymentStatus = 'Charged'

shipping-team-sub:
  Filter: OrderStatus = 'ReadyToShip' AND DeliveryType = 'Express'

analytics-sub:
  No filter — receives ALL events for reporting

Implementation:
Order service sends with properties:
message.ApplicationProperties["OrderStatus"] = "Confirmed";
message.ApplicationProperties["OrderTotal"] = 1500.00;
message.ApplicationProperties["DeliveryType"] = "Express";

Each team's consumer only receives events matching their filter.
Teams can be added/removed without changing the producer.

8. Cheat Sheet — Quick Reference

Service Selection Guide

Need to...                              → Use
Orchestrate a multi-step process        → Logic Apps
Decouple services reliably              → Service Bus Queue
Fan out events to multiple consumers    → Service Bus Topic OR Event Grid
React to Azure resource events          → Event Grid
Ingest millions of telemetry events/sec → Event Hubs
Secure and manage APIs                  → API Management
Transform request/response format       → APIM policy
Rate limit API callers                  → APIM rate-limit policy
Guarantee message order                 → Service Bus + Sessions
Handle large payloads (>256KB)          → Claim Check pattern + Blob Storage
B2B EDI (AS2, X12, EDIFACT)            → Logic Apps + Integration Account

Service Bus Quick Reference

Namespace tiers: Basic (queues only) | Standard | Premium (enterprise)
Max message size: 256KB (Standard) | 100MB (Premium)
Message retention: up to 14 days
Max delivery count: default 10 (configurable)

Queue (point-to-point):
→ Competing consumers
→ Each message processed once
→ Enable sessions for FIFO ordering

Topic (pub/sub):
→ Multiple subscriptions
→ SQL filter rules per subscription
→ Each subscription gets independent copy

Message receive modes:
Peek-Lock: safe, acknowledged, retryable    ← always use for business data
Receive-Delete: immediate delete, risk loss ← only for non-critical

DLQ: every queue/subscription has one
Monitor: alert when DLQ count > 0
Path: myqueue/$DeadLetterQueue

APIM Policy Reference

<!-- JWT validation -->
<validate-jwt header-name="Authorization" failed-validation-httpcode="401">
  <openid-config url="https://login.microsoftonline.com/{tid}/v2.0/.well-known/openid-configuration"/>
</validate-jwt>

<!-- Rate limit per subscription -->
<rate-limit-by-key calls="100" renewal-period="60"
  counter-key="@(context.Subscription.Id)"/>

<!-- Cache response -->
<cache-store duration="300"/>

<!-- Transform XML to JSON -->
<xml-to-json kind="direct" apply="always"/>

<!-- Set backend URL -->
<set-backend-service base-url="https://api.backend.com"/>

<!-- Add header -->
<set-header name="X-Key" exists-action="override">
  <value>{{named-value}}</value>
</set-header>

<!-- Remove response header -->
<set-header name="X-Powered-By" exists-action="delete"/>

<!-- Mock response -->
<mock-response status-code="200" content-type="application/json"/>

<!-- Return custom error -->
<return-response>
  <set-status code="400"/>
  <set-body>{"error": "Invalid request"}</set-body>
</return-response>

Logic Apps — Connectivity Modes

Consumption plan:
→ Shared infrastructure
→ Pay per action (~$0.000025/action)
→ No VNET
→ One workflow per resource
→ Good for: low-volume, quick start

Standard plan:
→ Dedicated App Service Plan
→ Fixed cost, predictable
→ VNET integration + private endpoints
→ Multiple workflows per resource
→ Stateless workflows (fast, no history)
→ Local development in VS Code
→ Good for: enterprise production

Top 10 Tips

Logic Apps vs Power Automate — same engine, different infrastructure control. Enterprise = Logic Apps (VNET, IaC, B2B). Business users = Power Automate. Never say "they're the same thing."
Standard vs Consumption — Standard is the enterprise choice (VNET, stateless, multi-workflow). Consumption for quick prototypes only. Know this before any architecture question.
Service Bus sessions = FIFO — sessions are the ONLY way to guarantee message ordering. Without them, ordering is not guaranteed even with a single consumer.
Peek-Lock, always — Receive-and-Delete risks message loss on consumer crash. Peek-Lock with Complete/Abandon is the correct pattern for any business-critical message.
DLQ monitoring is non-negotiable — an overflowing DLQ is silent data loss. Azure Monitor alert on DLQ count > 0 is a standard architecture requirement.
APIM Premium for VNET — it's the only tier with private network integration. If backends are on-premises or in a private VNET, you need Premium.
Named Values for secrets in APIM policies — never hardcode API keys or connection strings in policy XML. Named Values (Key Vault-backed) are the correct approach.
Products in APIM — how you bundle APIs and control consumer access tiers. Many candidates know APIs but miss Products as the access control layer.
Integration Account for B2B EDI — AS2, X12, EDIFACT in Logic Apps requires an Integration Account. This is the expected answer for any B2B/trading partner question.
APIM + App Gateway pattern — exposing APIM in Internal VNET mode behind an Application Gateway is the standard enterprise pattern for secure public API exposure with backend network isolation.

Wednesday, April 29, 2026