IFS Cloud and JAGGAER integration

What moves between them

Purchase orders and invoices flow from IFS Cloud into JAGGAER on a schedule you define. When a new purchase order is created in IFS Cloud, ml-connector reads it via OData query, maps it to JAGGAER PO structure, and writes it to JAGGAER. Similarly, when JAGGAER invoices are received, they flow back into IFS Cloud as posting proposals or GL entries. Supplier master data is aligned in both directions so sourcing rules and GL account assignments remain consistent.

How ml-connector handles it

ml-connector manages two separate OAuth 2.0 flows: one against the IFS Cloud tenant-specific token endpoint and one against JAGGAER's customer-instance token endpoint. It polls IFS Cloud OData entities with $filter clauses on LastModifiedDate to find new or changed records, captures the ETag header from each response, and includes that etag in the If-Match header when performing updates, satisfying IFS's optimistic concurrency requirement. When writing to JAGGAER, it uses standard OAuth bearer token authentication. Because IFS Cloud does not offer a push event mechanism via API, polling is the only reliable pattern. Requests to both systems are subject to rate limiting: ml-connector respects IFS Cloud's 1000-per-minute limit and JAGGAER's throttling by backing off with exponential jitter on HTTP 429 responses. Supplier records are mapped first so purchase order GL account assignments exist in IFS before orders are written. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturing company runs IFS Cloud for ERP and production planning, and uses JAGGAER for strategic sourcing and invoice management across multiple procurement departments. Before the integration, purchase requisitions created in IFS Cloud were manually exported and re-entered into JAGGAER, and invoices received in JAGGAER had to be manually matched and entered as proposals in IFS, creating delays in month-end close. With IFS Cloud and JAGGAER connected, new purchase orders flow into JAGGAER automatically, supplier contracts and pricing are visible to planners in IFS, and invoice receipts post directly into IFS as posting proposals with the correct GL accounts. The procurement cycle is faster, invoice discrepancies surface earlier, and manual re-keying is eliminated.

What you can do

• •Sync purchase orders from IFS Cloud into JAGGAER with correct GL account and supplier mapping.
• •Post JAGGAER invoice receipts into IFS Cloud as posting proposals or GL entries.
• •Keep supplier master data and GL account assignments aligned in both directions.
• •Manage OAuth 2.0 authentication for both IFS Cloud's tenant-specific token endpoint and JAGGAER's customer instance.
• •Handle IFS OData ETag concurrency requirements and rate limits with retry logic and full audit trail.

Questions

How does ml-connector handle IFS Cloud's OData ETag requirement?

IFS Cloud enforces optimistic concurrency control via OData ETag headers. ml-connector reads each record to capture its @odata.etag value, then includes that etag in the If-Match header when performing updates or mutations. This prevents lost updates if multiple clients are writing to the same record.

Which direction do purchase orders and invoices flow?

Purchase orders flow from IFS Cloud into JAGGAER. Invoices and receipt acknowledgments flow from JAGGAER back into IFS Cloud as posting proposals or GL entries. Supplier master data is synced in both directions so sourcing rules and account assignments remain consistent across both systems.

Does JAGGAER's pull-only API require polling, or can ml-connector receive push events?

JAGGAER's J1P REST API is pull-only for standard integration. Event-driven configuration exists but is not self-serve and requires JAGGAER professional services engagement. ml-connector polls on a schedule you define, filtering by modified timestamp or state to find new records since the last sync.