QAD and Google BigQuery integration

What moves between them

The main flow runs from QAD into Google BigQuery. ml-connector reads QAD purchase orders, supplier invoices, goods receipts, and GL entries on a schedule and writes them as rows into the BigQuery dataset and tables you configure, for example purchase_orders, invoices, and gl_entries. Supplier and item master records flow the same direction to keep the warehouse dimensions current. Because BigQuery also supports reads, a flow can submit a query job and pull an aggregated result back into QAD when one is needed, but the steady flow is QAD into BigQuery. Each record is mapped to a configured datasetId and tableId rather than a fixed object name, since BigQuery tables are customer-defined.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BigQuery side it signs a JWT with the service account private key, exchanges it at the Google token endpoint for a bearer token scoped to BigQuery, and refreshes that token before the one-hour expiry. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base URL, and validates entity paths against that instance. Writes go through the streaming insert endpoint with an insertId on each row for best-effort deduplication, and query and load jobs carry a caller-supplied jobId so a retry returns the existing job instead of creating a duplicate. Each QAD record type maps to a configured dataset and table, and partitioned tables let polling queries filter on a timestamp column cheaply. Because QAD cloud is pull-only and BigQuery sends no events, the connector polls QAD on a schedule rather than waiting for a push. A common gotcha is the service account private key, whose PEM block contains literal newline characters that must be preserved or JWT signing fails; ml-connector stores the key intact. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer runs QAD Adaptive ERP across three plants and wants a single warehouse for spend and finance reporting. Before the integration, an analyst exported purchase orders and supplier invoices from QAD to spreadsheets every week and loaded them into BigQuery by hand, so the dashboards were always a few days stale and the manual load was error-prone. With QAD and Google BigQuery connected, purchase orders, invoices, receipts, and GL entries stream into BigQuery on a schedule, mapped to the right tables. The spend dashboards refresh from current data, and the weekly export and manual load are gone.

What you can do

• •Stream QAD purchase orders, supplier invoices, goods receipts, and GL entries into Google BigQuery tables on a schedule.
• •Keep supplier and item master tables in BigQuery current with the matching QAD records.
• •Write rows through the streaming insert endpoint with an insertId for best-effort deduplication on retry.
• •Authenticate Google BigQuery with a service account JWT-bearer token and QAD with its tenant-specific login.
• •Poll on a schedule you control, with retries and a full audit trail on every record.

Questions

Which direction does data move between QAD and Google BigQuery?

The steady flow is QAD into Google BigQuery. ml-connector reads purchase orders, supplier invoices, receipts, and GL entries from QAD and writes them as rows into your BigQuery tables. Because BigQuery also supports reads, a flow can run a query job and pull an aggregated result back into QAD when one is needed.

Does Google BigQuery send webhooks when data changes?

No. BigQuery has no outbound webhook or change-data-capture push. Since QAD cloud is also pull-only, ml-connector polls QAD on a schedule and writes the records into BigQuery, and where it reads from BigQuery it queries a timestamp or partition column to detect new rows.

How does the integration authenticate to Google BigQuery?

It uses a Google service account. ml-connector signs a JWT with the service account private key, exchanges it at the Google token endpoint for a bearer token scoped to BigQuery, and refreshes the token before its one-hour expiry. The private key PEM block contains literal newlines that must be preserved, which the connector stores intact so JWT signing keeps working.