Oracle JD Edwards and SAP Ariba integration
Oracle JD Edwards EnterpriseOne runs financials and procurement on-premises. SAP Ariba runs sourcing, procurement, and invoicing in the cloud. Connecting the two brings the procurement activity buyers transact in Ariba into the JD Edwards ledger without re-keying. Purchase orders and approved invoices extracted from Ariba reporting jobs post into JD Edwards as purchase orders and AP vouchers, and supplier records stay aligned across both systems. ml-connector handles the very different APIs on each side and moves the data on a schedule you control.
What moves between them
The main flow runs from SAP Ariba into Oracle JD Edwards. ml-connector submits Ariba reporting jobs for purchase orders and invoice headers within a one-year window, polls until each job completes, downloads the paginated results, and posts them into JD Edwards as purchase orders and AP vouchers through named orchestrations, mapped to matching GL accounts and cost centers. Supplier records are aligned so vendors created or updated in JD Edwards keep Ariba registration and qualification status current through the Supplier Data API, which is the writable surface on the Ariba side. Ariba purchase order and invoice documents are read-only over REST, so ml-connector never writes those documents back to Ariba; it reads them and lands the financial result in JD Edwards.
How ml-connector handles it
ml-connector stores both credential sets encrypted. On the Ariba side it fetches a one-hour OAuth bearer token, caches it with refresh before expiry, sends the application key in the apiKey header, and appends the realm query parameter to every request. On the JD Edwards side it accepts the full AIS server URL per customer, exchanges the username and password for a session token, and re-authenticates automatically when a call returns HTTP 444 for an invalid token, which also happens after an AIS server restart. Because neither system pushes events, both are polled: Ariba through async reporting jobs filtered by an updated-date window with a stored high-water mark, and JD Edwards through data-service queries on the date-updated field. Reporting jobs are limited to a one-year span, so an initial backfill is split into annual chunks. Cost centers and GL accounts are mapped first so every voucher and purchase order line references a JD Edwards dimension that already exists. Ariba job submission is rate limited, returning HTTP 429 with a remaining-calls header, so ml-connector watches that header and backs off. Writes into JD Edwards require the pre-built orchestrations to be imported in Orchestrator Studio first, and since those orchestrations do not document idempotency, ml-connector checks for an existing document before creating one. The connector egress IP must be on the AIS server allowlist or calls return HTTP 405.
A real-world example
A mid-sized manufacturer with about 600 employees runs Oracle JD Edwards EnterpriseOne on-premises for finance and procurement and has rolled out SAP Ariba for sourcing and supplier-side purchasing across several plants. Before the integration, buyers approved purchase orders and invoices in Ariba, then the AP team exported reports and re-keyed the documents into JD Edwards as vouchers, which delayed approvals and left supplier records out of step between the two systems. With Oracle JD Edwards and SAP Ariba connected, approved Ariba purchase orders and invoices post into JD Edwards automatically against the right cost centers, and supplier status stays aligned, so the AP team stops re-typing documents and month-end close starts from matching data.
What you can do
- Read approved purchase orders and invoice headers from SAP Ariba reporting jobs and post them into Oracle JD Edwards as purchase orders and AP vouchers.
- Create JD Edwards vouchers through named orchestrations such as JDE_ORCH_04_Add_Supplier_Invoice rather than unsupported direct table writes.
- Keep supplier records aligned, updating Ariba registration and qualification status through the writable Supplier Data API.
- Bridge the Ariba OAuth bearer token, application key, and realm parameter with the JD Edwards session token, re-authenticating on invalid-token errors.
- Poll both systems on a schedule with rate-limit backoff and a full audit trail, since neither pushes events.
Questions
- Which direction does data move between Oracle JD Edwards and SAP Ariba?
- The main flow is SAP Ariba into Oracle JD Edwards. Approved purchase orders and invoice headers extracted from Ariba reporting jobs post into JD Edwards as purchase orders and AP vouchers. Supplier records are aligned in both directions, with JD Edwards vendor changes keeping Ariba registration and qualification status current. Ariba purchase order and invoice documents are read-only over REST, so those documents are never written back to Ariba.
- Why does the integration poll instead of using webhooks?
- Neither system offers a simple outbound webhook for this kind of sync. Oracle JD Edwards has no native push to an external URL, and SAP Ariba serves bulk procurement data through async reporting jobs rather than event pushes. ml-connector therefore polls both sides, submitting Ariba jobs filtered by an updated-date window and querying JD Edwards on its date-updated field, and stores a high-water mark so each run only picks up new changes.
- How are writes handled on the JD Edwards side?
- JD Edwards does not support direct table inserts over REST. ml-connector creates vouchers and purchase orders through named orchestrations such as JDE_ORCH_04_Add_Supplier_Invoice, which the customer must first import into Orchestrator Studio. Because those orchestrations do not document idempotency, the connector checks for an existing document before creating one to avoid duplicates, and every record is audited so a failed post can be replayed.
Related integrations
More Oracle JD Edwards integrations
Other systems that connect to SAP Ariba
Connect Oracle JD Edwards and SAP Ariba
Free to use. Add your credentials, ping your real systems, and see if we fit.
Get started