ml-connector
Oracle JD EdwardsBambooHR

Oracle JD Edwards and BambooHR integration

Oracle JD Edwards EnterpriseOne runs financials, procurement, and HR for the business. BambooHR is the system of record for people data such as headcount, org structure, and compensation. Connecting the two keeps employee records and org assignments in agreement across both systems without re-keying. New hires and terminations entered in BambooHR flow into the JD Edwards Address Book, and each employee's department lines up with the matching JD Edwards business unit so labor lands on valid accounting dimensions. ml-connector handles the very different APIs on each side and moves the data on a schedule you control.

How Oracle JD Edwards works

Oracle JD Edwards EnterpriseOne is on-premises, so each customer runs their own Application Interface Services (AIS) Server and there is no shared base URL. The connector accepts the full AIS host and port per customer. Authentication is a session token: the connector posts a JDE username and password to the tokenrequest endpoint and sends the returned token in the jde-AIS-Auth header on every call. Reads use the data service against F-prefix tables (F0101 Address Book, F0911 Account Ledger, F0901 Account Master). Writes require named orchestrations or the form service, since direct table writes are not supported. JD Edwards has no native outbound webhooks, so changes are found by polling tables filtered on the date-updated field.

How BambooHR works

BambooHR is a cloud HRIS exposing data over REST on a per-company subdomain such as acme.bamboohr.com. New apps authenticate with OAuth 2.0, and the token URLs are themselves subdomain-scoped, so each customer has its own authorize and token endpoint. The employee is the primary entity, with versioned tables for job info, compensation, and employment status keyed to each employee ID. Fields are explicit: the single-employee endpoint returns only the fields named in the fields query parameter. BambooHR also pushes employee.created, employee.updated, and employee.deleted webhooks signed with SHA-256 HMAC; the payload is lightweight, so the integration fetches the full record afterward. BambooHR has no vendors, invoices, purchase orders, or GL accounts.

What moves between them

The main flow runs from BambooHR into Oracle JD Edwards. New hires, profile changes, and terminations in BambooHR create or update employee and Address Book records in JD Edwards, with each BambooHR department and division mapped to the matching JD Edwards business unit and cost center. Org structure and cost center references are aligned so headcount sits on valid accounting dimensions for downstream labor and GL reporting. BambooHR holds no finance objects, so no vendors, invoices, or GL postings move in either direction. Because JD Edwards cannot push, employee writes into JD Edwards go through a named orchestration while BambooHR is read on webhook plus a scheduled reconciliation poll.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BambooHR side it runs the OAuth 2.0 code flow with offline access so it can refresh the one-hour access token unattended, and it keeps a separate token URL per customer subdomain rather than one global endpoint. On the JD Edwards side it logs in to the customer AIS Server for a session token and re-authenticates automatically on HTTP 444 invalid-token, which fires whenever the AIS Server restarts. Employee webhooks from BambooHR are verified with SHA-256 HMAC over the body plus timestamp using constant-time comparison, then the full employee record is fetched, since the webhook payload only names the changed fields. Department and division are mapped to JD Edwards business units first, so every employee write lands on a valid dimension. Writes into JD Edwards use a named orchestration, because direct table writes are not allowed; the customer must import the orchestration in Orchestrator Studio and the connector accepts its name as config. A scheduled poll of JD Edwards tables filtered on the date-updated field reconciles anything a webhook missed. The connector backs off and retries on HTTP 500 from JD Edwards and honors the Retry-After header on a BambooHR 503, and the customer must add the connector egress IPs to the AIS allowedHosts list or every call returns HTTP 405.

A real-world example

A mid-sized industrial distributor with about 600 employees across several branches runs Oracle JD Edwards EnterpriseOne for finance and operations and uses BambooHR as its HRIS. Before the integration, HR onboarded each new hire in BambooHR and then an analyst keyed the same person into the JD Edwards Address Book by hand, often days later and sometimes against the wrong branch cost center, which threw off labor reporting at month-end. Terminations were worse, because a person could stay active in JD Edwards long after leaving. With Oracle JD Edwards and BambooHR connected, a hire in BambooHR creates the JD Edwards employee record within minutes, mapped to the right branch business unit, and a termination flips the status automatically. The duplicate data entry is gone and headcount in finance matches HR.

What you can do

  • Create and update Oracle JD Edwards employee and Address Book records from BambooHR hires and profile changes.
  • Flip JD Edwards employee status automatically when BambooHR records a termination.
  • Map each BambooHR department and division to the matching JD Edwards business unit and cost center.
  • Bridge BambooHR OAuth 2.0 tokens and the JD Edwards AIS session token, re-authenticating on token expiry or AIS restart.
  • Act on BambooHR employee webhooks for fast updates and reconcile by polling JD Edwards tables, since JD Edwards sends no push events.

Questions

Which direction does data move between Oracle JD Edwards and BambooHR?
The main flow is BambooHR into Oracle JD Edwards. Employee records, org assignments, and termination status move from BambooHR into the JD Edwards Address Book, with department and division aligned to JD Edwards business units. BambooHR has no vendors, invoices, or GL accounts, so no finance records move in either direction.
How does the integration handle JD Edwards having no webhooks?
Oracle JD Edwards EnterpriseOne does not push events to an external URL. ml-connector instead reacts to BambooHR employee webhooks for timely updates, then runs a scheduled poll of JD Edwards data service tables filtered on the date-updated field to reconcile any change a webhook missed. Writes into JD Edwards go through a named orchestration, since direct table writes are not supported.
What credentials are needed on each side?
For Oracle JD Edwards you provide the AIS Server URL, a dedicated JDE service username and password, and the environment and role; the connector exchanges these for a session token. For BambooHR you provide the company subdomain and an OAuth 2.0 client ID and secret. The connector also needs its egress IPs added to the JD Edwards allowedHosts list, or the AIS Server returns HTTP 405.

Related integrations

Connect Oracle JD Edwards and BambooHR

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started