Infor CloudSuite and Google BigQuery integration

What moves between them

The main flow runs from Infor CloudSuite into Google BigQuery. ml-connector polls the ION API Gateway for new and changed suppliers, supplier invoices, purchase orders, payments, and GL accounts, then loads each record type into its matching BigQuery table in the configured dataset. Cadence is whatever you schedule, since neither system pushes events. BigQuery is treated as a read-only reporting destination for this pair, so ml-connector does not write ERP transactions back into Infor from the warehouse.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Infor side it accepts the full .ionapi field set per customer, builds the token URL from the OAuth provider and token path fields, requests a Bearer token with the service account access and secret keys, and refreshes it before the one to twenty-four hour lifetime expires rather than reacting to a 401. It supplies the company number that most M3 calls require and pages through list transactions using maxRecords, or Bookmark cursors on SyteLine. Rows are loaded into BigQuery with a JWT-bearer token, also refreshed before its one hour expiry, and each row carries a stable insertId built from the Infor record key so a re-run does not create duplicates. The private key newlines from the service account JSON are preserved so JWT signing does not break. Because Infor has no idempotency key, the connector tracks each external ID to avoid re-loading the same record, and it honors Infor 429 throttling and BigQuery quota limits with exponential backoff. New BigQuery columns are added as nullable so schema changes stay non-destructive.

A real-world example

A mid-sized industrial manufacturer running Infor CloudSuite M3 across several plants wants a single finance dashboard but cannot run heavy reporting queries against the ERP without slowing down operations. Before the integration, an analyst exported supplier, invoice, and PO extracts from Infor by hand each week and reloaded them into a reporting database, and the numbers were always days stale. With Infor CloudSuite and Google BigQuery connected, those records load into BigQuery automatically on a schedule, so spend analysis, supplier scorecards, and accrual reports run on near-current data in SQL without adding load to the ERP and without the manual export step.

What you can do

• •Load Infor CloudSuite suppliers, supplier invoices, purchase orders, payments, and GL accounts into Google BigQuery tables for SQL reporting.
• •Poll the Infor ION API Gateway on the schedule you set, since neither system pushes change events.
• •Bridge the Infor service account OAuth token from the .ionapi file and the BigQuery service account JWT, refreshing each before it expires.
• •Stamp every row with a stable insertId so a re-run or retry does not duplicate data in BigQuery.
• •Page through M3 and SyteLine list results and respect Infor and BigQuery rate limits with backoff and a full audit trail.

Questions

Which direction does data move between Infor CloudSuite and Google BigQuery?

The flow is Infor CloudSuite into Google BigQuery. Suppliers, invoices, purchase orders, payments, and GL accounts are read from the ION API Gateway and loaded into BigQuery tables. BigQuery is used as a read-only reporting destination here, so ml-connector does not write transactions back into Infor from the warehouse.

Does this integration use webhooks, or does it poll?

It polls. Infor CloudSuite has no self-service webhook for connectors, and Google BigQuery sends no outbound events at all. ml-connector reads changed Infor records on a schedule by filtering list transactions on modified date or status, then loads them into BigQuery.

How does the integration avoid duplicate rows in BigQuery?

Infor has no native idempotency key, so ml-connector builds a stable insertId from each Infor record key and includes it on the BigQuery streaming insert, which gives best-effort deduplication. The connector also tracks which external IDs it has already loaded, so a re-run or a retry after an error does not create duplicate rows.