Most architecture articles show one system talking to another. Real integration projects rarely look that simple. This article walks through a realistic, end-to-end scenario. A shipment event in CargoWise needs to reach both Salesforce and Oracle Fusion. It has to happen securely, reliably, and with full visibility along the way.
🏢 The Scenario
CargoWise generates a shipment or invoice event. From there, Azure Logic Apps receives it, and Azure Functions transforms the payload into a canonical format. API Management then exposes that data as a controlled API. Salesforce receives a customer or shipment update. Oracle Fusion, in parallel, receives the finance transaction. Service Bus handles the asynchronous processing between those two branches. Key Vault secures every credential involved, and Application Insights monitors the whole flow.
🔄 The Architecture
flowchart LR
CW[CargoWise]
subgraph Azure["Azure Integration Platform"]
LA[Logic Apps]
AF[Azure Functions]
APIM[API Management]
SB[Service Bus]
KV[Key Vault]
AI[Application Insights]
end
SF[Salesforce]
OF[Oracle Fusion]
CW --> LA
LA --> AF
AF --> APIM
APIM --> SB
SB --> SF
SB --> OF
LA --> KV
AF --> KV
LA --> AI
AF --> AI
APIM --> AI
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 CW,SF,OF external
class APIM gateway
class LA,AF,SB process
class KV,AI storage
⏱️ The Sequence
The architecture diagram shows the components. The sequence diagram below shows the order things actually happen in, message by message.
sequenceDiagram
participant CW as CargoWise
participant LA as Logic App
participant AF as Azure Function
participant SB as Service Bus
participant APIM as API Management
participant SF as Salesforce
participant OF as Oracle Fusion
CW->>LA: Shipment / Invoice XML
LA->>AF: Transform Message
AF-->>LA: Canonical JSON
LA->>SB: Publish Message
SB->>APIM: Process Customer Update
APIM->>SF: Update Salesforce
SF-->>APIM: Success
SB->>APIM: Process Finance Transaction
APIM->>OF: Post Invoice
OF-->>APIM: Transaction ID
APIM-->>LA: Processing Status
Notice the branch point. Once Service Bus publishes the message, the customer update and the finance transaction process independently. If Oracle Fusion is briefly unavailable, the Salesforce update still completes on schedule.
💡 Architecture Tip: Design the Service Bus topic with separate subscriptions per downstream system. That way, one slow or failing consumer never blocks the others.
⚙️ Why Each Component Is There
Logic Apps orchestrates the overall flow and handles retries automatically. Azure Functions does the heavy transformation work, converting CargoWise’s XML into a clean, canonical JSON structure. API Management then exposes that data through a controlled, authenticated interface. That way, Salesforce and Oracle Fusion never call Azure resources directly.
Service Bus decouples the two downstream branches, so a failure in one doesn’t cascade into the other. Key Vault keeps every credential, from Salesforce OAuth tokens to Oracle API keys, out of application settings entirely. Application Insights ties it all together with distributed tracing across every hop.
🚨 Common Challenges in This Pattern
Correlation is the hardest part. A single shipment event fans out into multiple downstream calls. As a result, tracing one CargoWise record through Salesforce and Oracle Fusion needs a consistent correlation ID from the start. Partial failures also need careful handling. If Oracle Fusion succeeds but Salesforce fails, the system needs a clear retry or compensation strategy, not a silent gap.
🔐 Security Considerations
Every hop in this flow uses Managed Identity where possible, instead of static credentials. API Management enforces authentication before any request reaches a Logic App. Service Bus connections use SAS tokens scoped to specific queues and topics. That’s instead of a single shared connection string across the whole namespace.
🚨 Production Consideration: Rotate Service Bus SAS keys on a schedule, and scope each application to its own key. A shared key across every consumer makes revoking access during an incident far harder than it needs to be.
📊 Monitoring and Exception Handling
Application Insights captures a distributed trace for every shipment event. That trace runs from CargoWise all the way through to Salesforce and Oracle Fusion. Failed runs route to a dead-letter queue in Service Bus, rather than disappearing silently. Alerts trigger on both hard failures and unusual latency. Often, a slow integration signals a problem before it becomes a full outage.
⚡ Performance and Scalability
Logic Apps and Functions both scale automatically under Consumption billing, which handles shipment volume spikes without manual intervention. Service Bus throughput, however, needs its own capacity planning, particularly around partition count for high-volume topics. API Management’s tier also matters here, since its own throttling limits can become the real bottleneck before Azure’s compute does.
🚀 Deployment Considerations
This entire architecture deploys well as a single Bicep template, with each resource’s configuration parameterized per environment. Staged deployment slots let a new version of the Logic App run against production traffic in shadow mode first. Only then does it fully cut over. Rollback, as a result, becomes a slot swap rather than a redeployment.
🏢 Real-World Use Cases
This exact pattern fits any scenario where one event needs to reach multiple systems independently. A freight forwarder might use it precisely as described, for shipment and invoice events. A retailer might adapt the same shape for order events instead. That means fanning out to inventory, CRM, and finance systems in parallel, each on its own subscription.
✅ Best Practices
Use a single correlation ID from the first hop onward, and log it everywhere. Also, design each downstream branch to be independently retryable, so one system’s outage never blocks another. Keep transformation logic in Functions, not scattered across multiple Logic App expressions, so it stays testable in isolation. And monitor Service Bus queue depth directly, since a growing backlog is often the earliest warning sign of trouble.
🎯 When to Use This Architecture
This pattern fits well whenever a single business event needs to reach two or more independent systems. It’s most valuable when those downstream systems have different reliability profiles. In that case, Service Bus decoupling protects the whole flow from any one system’s downtime.
🔑 Key Takeaways
Real integration architecture is rarely point-to-point. This scenario shows how Logic Apps, Functions, API Management, and Service Bus combine into a single, resilient flow. The key design decision is decoupling: once Service Bus enters the picture, downstream failures stop being your upstream system’s problem.
Tags: Enterprise Integration Architecture, Azure Logic Apps, Azure Service Bus, Azure Functions, API Management, CargoWise Integration, Salesforce Integration, Oracle Fusion Integration
Need an integration architecture built for your systems? Talk to our integration team →