Oracle PeopleSoft and Google BigQuery integration

What moves between them

The flow runs from Oracle PeopleSoft into Google BigQuery. ml-connector polls PeopleSoft on a schedule for AP invoices, payment status, purchase orders, requisitions, supplier records, and posted GL journals, then inserts each record into the configured BigQuery dataset and table, one table per entity type. The cadence is a conservative interval such as every 5 to 15 minutes, since PeopleSoft is on-premise and has no published rate limit. BigQuery is the analytical destination and holds no source records to push back, so the connector does not write data from BigQuery into PeopleSoft.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For PeopleSoft it accepts the customer base URL, port, and node name and sends Basic Auth on each REST or SOAP call, since there is no shared hostname or central token endpoint. For BigQuery it signs a JWT with the service account private key, exchanges it for an access token at Google's token endpoint, and refreshes the token before the one hour expiry. PeopleSoft REST inquiry endpoints return all matching rows with no cursor, so the connector always passes date-range filters to bound each pull and avoid saturating the Tuxedo queue; richer entity data is read through SOAP Component Interfaces. Each PeopleSoft entity maps to a configured BigQuery dataset and table, and rows are written with the PeopleSoft key, such as invoice or PO number, as the insertId so BigQuery's best-effort dedup absorbs retries. Edge cases handled: PeopleSoft 401 means re-check the OPRID rather than retry blindly, BigQuery streaming rows can take up to 90 seconds to appear in table reads, and the service account private key PEM newlines are preserved so JWT signing does not break.

A real-world example

A mid-sized regional hospital network runs Oracle PeopleSoft Financials on its own servers for accounts payable, procurement, and the general ledger across several facilities. The finance and analytics team needs spend and payables dashboards, but PeopleSoft reporting is slow and analysts were exporting voucher and payment extracts to spreadsheets every week to build them by hand. With Oracle PeopleSoft connected to Google BigQuery, invoices, payments, purchase orders, and posted journals land in BigQuery tables on a schedule, and the analysts query current finance data directly in SQL. The weekly manual export is gone, and dashboards reflect what is in the ledger without re-keying.

What you can do

• •Poll Oracle PeopleSoft AP invoices, payment status, purchase orders, requisitions, suppliers, and posted GL journals on a schedule you set.
• •Write each PeopleSoft entity into its own configured Google BigQuery dataset and table for SQL reporting and analytics.
• •Bridge PeopleSoft Basic Auth against your own server URL and node name with the BigQuery service account JWT token, refreshed hourly.
• •Bound each pull with date-range filters and use the PeopleSoft record key as the BigQuery insertId so retries do not create duplicates.
• •Read richer entity detail through PeopleSoft SOAP Component Interfaces where the delivered REST inquiry endpoints stop short.

Questions

Which direction does data move between Oracle PeopleSoft and Google BigQuery?

Data moves from Oracle PeopleSoft into Google BigQuery. The connector reads finance and procurement records from PeopleSoft and writes them into BigQuery tables for reporting. BigQuery is a data warehouse with no native ERP records to send back, so the connector does not write from BigQuery into PeopleSoft.

How does the integration authenticate to each side?

PeopleSoft uses HTTP Basic Auth with an OPRID and password sent on each call against your own server URL and Integration Broker node name, since PeopleSoft is self-hosted and has no shared hostname. BigQuery uses a Google service account: ml-connector signs a JWT with the private key and exchanges it for an access token. That token expires after one hour, so the connector refreshes it before expiry.

Does this integration use webhooks or polling?

It uses polling. PeopleSoft has no conventional webhooks; its outbound async publish must be configured by a PeopleSoft admin to reach an external endpoint, so the connector treats it as pull-only. BigQuery sends no webhooks at all. The connector reads PeopleSoft on a conservative schedule, typically every 5 to 15 minutes, and passes date-range filters to keep each pull bounded.