Oracle JD Edwards and Workday HCM integration

What moves between them

Worker and cost center records flow from Workday HCM into Oracle JD Edwards. After each payroll run, ml-connector reads Workday's general ledger journals (Accounting_Journals) and posts the labor cost entries into JD Edwards' F0911 Account Ledger, mapped to the matching GL accounts and cost centers. Worker additions, terminations, and transfers in Workday trigger updates to JD Edwards' F0101 Address Book (employee records) and F0401 Supplier Master if the worker also appears in a supplier context. Cost centers are reconciled bidirectionally so both systems agree on the valid allocation dimensions. Polling occurs on a cadence tied to your payroll calendar, typically daily or weekly depending on your close process.

How ml-connector handles it

ml-connector stores both credential sets encrypted: the JD Edwards AIS Server host URL and user credentials for session token requests, and the Workday OAuth2 refresh token. On the JD Edwards side, it manages session token lifetime (typically 30-60 minutes) and refreshes when a call returns an HTTP 444 status code indicating token expiry. Tokens are tied to a JDE service account license, so the connector re-authenticates as that license owner. On the Workday side, it uses the long-lived refresh token to obtain new 60-minute access tokens and retries on HTTP 429 with exponential backoff respecting the Retry-After header. Cost center mapping happens first so every GL journal line references a GL account and cost center that exists in both systems before the entry is created. JD Edwards requires pagination via maxPageSize parameter (default 100) with moreRecords flag indicating more data follows, so ml-connector tracks pagination state across retries. Workday's SOAP API has a maximum record-per-request limit around 2000 rows, so large GL posting batches are split. Every record carries a full audit trail keyed by worker ID and cost center to detect and skip duplicates if a poll runs again over the same time window.

A real-world example

A mid-sized discrete manufacturer with multiple plants and a head office runs Oracle JD Edwards EnterpriseOne on-premises for accounting and procurement. The company uses Workday HCM in the cloud for payroll and worker management. Before the integration, the accounting team exported payroll registers from Workday each pay period and manually re-entered labor cost totals into JD Edwards by cost center, then spent the first week of month-end chasing GL reconciliation errors and disagreements between Workday headcount and JD Edwards payroll accounts. With Workday and JD Edwards connected, each payroll run's general ledger entries post into JD Edwards automatically, allocated to the correct cost center, and worker changes are reflected in both systems. The accounting close process now starts with labor accounts already aligned, eliminating manual re-keying.

What you can do

• •Post Workday payroll general ledger entries into Oracle JD Edwards accounts and cost centers after each pay run without manual re-entry.
• •Keep worker records synchronized between Workday HCM and JD Edwards Address Book across hires, terminations, and transfers.
• •Align cost centers, departments, and GL account mappings bidirectionally so payroll allocations land on valid JD Edwards dimensions.
• •Manage JD Edwards AIS Server session token refresh and Workday OAuth2 token lifecycle, retrying on rate limits and token expiry.
• •Poll on a schedule tied to your payroll calendar with batch deduplication and a complete audit trail on every financial and worker record.

Questions

Which direction does data move between Oracle JD Edwards and Workday HCM?

The primary flow is from Workday into JD Edwards. Payroll general ledger entries and worker records move from Workday into JD Edwards, while cost centers and GL account mappings are aligned in both directions to ensure posting destinations exist before transactions are created. GL entries are read-only in Workday, so ml-connector does not write financial data back to payroll.

How does the integration handle JD Edwards' on-premises infrastructure and lack of webhooks?

The customer provides the full AIS Server hostname and port as part of the credential setup, since JD Edwards has no shared public API endpoint. ml-connector manages the session token lifecycle (obtaining tokens via /jderest/v2/tokenrequest and refreshing on HTTP 444 status) and polls for new records on a customer-defined schedule using date filters on UPMJ and DGJ fields rather than waiting for a push from JD Edwards.

What happens if Workday rate-limits the integration?

Workday returns HTTP 429 with a Retry-After header indicating the backoff interval. ml-connector respects that header and retries the request after the specified delay. If an entire batch of GL postings hits the rate limit, it is split into smaller chunks and replayed incrementally until all entries are posted.