Oracle E-Business Suite and Rippling integration

What moves between them

The main flow is Rippling to Oracle E-Business Suite. Employee records (workers with departments and cost centers) flow from Rippling into EBS HR module tables (HZ_PARTIES, HZ_CUST_ACCOUNTS) on a daily or on-demand schedule. Payroll GL journals generated by Rippling after each payroll run are posted into EBS general ledger (GL_JE_HEADERS, GL_JE_LINES), mapped to valid GL code combinations and cost centers that already exist in EBS. Department and cost center reference data is aligned in both directions: Rippling departments and accounting dimensions are read and validated against EBS GL code combinations so payroll journals land on valid accounts, and new dimensions created in EBS are synced back to Rippling where applicable. GL journals are read-only in Rippling, so ml-connector never writes financial entries back to Rippling.

How ml-connector handles it

ml-connector stores Rippling API credentials encrypted and retrieves an OAuth2 bearer token, refreshing it when a call returns 401 Unauthorized. On the EBS side it stores the ISG hostname, port, and basic auth credentials encrypted, accepts the full URL pattern (https://<hostname>:<port>/webservices/rest/<service-alias>), and includes the required context headers (ctx_orgid, ctx_responsibility, ctx_respapplication, ctx_securitygroup, ctx_nlslanguage) on every call, obtained from the customer's Oracle instance configuration. Rippling employee data is polled on a daily schedule using the updated_at filter and company_activity event log; webhook delivery is available if the customer has enabled App Shop integrations, but ml-connector can operate without it. Employee records are written to EBS HR interface tables (HZ_CUST_ACCOUNTS, HZ_PARTIES) via REST POST, then EBS concurrent programs are scheduled via the ISG to import the staged data into base tables; ml-connector tracks the import status and can replay records if a concurrent program fails. Payroll GL journals from Rippling are posted to EBS GL_JE_INTERFACE, again staged for import via concurrent program. Department and cost center mappings are validated before any journal is posted: every journal line references a GL code combination and cost center that already exists in EBS, preventing downstream import failures. EBS session tokens expire based on EBS session timeout (typically 30 to 60 minutes), so ml-connector monitors token age and re-authenticates on 401 responses. Rippling's Idempotency-Key header is used on all write operations for safe retries. Every record carries a full audit trail and can be replayed if an import fails.

A real-world example

A mid-sized professional services firm with offices in two cities runs Oracle E-Business Suite on-premises for general ledger, AP, projects, and revenue management. They use Rippling for employee records, payroll, and benefits in the cloud. Before the integration, the finance team exported payroll registers from Rippling each pay period and re-entered labor totals and cost allocations into EBS by hand, a process prone to error and month-end reconciliation delays. With Oracle E-Business Suite and Rippling connected, each payroll GL journal flows automatically into EBS's general ledger and is allocated to the cost center and project for each employee. New hires and transfers in Rippling sync into EBS HR so headcount is always current, and month-end close begins with labor accounts already reconciled.

What you can do

• •Sync employee records from Rippling into Oracle E-Business Suite HR tables (HZ_PARTIES, HZ_CUST_ACCOUNTS) on a daily schedule or webhook trigger.
• •Post payroll GL journals from Rippling into EBS general ledger (GL_JE_LINES) allocated to the correct cost centers and GL code combinations.
• •Map Rippling departments and accounting dimensions to EBS GL code combinations and cost centers so payroll lines land on valid accounts.
• •Authenticate Rippling via OAuth2 with automatic token refresh and EBS via HTTP Basic Auth with context headers and session token caching.
• •Poll Rippling on a schedule with updated_at filters and event logs, with staged import into EBS interface tables, concurrent program scheduling, and a full audit trail on every record.

Questions

How does ml-connector handle Oracle E-Business Suite's context headers and multi-org setup?

Oracle E-Business Suite requires application context headers (ctx_orgid, ctx_responsibility, ctx_respapplication, ctx_securitygroup, ctx_nlslanguage) on every API call. ml-connector stores these headers per customer configuration in the ISG URL setup, retrieves them at runtime, and includes them on all requests. If your EBS instance has multiple operating units or responsibilities, ml-connector routes GL journals and employee records to the correct organization based on cost center mapping.

Does the integration handle the asynchronous import cycle in EBS, where data must be staged in interface tables first?

Yes. Rippling records and GL journals are posted to EBS interface tables (HZ_CUST_ACCOUNTS, GL_JE_INTERFACE, RA_INTERFACE_LINES_ALL) via REST, then ml-connector schedules the corresponding concurrent programs (Validate Customers, Post GL Journal, Import Receivables) to import staged data into base tables. ml-connector tracks job status and can replay records if a concurrent program fails, preventing data loss during the import cycle.

What happens if Rippling and EBS GL code combinations or cost centers get out of sync?

ml-connector validates that every GL journal line and cost center exists in EBS before posting. If a Rippling dimension does not match an EBS account, ml-connector logs the mismatch to the audit trail and does not post the journal, preventing rejection by EBS import programs. The customer can then either create the missing GL code combination in EBS or map the Rippling dimension to a different EBS account and replay the record.