Sage 300 and SAP Ariba integration

What moves between them

The main flow is bidirectional. ml-connector reads purchase orders and vendor master data from Sage 300 and writes them into SAP Ariba as requisitions and supplier records for procurement visibility. In the reverse direction, ml-connector reads invoices from Ariba on a daily schedule and writes them into Sage 300's AP module for three-way matching against POs and goods receipts. Supplier and contract updates from Ariba can also be written back to Sage 300's vendor master on a weekly or event-driven cadence.

How ml-connector handles it

ml-connector stores Sage 300 HTTP Basic Auth credentials (username and password, both uppercase per the API requirement) and SAP Ariba OAuth client ID, secret, and API key. For Sage 300, it polls the customer's self-hosted IIS endpoint on a schedule using OData filters (DocumentDate gt '<date>') and pagination ($skip, $top). For Ariba, it requests OAuth tokens and caches them for the one-hour lifetime, refreshing before expiry. When reading invoices or POs from Ariba, ml-connector submits async reporting jobs filtered by the one-year window constraint, polls for job completion via jobId, and pages through results at up to 50,000 records per call. Sage 300 purchase orders are mapped to Ariba requisitions using line item amounts and GL accounts; Ariba invoices are mapped to Sage 300 AP batches using vendor codes and line descriptions. Because Sage 300 is a scheduled pull and Ariba write operations use SOAP/cXML (not REST), ml-connector uses a polling cadence tied to your procure-to-pay cycle and enqueues failed invoice writes for retry with exponential backoff. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized distributor runs Sage 300 on-premise for AP, AR, and inventory, and uses SAP Ariba for strategic sourcing and supplier management across 150+ vendors. Before the integration, the procurement team created POs in Sage 300 and manually entered them into Ariba for sourcing visibility, then received invoices in Ariba and re-keyed them into Sage 300 for three-way matching. With Sage 300 and Ariba connected, POs flow automatically from Sage 300 to Ariba on creation, giving suppliers and sourcing managers real-time visibility; invoices received in Ariba post into Sage 300's AP module with vendor and PO reference intact, eliminating the manual re-entry step and enabling automated matching and payment processing.

What you can do

• •Read purchase orders and vendor records from Sage 300 and write them into SAP Ariba as requisitions and supplier updates.
• •Read invoices from SAP Ariba and write them into Sage 300's AP module with automatic GL account and vendor mapping.
• •Handle Sage 300 HTTP Basic Auth with uppercase username and password validation per API requirements.
• •Manage SAP Ariba OAuth 2.0 token refresh and dual-key authentication (OAuth token plus static API key header) on every call.
• •Poll both systems on a schedule tied to your procure-to-pay cycle, with automatic retries, audit trail, and replay capability on all records.

Questions

Which direction does data flow between Sage 300 and SAP Ariba?

The flow is bidirectional. Purchase orders and vendor records flow from Sage 300 to Ariba for procurement visibility. Invoices and supplier updates flow from Ariba back to Sage 300 for AP processing and three-way matching. The sync is scheduled polling on both sides, not event-driven, since Sage 300 is on-premise with no webhooks and Ariba's REST APIs are read-only.

Why does SAP Ariba require both OAuth and an API key?

SAP Ariba Open APIs require OAuth 2.0 bearer token authentication plus a static API key header on every single call. ml-connector caches the OAuth token for its one-hour lifetime and refreshes it before expiry, presenting both credentials on each request. Missing either returns a 401 error.

How does the integration handle Sage 300's HTTP Basic Auth and the uppercase requirement?

ml-connector stores Sage 300 credentials encrypted and converts the username and password to uppercase before encoding them in the HTTP Basic Auth header, as the API requires. It validates the credentials against the customer's IIS endpoint and confirms that the API user has the Web API security group assigned in Sage 300's Administrative Services.