Most enterprises don’t run one system. They run ten. An order might start in CargoWise, get invoiced through Oracle Fusion, and land as a customer record in Salesforce. Someone has to move that data between systems, and doing it by hand doesn’t scale. That’s the business problem Microsoft BizTalk Server solves: it acts as the enterprise integration hub connecting all of it together.
This article walks through a real BizTalk architecture. It covers Oracle Fusion, Salesforce, SharePoint, Dynamics CRM, X12 EDI, EDIFACT, REST and SOAP APIs, and SFTP. By the end, you’ll understand not just what BizTalk does, but how each piece fits together.
🔄 The Core Architecture
Here’s the full picture. Systems send messages in on the left. BizTalk receives, decodes, maps, and routes them through orchestrations. Systems receive messages out on the right.
flowchart LR
Oracle[Oracle Fusion]
SF[Salesforce]
SP[SharePoint]
CRM[Dynamics CRM / D365]
TP1[X12 Trading Partners]
TP2[EDIFACT Trading Partners]
API[REST / SOAP APIs]
FTP[SFTP / FTP]
subgraph BizTalk["Microsoft BizTalk Server"]
Receive[Receive Locations]
Pipeline[Receive Pipelines]
Decode[EDI / XML / JSON Processing]
Mapping[Maps / XSLT]
Orch[Orchestrations]
Rules[Business Rules Engine]
Send[Send Ports]
Tracking[BAM / Tracking]
end
SQL[(SQL Server)]
Monitoring[Monitoring and Alerts]
Oracle --> Receive
SF --> Receive
SP --> Receive
CRM --> Receive
TP1 --> Receive
TP2 --> Receive
API --> Receive
FTP --> Receive
Receive --> Pipeline
Pipeline --> Decode
Decode --> Mapping
Mapping --> Orch
Orch --> Rules
Rules --> Send
Send --> Oracle
Send --> SF
Send --> SP
Send --> CRM
Send --> TP1
Send --> TP2
Orch --> SQL
Tracking --> Monitoring
classDef external fill:#dbeafe,stroke:#2563eb,color:#1e3a5f,stroke-width:1.5px
classDef adapter 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,SF,SP,CRM,TP1,TP2,API,FTP external
class Receive,Pipeline,Send adapter
class Decode,Mapping,Orch,Rules,Tracking process
class SQL,Monitoring storage
⚙️ What Each Component Actually Does
Each piece in that diagram has a specific job. Here’s a plain breakdown.
Receive Ports and Receive Locations are where messages enter BizTalk. A Receive Location is a specific endpoint, like an SFTP folder or an HTTP URL. A Receive Port groups related locations together.
Pipelines process messages as they arrive or leave. A receive pipeline might decode EDI, validate XML, or decrypt a file. A send pipeline does the reverse on the way out.
Adapters handle the actual transport. BizTalk ships with adapters for SFTP, FTP, HTTP, SOAP, SQL, and file shares, among others.
Schemas define the shape of a message. Every XML message BizTalk processes gets validated against a schema first.
Maps, built with XSLT under the hood, transform one schema into another. This is how a Salesforce JSON payload becomes an internal XML format, or vice versa.
Orchestrations are the actual business logic. Specifically, they decide what happens to a message next. That includes which system to route to, what conditions apply, and how errors get handled.
The Business Rules Engine lets you externalize decision logic from orchestrations. As a result, business users can update rules without redeploying code.
Send Ports deliver the outbound message to its destination, using whichever adapter that destination requires.
Party configuration and agreements define your trading partners, including which EDI formats and identifiers each one uses.
BAM, or Business Activity Monitoring, tracks message flow for reporting. Tracking, on the other hand, logs the technical detail for troubleshooting.
Finally, the SQL Server MessageBox is BizTalk’s internal database. Every message passes through it, which is also why SQL Server sizing matters so much for BizTalk performance.
💡 Architecture Tip: Keep orchestrations focused on routing and business logic. Push heavy data transformation into maps, not orchestration code, so it stays testable and reusable.
🔗 BizTalk and Oracle Fusion
Oracle Fusion integration usually happens one of three ways: SOAP, REST, or file-based exchange over SFTP. Oracle also exposes its own APIs for specific modules, like financials or procurement.
A common pattern looks like this. Oracle Fusion generates finance or order data. From there, BizTalk receives and transforms it. Finally, the result lands in Salesforce as an updated account or opportunity. That flow also works in reverse, moving customer data from Salesforce into Oracle Fusion for invoicing.
☁️ BizTalk and Salesforce
Salesforce integration runs through its REST API, secured with OAuth 2.0. BizTalk authenticates, retrieves an access token, and uses it for subsequent calls.
Typical use cases include account and contact synchronization, plus batch processing for high-volume updates. Here’s the flow in practice:
flowchart LR
A[Salesforce] --> B[REST API]
B --> C[BizTalk]
C --> D[Validation]
D --> E[Mapping]
E --> F[Oracle Fusion]
classDef external fill:#dbeafe,stroke:#2563eb,color:#1e3a5f,stroke-width:1.5px
classDef api fill:#fef3c7,stroke:#d97706,color:#78350f,stroke-width:1.5px
classDef process fill:#ede9fe,stroke:#7c3aed,color:#3b0764,stroke-width:1.5px
class A,F external
class B api
class C,D,E process
Error handling matters a lot here. Salesforce API limits can throttle a poorly designed integration. Because of that, batching and retry logic need to be built in from the start.
📁 BizTalk and SharePoint
SharePoint integration usually centers on documents. BizTalk can extract files from a SharePoint library through its REST API. It can also update metadata, or trigger a SharePoint workflow once processing completes. This pattern works well for invoice attachments, contracts, or compliance documents tied to a business transaction.
🔷 BizTalk and Dynamics CRM / Dynamics 365
Dynamics integration goes through the Dataverse API, authenticated with OAuth. Common scenarios include customer and contact synchronization. Another common scenario is sales order integration, connecting Dynamics to back-office systems like an ERP or a logistics platform.
📦 X12 EDI Integration
X12 is the EDI standard most common in North American logistics and supply chain. A few transaction sets show up constantly. These include 204 for load tenders, 210 for freight invoices, and 214 for shipment status. Others are 810 for invoices, 850 for purchase orders, 856 for advance ship notices, and 990 for load tender responses.
Here’s how a typical X12 flow works end to end:
flowchart LR
Partner[Trading Partner]
AS2[AS2 / SFTP]
BizTalk[BizTalk Server]
EDI[EDI Pipeline]
Agreement[Party / Agreement]
Map[EDI to Internal XML]
ERP[ERP / Cargo System]
Ack[997 / 999 ACK]
Partner --> AS2
AS2 --> BizTalk
BizTalk --> EDI
EDI --> Agreement
Agreement --> Map
Map --> ERP
EDI --> Ack
Ack --> AS2
AS2 --> Partner
classDef external fill:#dbeafe,stroke:#2563eb,color:#1e3a5f,stroke-width:1.5px
classDef transport fill:#fef3c7,stroke:#d97706,color:#78350f,stroke-width:1.5px
classDef process fill:#ede9fe,stroke:#7c3aed,color:#3b0764,stroke-width:1.5px
classDef target fill:#dcfce7,stroke:#16a34a,color:#14532d,stroke-width:1.5px
class Partner external
class AS2,Ack transport
class BizTalk,EDI,Agreement,Map process
class ERP target
A few terms are worth knowing here. ISA and IEA wrap the entire interchange envelope. GS and GE wrap a functional group. ST and SE wrap an individual transaction. Meanwhile, a 997 or 999 acknowledgment confirms receipt back to the sender. That’s why party agreements and validation rules matter so much in EDI setups.
🌍 EDIFACT Integration
EDIFACT is the international counterpart to X12, common outside North America. Frequent message types include IFTMIN and IFTSTA, for transport instructions and status. Others are CODECO and COARRI for container events, DESADV for dispatch advice, and INVOIC and ORDERS for invoicing and orders.
The processing pattern mirrors X12. First, an EDIFACT decoder converts the raw message to XML. Then a BizTalk map transforms it into your internal canonical format. From there, it lands in your ERP or cargo system.
🚨 Common Integration Challenges
A few issues come up repeatedly in BizTalk projects. Trading partner EDI formats vary more than the standard suggests, so mapping needs real flexibility. In addition, high message volumes can strain the SQL Server MessageBox if it isn’t sized correctly. Finally, legacy orchestrations, built years ago, often need careful refactoring before they can support new integration points.
🔐 Security Considerations
Trading partner connections should run over AS2 or SFTP with proper certificate management, not plain FTP. Likewise, API-based integrations need OAuth 2.0 rather than static credentials, wherever the target system supports it. Sensitive fields, like account numbers or personal data, should be encrypted at rest and masked in tracking data. Access to the BizTalk Administration Console itself should also be tightly scoped to the people who actually need it.
🚨 Production Consideration: Never hard-code credentials inside an orchestration or a map. Store them in a secured configuration store instead, and rotate them on a schedule.
📊 Monitoring and Exception Handling
BAM gives you business-level visibility: which orders processed, which failed, and when. The BizTalk Administration Console, in contrast, gives you technical-level visibility: suspended instances, failed message details, and adapter errors.
Good exception handling means orchestrations catch specific fault types, instead of just generic exceptions. It also means routing failures to a dead-letter or retry queue, rather than silently dropping them. Alerts should fire automatically when suspended instances start piling up, not get discovered days later during a manual check.
⚡ Performance and Scalability
BizTalk scales by adding hosts and host instances across multiple servers, spreading load across the group. The SQL Server MessageBox is usually the real bottleneck. As a result, it needs proper indexing, regular maintenance jobs, and enough hardware headroom. Pipeline and map complexity also matter. In fact, a poorly optimized map can slow down high-volume message flows more than the infrastructure itself does.
🚀 Deployment Considerations
BizTalk deployments typically ship as MSI packages, promoted through Dev, QA, and Production environments in sequence. Configuration, like endpoint URLs and credentials, should live outside the deployed artifacts, using BizTalk’s Deployment Framework or a similar tool. Rollback plans matter too, since a bad orchestration deployment can affect every connected system at once.
🏢 Real-World Use Cases
A logistics company might use this architecture to connect CargoWise shipment data to Salesforce, for customer visibility. At the same time, it can post invoices to Oracle Fusion for finance. A manufacturer, similarly, might use it to process incoming X12 purchase orders from retail partners. From there, it converts them into internal ERP orders and sends back 997 acknowledgments automatically. Both cases follow the same underlying pattern: receive, validate, transform, route.
✅ Best Practices
Keep maps and schemas versioned in source control, the same as any other code. Also, build orchestrations around a canonical internal format, rather than mapping directly between every pair of systems. Document party agreements clearly, since EDI trading partner setups are rarely self-explanatory months later. And test with real production-like data volumes before go-live, not just sample files.
🎯 When to Use This Architecture
This pattern fits best in two cases. First, when you already have BizTalk in place and need to extend it. Second, when EDI trading partner support is a hard requirement that BizTalk handles natively and well. It’s less suited to greenfield, cloud-native projects with no existing on-premises investment. In those cases, Azure Logic Apps often makes more sense from day one.
🔑 Key Takeaways
BizTalk Server remains a capable integration hub for connecting ERP, CRM, EDI, and API-based systems. Its strength is native EDI support and mature orchestration tooling. Its main constraint is infrastructure: scaling means adding servers, not just consumption-based cloud capacity. For companies already invested in BizTalk, extending it thoughtfully is usually more practical than a full rip-and-replace.
Tags: BizTalk Server, Enterprise Integration, Oracle Fusion Integration, Salesforce Integration, Dynamics 365 Integration, X12 EDI, EDIFACT, System Integration Architecture
Need help designing or extending a BizTalk integration? Talk to our integration team →