India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
Azure Functions, Logic Apps, API Management & Service Bus Integration
Azure serverless and integration services are the managed building blocks for connecting systems and running event-driven code: Azure Functions (including the Flex Consumption plan), Logic Apps workflows, API Management gateways, Service Bus queues and topics, and Event Grid event routing. NTSPL uses them to integrate dealer, hospital and distributor systems with OEMs, health networks and retailers, replacing point-to-point scripts with monitored, retryable flows.
Microsoft Azure services in scope
The Problem Azure Functions (Flex Consumption plan) and Azure Logic Apps (Standard) Solve
Integration in most Indian enterprises is a layer of scheduled scripts, FTP folders, SSIS packages and vendor-built adapters that nobody fully documents. Each new partner, an OEM portal, a TPA, a retailer's EDI requirement, adds another point-to-point link. When one fails at night, messages are lost silently and someone re-keys data the next morning. The integration problem is decoupling producers and consumers so a failure is queued and retried, not lost, publishing APIs with consistent security and throttling, and making every message traceable end to end.
NTSPL designs integration around three rules: every cross-system message goes through Service Bus or Event Grid so it survives downstream outages; every external API passes through API Management with its own product, key and rate limit; and transformation logic sits in Logic Apps when it is mapping-heavy or partner-specific, and in Functions when it is code-heavy or high-throughput. Correlation IDs travel with each message into Application Insights so support teams can trace a single order or claim across systems.
When to Use Azure Functions, Logic Apps, API Management and Service Bus (and When Not To)
Signals that point to serverless & integration on Microsoft Azure
- More than 20 scheduled scripts, SSIS packages or FTP jobs move data between systems, and failures are discovered by users the next day.
- A new partner, OEM or retailer integration takes more than six weeks because each is built point to point.
- Partners call internal APIs directly with shared credentials and no rate limits, and one partner's traffic has slowed others.
- Messages are lost or duplicated when a downstream system is restarted or slow.
- Event-driven jobs run on always-on VMs that sit idle more than 80 percent of the day.
When a different approach is better
- Bulk data movement and transformation of millions of rows for analytics: Azure Data Factory or Microsoft Fabric pipelines are designed for that, not Logic Apps loops.
- High-throughput telemetry streams at thousands of events per second for analysis: Azure Event Hubs handles streaming ingestion better than Service Bus.
- Long-running, stateful services needing constant compute or specific OS dependencies: Azure Container Apps or AKS avoids Functions timeouts and platform limits.
Azure Integration Building Blocks: Flex Consumption Functions, Logic Apps Standard, APIM, Service Bus and Event Grid
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Azure Functions (Flex Consumption plan) | Runs event-triggered code on Linux with per-function scaling, configurable instance memory, optional always-ready instances and VNet integration, billed for execution time. | Transformation or enrichment logic is code-heavy, high-throughput or needs private network access without a dedicated plan. |
| Azure Logic Apps (Standard) | Runs stateful and stateless workflows on single-tenant hosting with built-in connectors, VNet integration and B2B operations for AS2, X12 and EDIFACT with an integration account. | Flows are mapping-heavy, partner-specific or orchestrate several SaaS and on-premises systems with approvals and retries. |
| Azure API Management | Publishes, secures and throttles APIs through a gateway with policies for JWT validation, rate limits, quotas and transformation, plus a developer portal for partners. | APIs are consumed by partners, mobile apps or multiple internal teams and need consistent authentication, versioning and usage limits. |
| Azure Service Bus | Provides durable queues and publish-subscribe topics with sessions for ordered processing, duplicate detection, dead-lettering, scheduled delivery and transactions. | Business messages such as orders, claims or appointments must not be lost or processed twice when a consumer is down. |
| Azure Event Grid | Routes discrete events from Azure services, custom topics or namespaces to handlers with push or pull delivery, filtering, retries and dead-lettering, using the CloudEvents schema. | Systems need to react to state changes such as a blob created or a status updated, rather than exchange commands. |
| Azure Health Data Services (FHIR service) | Provides a managed FHIR R4 server with a $convert-data operation that transforms HL7 v2 messages into FHIR resources using Liquid templates. | Hospital systems exchanging HL7 v2 need a standards-based clinical data store or must publish FHIR records for ABDM-aligned exchange. |
API-led, queue-decoupled integration hub in Central India
API-led, queue-decoupled integration hub in Central India
Partners and internal apps call APIs through API Management, which validates tokens, applies quotas and hands requests to Service Bus topics or Logic Apps workflows. Functions on Flex Consumption and Logic Apps Standard consume messages, transform them and call target systems over private networking, while Event Grid broadcasts state-change events and failed messages land in dead-letter queues for replay.
Select any component
API-led, queue-decoupled integration hub in Central India: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 5-step primary path.
Azure Integration Engineering Decisions: Messaging Pattern, Workflow Engine, Hosting Plan and API Tier
Queue, topic or event
Use a Service Bus queue for commands with one consumer, such as post this invoice to the ERP. Use a topic with subscriptions when several systems need the same business message, such as an order to billing, warehouse and CRM. Use Event Grid for lightweight notifications that something happened, where subscribers fetch details themselves. Use sessions when messages for one entity must be processed in order, and duplicate detection when producers may retry sends.
Logic Apps or Functions for a flow
Choose Logic Apps Standard when a flow is mostly connectors, mappings, conditions and waits, when business analysts need to read it, or when it uses B2B AS2, X12 or EDIFACT operations. Choose Functions when logic needs real code, libraries, complex validation or throughput above a few hundred messages per second. Combine them: a Logic App orchestrates, calling a Function for heavy transformation. Avoid putting loops over thousands of items in Logic Apps, as action executions drive cost.
Functions hosting plan
Flex Consumption is the default for new serverless functions: it scales per function, supports VNet integration, lets you choose instance memory and keeps always-ready instances warm to avoid cold starts on HTTP endpoints. Use the Premium plan or App Service plan when you need Windows-only features or very long steady workloads that would cost less on reserved capacity. Check that the target region and language stack are supported for Flex Consumption before committing.
API Management tier
Consumption suits low-volume, internal APIs billed per call. Basic v2 and Standard v2 give fast deployment and VNet integration for outbound calls at moderate scale. Premium (classic or v2) is needed for VNet injection, multi-region gateways, availability zones and self-hosted gateways. Choose based on network isolation and gateway location needs first, then throughput; scaling units can be added later within a tier.
Error handling and replay
Set max delivery count on Service Bus subscriptions to 5-10 so poison messages move to dead-letter instead of blocking the queue. Use exponential retry in Logic Apps actions and Functions for transient errors, but never retry business validation failures. Store the original payload with the failure reason, alert on dead-letter count above zero for critical flows, and give support a replay tool that resubmits after correction.
How NTSPL Replaces Point-to-Point Scripts with Azure Integration Services
Integration catalogue and pattern mapping
List every existing script, package and adapter with source, target, frequency and failure behaviour, and assign each to queue, topic, event or API pattern.
Service Bus and Event Grid foundation
Create Service Bus namespaces with topics, subscriptions, sessions and duplicate detection per domain, plus Event Grid topics, all on private endpoints.
API Management products and policies
Publish APIs with partner products, OAuth or key auth, rate limits and correlation-ID injection, and onboard partners through the developer portal.
Workflow and function build
Build Logic Apps Standard workflows and Flex Consumption functions in source control with CI/CD, using managed identity for every connection.
Parallel run and reconciliation
Run new flows alongside old scripts, reconcile outputs daily, then switch partners and systems over flow by flow.
Dead-letter alerting and replay handover
Set alerts on dead-letter counts and queue age, deliver the replay tool and train support teams on correlation-ID tracing.
What you receive
Securing Azure Integrations: APIM Policies, Managed Identity, Private Endpoints and Message-Level Controls
Integration layers hold credentials for many systems and accept traffic from outside, so the risks are leaked partner keys, overprivileged connectors, data exposure in run history and public messaging endpoints. NTSPL authenticates partners with OAuth tokens validated at API Management, gives every Function and Logic App a managed identity with least-privilege roles, keeps Service Bus and Storage on private endpoints, and secures inputs and outputs in Logic Apps run history for personal data.
- APIM validate-jwt and rate-limit-by-key policies per partner product
- Managed identity with Azure Service Bus Data Sender and Receiver roles instead of SAS connection strings
- Private endpoints on Service Bus Premium and VNet integration on Functions and Logic Apps
- Secure inputs and outputs in Logic Apps to keep patient or customer data out of run history
- Key Vault references for partner certificates and OEM API secrets with rotation alerts
Azure Integration Pricing Levers: Flex Consumption, Logic Apps Plans, Service Bus Tiers and APIM Units
Functions Flex Consumption bills per GB-second of execution plus executions, with always-ready instances billed at a lower baseline rate. Logic Apps Standard bills the hosting plan's vCPU and memory, while Consumption bills per action. Service Bus Standard bills per operation; Premium bills per messaging unit-hour. API Management bills per unit or per call on Consumption. Event Grid bills per operation.
- Flex Consumption with always-ready instances only on latency-sensitive HTTP functions
- Logic Apps Standard for high-volume flows, where per-action Consumption billing would exceed plan cost
- Service Bus Standard for non-critical domains; Premium only where isolation, VNet or large messages are needed
- APIM response caching for reference data APIs such as price lists and doctor schedules
- Batching small messages before transformation to cut execution counts
Azure Service Bus vs Event Grid vs Event Hubs: which should carry my messages?
Decide on four criteria. Intent: Service Bus carries business messages that a consumer must act on, such as an order or claim; Event Grid carries notifications that something happened; Event Hubs carries high-volume telemetry streams for analysis. Delivery guarantees: Service Bus offers ordered sessions, transactions, duplicate detection and dead-lettering; Event Grid offers retries and dead-lettering with at-least-once delivery; Event Hubs keeps a retained log that consumers read at their own pace. Volume: Event Hubs handles millions of events per second; Service Bus suits thousands of business messages per second. Consumer model: Service Bus and Event Grid push or pull per message; Event Hubs uses partitioned consumer groups. NTSPL rule: business transactions on Service Bus, reactive notifications on Event Grid, telemetry on Event Hubs.
Key facts about serverless & integration on Microsoft Azure
Serverless & Integration on Microsoft Azure in Practice
3 serverless & integration scenarios from Automobile dealerships, Hospitals & healthcare, Electronics distribution: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Dealership group cuts OEM warranty claim rejections by integrating DMS through Service Bus
Hospital network moves HL7 and appointments to event-driven FHIR integration
Electronics distributor onboards retail EDI partners in 2 weeks with Logic Apps B2B
Apparel retailer serves 6 million loyalty members from Cosmos DB at 8 ms p99 reads
Non-profit runs donor CRM on App Service and launches campaign sites in 2 days
Health TPA meets 1-hour cashless pre-auth target with AKS and KEDA-scaled adjudication
Telecom operator runs OSS fault and inventory microservices at 4x event volume on AKS
Serverless & Integration on Microsoft Azure: Frequently Asked Questions
How is Azure Functions Flex Consumption billed?
Flex Consumption bills on-demand executions by GB-seconds of memory used during execution plus a per-execution charge, and bills always-ready instances, if you configure them, at a lower baseline rate while idle and the normal rate while executing. There is a monthly free grant for on-demand usage. NTSPL estimates cost from expected executions, duration and memory size per function.
How do we replace our existing SSIS packages, scripts and FTP jobs?
Catalogue each job's source, target, schedule and failure handling, then classify it: bulk data loads go to Data Factory, file-based partner exchanges to Logic Apps with SFTP or AS2 connectors, and event-driven transfers to Service Bus with Functions consumers. NTSPL migrates flows in order of business pain, running old and new in parallel until outputs match.
Can integration data stay within India for DPDP Act and sector rules?
Yes. Functions, Logic Apps, API Management, Service Bus and Event Grid can be deployed in Indian regions such as Central India, with private endpoints so message traffic stays on private networks. Logic Apps run history and Application Insights logs should also be placed in Indian regions and masked for personal data. NTSPL documents these locations for DPDP Act processing records.
Can Logic Apps handle EDI with large retailers?
Yes. Logic Apps supports AS2 for secure transport and X12 and EDIFACT for encoding and decoding business documents such as purchase orders, ship notices and invoices, using an integration account to hold trading partners, agreements, schemas and maps. Acknowledgements such as MDN and functional acknowledgements are generated automatically per agreement.
How do we integrate HL7 v2 hospital systems with FHIR?
Route HL7 v2 messages from the HIS or LIS over MLLP to a listener, typically a container or Function, then call the FHIR service's $convert-data operation with Liquid templates to produce FHIR R4 resources, and store them in Azure Health Data Services. Templates are adjusted for local fields. This supports exchange aligned with ABDM's FHIR-based profiles.
Should partners call our ERP directly or go through API Management?
Through API Management. It gives each partner its own key or OAuth client, rate limits and quotas, so one partner cannot overload the ERP; it hides internal URLs; and it logs every call for dispute resolution. Policies can also transform payloads, so partner contracts stay stable even when the ERP API changes.