Oracle PeopleSoft and Anaplan integration

What moves between them

The main flow runs from Oracle PeopleSoft into Anaplan. On a schedule, ml-connector reads GL actuals, ChartField lists such as accounts, departments, and business units, and headcount from PeopleSoft, then loads them into the matching Anaplan lists and modules through pre-built import actions so planning models always sit on current data. In the other direction, approved budget and forecast figures are exported from Anaplan and posted into the PeopleSoft general ledger through the JOURNAL_ENTRY_CI Component Interface. Reference lists are aligned in both directions so every planned value maps to a real account and cost center. The cadence follows your close and planning calendar, often nightly for actuals and on demand around budget approval.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For PeopleSoft it accepts the full base URL and Integration Broker node name per customer, sends Basic Auth on each call, and uses REST inquiry endpoints for reads and the JOURNAL_ENTRY_CI SOAP Component Interface for journal writes, since there is no delivered REST endpoint for GL entry. Because neither system pushes events, both sides are polled: PeopleSoft on a conservative interval to avoid loading the Tuxedo queue, and Anaplan through its mandatory async pattern where each import or export is started, polled by task id until complete, then chunked. Accounts, departments, and business units are mapped to Anaplan lists first so every imported or written value lands on a valid member. Anaplan locks the model during an action, so ml-connector serializes jobs against the same model. It backs off on Anaplan HTTP 429 and PeopleSoft 500 or 503 responses, refreshes the 35-minute Anaplan token before expiry, and uses the journal number as a natural key so a retried posting does not duplicate. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A regional healthcare provider with about 4,000 employees runs Oracle PeopleSoft for finance and HCM and uses Anaplan for its annual budget and rolling forecast. Before the integration, the FP&A team exported trial balances and position reports from PeopleSoft each month and hand-loaded them into Anaplan, which delayed the forecast and introduced mapping errors between ledger accounts and planning lines. Once approved, budget figures were re-keyed back into PeopleSoft journals by the accounting team. With Oracle PeopleSoft and Anaplan connected, monthly actuals and headcount flow into the planning models automatically, and approved budget values post back to the general ledger through a Component Interface. The forecast refreshes on time and the manual load-and-rekey work is gone.

What you can do

• •Load PeopleSoft GL actuals into Anaplan planning modules on your close calendar.
• •Sync ChartField lists such as accounts, departments, and business units into Anaplan list dimensions.
• •Feed PeopleSoft headcount into Anaplan workforce models for staffing plans.
• •Post approved Anaplan budget and forecast values back into the PeopleSoft general ledger through JOURNAL_ENTRY_CI.
• •Bridge PeopleSoft Basic Auth on a self-hosted URL with Anaplan token auth, with retries and a full audit trail on every record.

Questions

Which direction does data move between Oracle PeopleSoft and Anaplan?

The main flow is PeopleSoft into Anaplan, carrying GL actuals, ChartField lists, and headcount so planning models stay current. Approved budget and forecast values move the other way, from Anaplan into the PeopleSoft general ledger through the JOURNAL_ENTRY_CI Component Interface. Reference lists like accounts and cost centers are aligned in both directions.

How does the integration write data into PeopleSoft when there is no REST endpoint for journals?

PeopleSoft delivers REST endpoints mainly as read-only inquiries, so GL postings use the JOURNAL_ENTRY_CI Component Interface exposed as a SOAP service. ml-connector calls that service to create journals and uses the journal number as a natural key, so a retried posting will not create a duplicate. Reads still use the faster REST inquiry endpoints where they exist.

How are imports and exports handled given Anaplan has no native finance objects and no webhooks?

Anaplan data is reached as lists and modules, and bulk transfers run named import and export actions that a model builder must create in advance. ml-connector discovers those action ids, starts each action, polls the returned task id until it completes, then uploads or downloads file chunks. Because Anaplan sends no push events and locks the model during an action, the connector polls on a schedule and serializes jobs against the same model.