Oracle Fusion Cloud ERP and IBM Sterling integration

What moves between them

Purchase orders and supplier invoices from Oracle Fusion Cloud ERP are extracted on a schedule (typically daily or per procurement batch), translated to ANSI X12 850 (PO) or 810 (invoice) format, and routed through IBM Sterling to trading partners via AS2 or SFTP file transfer. Inbound EDI documents from trading partners (856 ASNs, 810 invoices, 820 remittance advices) arrive in IBM Sterling mailboxes, are polled and extracted, validated, and parsed back to structured procurement and financial data, then posted into Oracle Fusion Cloud ERP as received goods, supplier invoices, and payment references. Bi-directional master data (suppliers, customers, item hierarchies) is aligned first so downstream documents land on valid GL accounts and PO line items.

How ml-connector handles it

ml-connector stores Oracle Fusion Cloud ERP OAuth credentials and IBM Sterling Basic Auth or OAuth credentials encrypted, accepting the customer's unique Oracle Fusion Cloud ERP pod URL and IBM Sterling instance hostname and port. It polls Oracle Fusion Cloud ERP's REST API for newly created or updated purchase orders and invoices using LastUpdateDate filtering every 5 to 15 minutes, transforming each order to ANSI X12 850 format according to your trading partner's EDI profile stored in IBM Sterling. The X12 document is routed through IBM Sterling's REST API to the appropriate mailbox and delivery method (AS2, SFTP, or email). On the inbound side, ml-connector polls IBM Sterling's mailboxMessages endpoint every 1 to 5 minutes, extracts EDI payloads (856, 810, 820), parses them with X12 validation, maps line items and amounts to the original Oracle Fusion Cloud ERP purchase orders and GL accounts, and posts receipts, invoices, and payment records via Oracle Fusion Cloud ERP's REST endpoints. Because IBM Sterling holds EDI documents only in mailbox message payloads (not queryable REST resources), ml-connector tracks mailbox message timestamps to avoid re-processing. Both systems require polling since neither supports outbound webhooks. If an EDI translation fails or an Oracle Fusion Cloud ERP post fails partway through, ml-connector backs off, retries with exponential jitter, and logs the full transaction to an audit trail for manual recovery.

A real-world example

A mid-sized manufacturing company uses Oracle Fusion Cloud ERP for procurement and finance, and manages supplier relationships across automotive, electronics, and industrial parts vendors. Ninety percent of those vendors require ANSI X12 EDI (850 POs, 810 invoices, 856 ASNs) over AS2 or SFTP. Before the integration, the procurement team manually exported purchase orders from Oracle Fusion Cloud ERP, ran them through a translation tool to create X12 files, uploaded them to an SFTP folder, and received ASNs and invoices back as static files they had to manually reconcile against the GL. With Oracle Fusion Cloud ERP and IBM Sterling connected, each new purchase order in Oracle Fusion Cloud ERP is automatically sent as a compliant X12 850 to the supplier's EDI mailbox via IBM Sterling, and inbound ASNs and invoices are automatically validated, mapped, and posted back into Oracle Fusion Cloud ERP's receiving and AP workflows. Month-end reconciliation is faster because every received good and invoice is already in the system.

What you can do

• •Export Oracle Fusion Cloud ERP purchase orders as ANSI X12 850 transactions and route them through IBM Sterling to suppliers over AS2, SFTP, or other file protocols.
• •Receive inbound EDI 856 Advanced Shipment Notices from suppliers via IBM Sterling, parse them, and post goods receipts into Oracle Fusion Cloud ERP.
• •Map supplier invoices (EDI 810) received through IBM Sterling to Oracle Fusion Cloud ERP purchase orders and GL account combinations, creating supplier invoice records automatically.
• •Maintain two-way master data synchronization of suppliers, items, and GL accounts so EDI line items reference valid Oracle Fusion Cloud ERP dimensions.
• •Poll IBM Sterling mailboxes and Oracle Fusion Cloud ERP APIs on configurable schedules, with automatic retry and a full audit trail for every document translated and posted.

Questions

How does ml-connector handle the fact that Oracle Fusion Cloud ERP and IBM Sterling both require polling?

Neither Oracle Fusion Cloud ERP nor IBM Sterling supports outbound webhooks, so ml-connector polls both systems on a schedule you control (typically 5 to 15 minutes for Oracle Fusion Cloud ERP and 1 to 5 minutes for IBM Sterling mailboxes). Oracle Fusion Cloud ERP orders are filtered by LastUpdateDate to avoid re-processing, and IBM Sterling mailbox messages are tracked by timestamp. This approach adds latency compared to webhooks, but is reliable and suitable for batch procurement workflows.

What happens if an EDI translation fails or an Oracle Fusion Cloud ERP POST fails halfway through?

ml-connector logs the transaction in full, backs off, and retries with exponential jitter. If the error persists (e.g., a GL account does not exist in Oracle Fusion Cloud ERP), the record is flagged in the audit trail for manual review. You can correct the data in Oracle Fusion Cloud ERP or IBM Sterling and replay the transaction without re-downloading or re-translating the source document.

Does ml-connector support multiple trading partner EDI profiles in IBM Sterling?

Yes. IBM Sterling stores each trading partner's EDI profile (850 segment layout, 856 expected field mappings, delivery protocol) as a community or partner configuration. ml-connector uses the partner ID from the purchase order to look up the correct profile in IBM Sterling and applies the correct translation before routing, so different suppliers can have different X12 versions or field mappings in the same integration.