Oracle JD Edwards and Looker integration

What moves between them

Data flows one direction, from Oracle JD Edwards into Looker. ml-connector polls JD Edwards for open AP invoices (F0411 table), purchase orders (F4301, F4311), GL account masters (F0901), and cost centers, then loads the records into your warehouse staging tables that Looker models expose via predefined looks and dashboards. The polling runs on a schedule you set, typically daily or on-demand.

How ml-connector handles it

ml-connector exchanges JDE credentials (username, password, AIS Server hostname and port) for a session token on each polling cycle, refreshing the token after 30 to 60 minutes when calls return HTTP 444. It queries JD Edwards F-tables with a date filter on UPMJ to fetch only changed records, handles pagination via the moreRecords flag and POST /next requests, and builds staging records that include GL account codes, cost center dimensions, and supplier names. For Looker, ml-connector presents OAuth2 credentials to obtain a fresh bearer token before querying, then loads transformed records into your warehouse via INSERT or UPSERT on pre-staging tables that Looker models already define. JD Edwards IP allowlists require the connector's egress IPs to be whitelisted. Session tokens are tied to a JDE service account user license, so the license must remain valid. Looker tokens expire after 1 hour and are re-requested before each sync cycle.

A real-world example

A mid-market manufacturing company runs Oracle JD Edwards for procure-to-pay and GL accounting across three plants and a shared services center, and uses Looker for spend analysis and cost center reporting. Before integration, the finance team exported AP registers and PO summaries from JD Edwards every week, loaded them into Excel, and manually mapped cost center codes to Looker's dimension tables. With JD Edwards and Looker connected, new invoices and POs appear in Looker dashboards within a few hours of posting, complete with GL codes and cost allocations, and the finance team spends their time analyzing variance and headcount cost instead of re-keying data.

What you can do

• •Poll Oracle JD Edwards for open AP invoices, POs, GL account masters, and cost centers on a daily or ad-hoc schedule.
• •Transform JD Edwards F-table records into warehouse-ready staging format with GL codes and cost center dimensions intact.
• •Load invoices and purchase orders into Looker-connected warehouse tables so analysts can build spend, variance, and allocation reports.
• •Handle JD Edwards AIS Server token expiration and Looker OAuth2 token refresh, with transparent re-authentication on each sync cycle.
• •Track last-polled timestamps and request only changed records from JD Edwards using the UPMJ date filter.

Questions

Why does ml-connector poll JD Edwards instead of using webhooks?

Oracle JD Edwards has no native outbound webhooks, so ml-connector polls the F-tables on a schedule tied to your AP posting and GL close cycles. The polling uses UPMJ date filters to fetch only changed records, so you are not re-importing data you have already seen.

How does cost center and GL account mapping work in Looker?

ml-connector extracts the GL account codes (F0901) and cost center codes from each JD Edwards invoice and PO line, then includes them as dimensions in the warehouse staging tables. Looker's models use those dimensions to enable filtering, grouping, and variance analysis by cost center and account without a separate mapping step.

What happens when JD Edwards session tokens or Looker OAuth2 tokens expire?

ml-connector refreshes the JD Edwards session token every 30 to 60 minutes by requesting a new one, and it requests a fresh Looker OAuth2 bearer token before each sync cycle (tokens expire after 1 hour). Both re-authentications are transparent and do not require manual intervention or restart.