Oracle JD Edwards and Snowflake integration

What moves between them

Data flows from Oracle JD Edwards into Snowflake. ml-connector polls JD Edwards for changes to suppliers, purchase orders, AP invoices, GL transactions, GL accounts, and item master records on a cadence you configure, typically daily or weekly. Each record is transformed and written into corresponding Snowflake tables where it is available for analytics, reconciliation, and audit queries. GL postings are read-only in JD Edwards, so ml-connector moves them into Snowflake as historical records that can be joined with cost allocations and payroll GL.

How ml-connector handles it

ml-connector stores the JD Edwards AIS Server URL and credentials encrypted, and obtains a session token by calling the /tokenrequest endpoint with the stored username and password. It stores the Snowflake Key Pair or PAT token encrypted and presents it as a JWT (Key Pair) or bearer token (PAT) on each Snowflake call. Because JD Edwards is on-premises and has no outbound webhooks, ml-connector polls JD Edwards on your schedule using date filters on the UPMJ (date updated) field to find changed records since the last poll. Snowflake requires explicit warehouse configuration (AUTO_RESUME = TRUE) and network policy rules to allow the connector's egress IPs. ml-connector batches records into Snowflake write calls, maps JD Edwards F-table entities to Snowflake table schemas on your first run, and tracks poll timestamps to ensure no duplicate ingestion. If a poll fails or a Snowflake write times out, ml-connector retries with exponential backoff, and every record is logged in an audit trail so replays are possible.

A real-world example

A mid-market financial services company runs Oracle JD Edwards for accounts payable, general ledger, and vendor management across multiple legal entities. They deploy Snowflake to consolidate financial data from JD Edwards and other sources for month-end reporting, regulatory compliance, and audit. Before the integration, the accounting team exported AP and GL data manually from JD Edwards each month, reformatted it in Excel, and loaded it into Snowflake for reporting. With JD Edwards and Snowflake connected, AP invoices and GL transactions flow automatically into Snowflake every night, journal entries reconcile without re-keying, and the compliance team has a continuous audit trail of all postings and changes.

What you can do

• •Poll Oracle JD Edwards on a schedule and load AP invoices, purchase orders, and GL transactions into Snowflake without manual export.
• •Authenticate JD Edwards with session tokens and Snowflake with Key Pair or PAT, bridging on-premises and cloud auth models.
• •Map JD Edwards F-tables to Snowflake user-defined tables, with schema creation on first run.
• •Track polling timestamps and handle retries so no records are missed or duplicated.
• •Log every record move in an audit trail for compliance and replay if a load fails.

Questions

Does Oracle JD Edwards have webhooks to push data to Snowflake?

No. JD Edwards has no native outbound webhooks. ml-connector polls JD Edwards on a schedule you define, using date filters to find recently updated records since the last poll. This is typical for on-premises ERPs and works well for daily or weekly batch loads.

How does the integration handle JD Edwards on-premises URLs and session token expiry?

JD Edwards customers provide the full AIS Server URL and credentials as part of the connection setup, since each customer hosts their own AIS Server. ml-connector obtains a fresh session token by calling the /tokenrequest endpoint before the stored token expires (default 30 to 60 minutes), so subsequent polls do not fail due to token timeout.

What Snowflake authentication does ml-connector support?

ml-connector supports both Key Pair Authentication (recommended for server-to-server integrations, using an RSA private key and JWT) and Programmatic Access Tokens (long-lived bearer tokens). Both are stored encrypted and used on every Snowflake API call.