IFS Cloud and Snowflake integration

What moves between them

The primary flow is IFS Cloud into Snowflake. After each polling cycle, ml-connector reads IFS supplier invoices, purchase orders, GL vouchers, and customer orders filtered by modified timestamp, transforms them to align with Snowflake table schemas partitioned by company code and entity type, and writes them into the warehouse. GL account master data and dimension tables are synced less frequently to keep reference tables current. The integration also reads reconciled totals back from Snowflake to validate that the warehouse balance matches the IFS general ledger. No data flows back to IFS.

How ml-connector handles it

ml-connector stores the IFS tenant URL, client credentials, and Snowflake RSA key pair encrypted in its secure vault. On each poll cycle it refreshes the OAuth2 token against the IFS tenant endpoint, then queries IFS OData endpoints filtered on modified timestamp and company code to retrieve new or changed records. It respects IFS page size limits (typically 5000 elements) and manages pagination to ensure large result sets are handled correctly. Before writing to Snowflake it captures the current ETag from IFS for concurrency detection, then transforms IFS entities to Snowflake column names and data types. Writes use SQL INSERT or UPSERT operations partitioned by company code. If an IFS ETag changes between read and write, ml-connector retries the read cycle. Snowflake rate limits and async query execution are managed with exponential backoff and polling loops. The schedule is configurable per customer, typically tied to close dates rather than running continuously, to align with financial month-end procedures.

A real-world example

A global manufacturing company runs IFS Cloud across three regions with separate company codes for EMEA, APAC, and Americas. The finance team uses Snowflake for analytics, reporting, and reconciliation but spends the first two weeks of each month waiting for the accounting team to export invoices and vouchers from IFS and load them manually into Snowflake. With IFS Cloud and Snowflake connected, at the close date ml-connector automatically polls IFS for all new invoices, purchase orders, and GL vouchers for each region, writes them into Snowflake tables tagged with company code, and flags any discrepancies. The analytics team can immediately run variance reports against current data, and the accounting team can start reconciliation work instead of data entry.

What you can do

• •Poll IFS Cloud supplier invoices, purchase orders, GL vouchers, and customer orders on a configurable schedule aligned to your month-end close.
• •Write financial records into Snowflake tables partitioned by company code so multiple business units can query their own data safely.
• •Handle IFS OAuth2 token refresh, ETag-based optimistic concurrency, and page size limits automatically.
• •Transform IFS OData entities to Snowflake column schemas and detect new or changed records using modified timestamps.
• •Read reconciled totals back from Snowflake and validate that warehouse balances match the IFS general ledger within tolerance.

Questions

Why poll instead of using IFS Event Actions?

IFS Event Actions require manual per-customer configuration in the IFS admin UI and are not self-registerable through an API. Polling via OData with timestamp filters is reliable, repeatable, and works across all IFS Cloud versions without requiring customer admin involvement. Polling also ensures your sync schedule is tied to your close calendar, not to ad-hoc business events.

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

IFS uses ETag headers to enforce optimistic concurrency on mutations. ml-connector reads each record and captures its ETag before writing to Snowflake. If the ETag changes between read and write (meaning another system updated the record in IFS), ml-connector detects the conflict, retries the read cycle to fetch the latest version, and re-attempts the write. This ensures no data loss if records are modified in IFS during the sync.

Can ml-connector sync data from multiple IFS company codes to the same Snowflake warehouse?

Yes. ml-connector queries IFS by company code and writes each entity into Snowflake tables with the company code as a partition or dimensional column. Multiple company codes can be configured per Snowflake instance, and each sync cycle pulls records for all configured codes in sequence, so your Snowflake warehouse accumulates data across all IFS business units.