Cloud-native integration works differently than on-premises middleware. There are no servers to patch, no fixed capacity to plan around. Azure Logic Apps, alongside API Management, Service Bus, and Azure Functions, gives you an integration platform that scales on demand. This article walks through that platform, using a realistic enterprise architecture as the guide.
The scenario connects Oracle Fusion, Salesforce, Dynamics 365, SharePoint, SAP, and CargoWise. It also covers SFTP, AS2, X12 EDI, and EDIFACT trading partners. By the end, you’ll understand how each Azure service fits into that picture.
☁️ The Core Architecture
Here’s the full platform. Source systems and trading partners connect in on the left. Azure’s integration services process, route, and secure that data. Target systems receive it on the right.
flowchart LR
Oracle[Oracle Fusion]
Salesforce[Salesforce]
Dynamics[Dynamics 365]
SharePoint[SharePoint]
CargoWise[CargoWise]
Partners[EDI Trading Partners]
subgraph Azure["Azure Integration Platform"]
APIM[API Management]
LogicApps[Azure Logic Apps]
ServiceBus[Service Bus]
EventGrid[Event Grid]
Functions[Azure Functions]
IntegrationAccount[Integration Account]
KeyVault[Key Vault]
Storage[Storage Account]
Monitor[Azure Monitor / App Insights]
end
Oracle --> APIM
Salesforce --> APIM
Dynamics --> LogicApps
SharePoint --> LogicApps
CargoWise --> LogicApps
Partners --> IntegrationAccount
APIM --> LogicApps
LogicApps --> ServiceBus
ServiceBus --> Functions
EventGrid --> LogicApps
Functions --> LogicApps
LogicApps --> Oracle
LogicApps --> Salesforce
LogicApps --> CargoWise
LogicApps --> KeyVault
LogicApps --> Storage
LogicApps --> Monitor
classDef external fill:#dbeafe,stroke:#2563eb,color:#1e3a5f,stroke-width:1.5px
classDef gateway fill:#fef3c7,stroke:#d97706,color:#78350f,stroke-width:1.5px
classDef process fill:#ede9fe,stroke:#7c3aed,color:#3b0764,stroke-width:1.5px
classDef storage fill:#f3f4f6,stroke:#6b7280,color:#1f2937,stroke-width:1.5px
class Oracle,Salesforce,Dynamics,SharePoint,CargoWise,Partners external
class APIM,IntegrationAccount gateway
class LogicApps,ServiceBus,EventGrid,Functions process
class KeyVault,Storage,Monitor storage
💡 Architecture Tip: Start with Logic Apps for orchestration, and only drop into Azure Functions when a step needs custom code. That keeps the integration visual and maintainable for longer.
🔌 Azure API Management
API Management sits at the front door. It acts as a gateway between external callers and your backend Logic Apps or Functions. Along the way, it handles authentication through OAuth 2.0 and JWT validation, plus subscription keys for partner access.
It also handles rate limiting, IP filtering, and API versioning. Transformation policies let it reshape a request before it even reaches your backend. Here’s the typical flow:
flowchart LR
Client[Client] --> APIM[API Management]
APIM --> Auth[JWT Validation]
Auth --> Policy[Policy Processing]
Policy --> Backend[Logic App / Function]
Backend --> System[Backend System]
classDef external fill:#dbeafe,stroke:#2563eb,color:#1e3a5f,stroke-width:1.5px
classDef gateway fill:#fef3c7,stroke:#d97706,color:#78350f,stroke-width:1.5px
classDef process fill:#ede9fe,stroke:#7c3aed,color:#3b0764,stroke-width:1.5px
class Client,System external
class APIM,Auth,Policy gateway
class Backend process
⚙️ Azure Logic Apps
Logic Apps come in two flavors: Consumption and Standard. Consumption bills per execution and scales automatically. Standard runs on dedicated compute, which suits high-throughput or latency-sensitive workflows.
Every Logic App starts with a trigger, then runs a series of actions through connectors. Common connectors include HTTP, SFTP, SQL, Salesforce, SharePoint, and Service Bus. For resilience, each action supports retry policies and run-after conditions, so a single failure doesn’t take down the whole workflow.
🧩 Azure Functions
Functions handle the logic that Logic Apps connectors can’t express visually. That includes complex transformations, custom C# code, and XML manipulation. It also covers ZIP and Base64 processing, PDF generation, custom authentication schemes, and file encryption.
As a rule of thumb: if a step needs real code, it belongs in a Function. It shouldn’t be buried inside a Logic App expression.
🚌 Azure Service Bus
Service Bus decouples systems that don’t need to talk in real time. Queues handle point-to-point messaging. Topics and subscriptions handle publish-subscribe patterns, where multiple systems need the same message.
Dead-letter queues catch messages that fail processing repeatedly, instead of losing them. Duplicate detection and sessions add further reliability for ordered or exactly-once scenarios. Here’s an asynchronous pattern in practice:
flowchart LR
LA[Logic App] --> SB[Service Bus Topic]
SB --> Sub1[Subscription: Finance]
SB --> Sub2[Subscription: CRM]
Sub1 --> Func1[Function: Post Invoice]
Sub2 --> Func2[Function: Update Account]
classDef process fill:#ede9fe,stroke:#7c3aed,color:#3b0764,stroke-width:1.5px
classDef gateway fill:#fef3c7,stroke:#d97706,color:#78350f,stroke-width:1.5px
class LA process
class SB,Sub1,Sub2 gateway
class Func1,Func2 process
⚡ Event Grid
Event Grid handles a different pattern: reacting to events as they happen, rather than polling for them. A file landing in Blob Storage, or a custom application event, can trigger a Logic App or Function instantly.
Choose Event Grid over Service Bus when you need low-latency, event-driven reactions. Choose Service Bus instead when you need guaranteed delivery, ordering, or transactional messaging.
🔐 Azure Key Vault
Key Vault stores the secrets your integrations depend on: client secrets, API keys, certificates, SFTP passwords, and encryption keys. Logic Apps and Functions can access these secrets through Managed Identity, without ever hard-coding a credential.
🚨 Production Consideration: Never store API secrets directly in a Logic App definition. Use Key Vault with Managed Identity instead, so credentials never appear in source control or deployment templates.
🚨 Common Integration Challenges
A few patterns cause trouble repeatedly. Chatty Logic App workflows, with too many small steps, can get expensive under Consumption billing. In addition, EDI trading partners still need an Integration Account, which has its own learning curve separate from standard connectors. Finally, debugging a distributed flow across Logic Apps, Functions, and Service Bus takes real discipline in correlation and logging.
📊 Monitoring and Exception Handling
Azure Monitor and Application Insights give you end-to-end visibility. Every Logic App run, every Function execution, and every Service Bus message can be traced. That said, good exception handling still needs deliberate design.
Use scoped try-catch blocks in Logic Apps, so one failed action doesn’t silently fail the whole run. Route unrecoverable failures to a dead-letter queue instead of dropping them. Set alerts on failure rates, not just on total failures. A low absolute count can still signal a real problem at scale.
⚡ Performance and Scalability
Logic Apps on Consumption scale automatically, which removes most capacity planning. Standard, on the other hand, needs proper App Service Plan sizing, similar to any hosted compute. Service Bus throughput depends on the tier and partitioning strategy chosen upfront. Functions scale independently, which makes them a good place to isolate CPU-heavy work away from your orchestration layer.
🚀 Deployment Considerations
Azure integrations deploy well through ARM templates, Bicep, or Azure DevOps pipelines. Environment-specific configuration, like connection strings and endpoints, should live in parameters or Key Vault references, not hard-coded in the template. Blue-green or staged deployment slots reduce risk when updating a Logic App that’s already handling production traffic.
🏢 Real-World Use Cases
A freight forwarder might use this platform to receive CargoWise shipment events through Event Grid. From there, it can post updates to Salesforce and Oracle Fusion in parallel, through Service Bus topics. A retailer, similarly, might use API Management to expose a partner-facing order API. Behind it, a Logic App validates and routes each order into SAP. Both cases lean on the same core pattern: gateway in, orchestrate, fan out.
✅ Best Practices
Design Logic Apps around a clear naming convention from day one. Otherwise, a workspace with dozens of similarly-named flows becomes unmanageable fast. Also, keep secrets exclusively in Key Vault, never in application settings. Use Integration Accounts for EDI rather than building custom X12 or EDIFACT parsing by hand. And version your ARM or Bicep templates in source control, the same as any other code.
🎯 When to Use This Architecture
This pattern fits greenfield, cloud-first integration projects particularly well. It also suits companies actively moving off legacy middleware, since Logic Apps can run alongside BizTalk during a phased migration. It’s less ideal for pure on-premises environments with no Azure connectivity at all. In those cases, a fully on-premises platform may still make more sense.
🔑 Key Takeaways
Azure Logic Apps, paired with API Management, Service Bus, and Functions, gives you a modern, consumption-scaled integration platform. Its strength is elasticity and native cloud connectivity. Its main tradeoff: EDI and legacy protocol support need more setup than a purpose-built tool like BizTalk provides natively. For cloud-first organizations, that tradeoff is usually worth it.
Tags: Azure Logic Apps, Azure Integration Services, Enterprise Integration, API Management, Azure Service Bus, Azure Functions, Oracle Fusion Integration, Salesforce Integration, CargoWise Integration
Planning a move to Azure integration services? Talk to our integration team →