Infor CloudSuite and SAP Ariba integration

What moves between them

The main flow runs from SAP Ariba into Infor CloudSuite. ml-connector submits Ariba reporting jobs for purchase orders and supplier invoices, filtered by an updated-date window, polls until each job finishes, downloads the paginated results, and posts the documents into Infor CloudSuite as purchase orders and AP invoices against the matching suppliers, currencies, and GL accounts. Supplier master records are aligned in both directions: new and changed suppliers from Infor seed Ariba supplier profiles, and Ariba registration and qualification status flows back so the Infor vendor record reflects approval state. Ariba transactional documents are read-only over REST, so ml-connector never writes invoices or POs back into Ariba; only supplier status writes go to the Ariba Supplier Data API.

How ml-connector handles it

ml-connector stores both credential sets encrypted and bridges two different OAuth2 styles. For SAP Ariba it fetches a client-credentials bearer token and attaches the apiKey header and the realm query parameter to every request, refreshing the token before its one-hour expiry. For Infor CloudSuite it accepts the full .ionapi field set per customer, since every tenant has its own ION gateway URL and token endpoint, runs the password grant, and includes the CONO company parameter that M3 API programs require. Because neither system pushes events, it polls: Ariba on the reporting-job pattern with a stored last-successful updated-date cursor, and Infor on a schedule for supplier and document reads. Supplier and currency codes are mapped first so every posted invoice and PO references an Infor supplier and GL account that already exists. Real edge cases are handled directly: Ariba reporting jobs cap each filter window at one year, so initial backfill is split into annual chunks; Ariba job submission is rate limited to a few calls per minute, so the connector watches the X-RateLimit-Remaining-minute header and backs off; and Infor M3 Add transactions are not idempotent, so it queries by invoice or PO number before creating to avoid duplicates. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturer with around 600 employees runs Infor CloudSuite M3 for production and finance and uses SAP Ariba for sourcing and supplier onboarding across several buying categories. Before the integration, the AP team logged into Ariba each week, ran reporting downloads of approved purchase orders and supplier invoices, and re-keyed the totals into Infor by hand, while a separate person maintained the same supplier list in both systems. With Infor CloudSuite and SAP Ariba connected, approved POs and invoices flow from Ariba into Infor automatically, matched to the right suppliers and GL accounts, and supplier records stay aligned so a vendor approved in Ariba is ready to transact in Infor. The weekly re-keying disappears and month-end close starts with procurement documents already in the ledger.

What you can do

• •Submit SAP Ariba reporting jobs for purchase orders and supplier invoices, then post the results into Infor CloudSuite AP and purchasing.
• •Keep supplier master records aligned, seeding Ariba profiles from Infor and reflecting Ariba registration and qualification status back to Infor.
• •Map Ariba supplier and currency codes to Infor suppliers and GL accounts so every document lands on a valid account.
• •Bridge Ariba client-credentials tokens with apiKey and realm to the Infor ION password-grant bearer token.
• •Poll on a schedule with a stored updated-date cursor, annual backfill chunking, rate-limit backoff, and a full audit trail per record.

Questions

Which direction does data move between Infor CloudSuite and SAP Ariba?

The main flow is SAP Ariba into Infor CloudSuite. Purchase orders and supplier invoices extracted from Ariba reporting jobs post into Infor as POs and AP invoices, while supplier master data is aligned in both directions. Ariba transactional documents are read-only over REST, so ml-connector only writes supplier registration and qualification status back to Ariba, never invoices or POs.

Why does SAP Ariba use reporting jobs instead of a simple data pull?

SAP Ariba has no plain GET endpoint for bulk procurement documents. Instead you submit a reporting job filtered by an updated-date window, poll until it completes, then download paginated results up to fifty thousand records per call. ml-connector runs this submit, poll, and download cycle, stores the last successful updated-date as a cursor, and splits initial backfill into annual chunks because each job window is capped at one year.

How does the integration handle two different authentication schemes and the lack of webhooks?

SAP Ariba needs an OAuth2 client-credentials bearer token plus a static apiKey header and the realm as a query parameter, while Infor CloudSuite uses an OAuth2 password grant with credentials from the tenant's .ionapi file. ml-connector stores both encrypted, refreshes each token before expiry, and supplies the per-tenant Infor gateway URL and CONO company value. Since neither system pushes events, it polls both on the schedule you set and tracks high-water marks so nothing is processed twice.