Oracle PeopleSoft and Adobe Commerce integration

What moves between them

The main flow runs from Adobe Commerce into Oracle PeopleSoft. As orders complete and invoices and credit memos are created on the storefront, ml-connector reads them and posts AR vouchers and GL journal lines into PeopleSoft through Component Interface SOAP, mapped to the correct PeopleSoft ChartFields. New storefront customers and B2B company accounts flow the same direction into the PeopleSoft customer master. In the reverse direction, PeopleSoft item, price, and stock data is pushed to the Adobe Commerce product catalog so the storefront reflects current ERP inventory. Both reads run on a polling schedule, since neither side offers self-service webhooks the other can subscribe to without setup.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Adobe Commerce side it signs OAuth 1.0a requests for PaaS or refreshes the IMS bearer token before its 24 hour expiry for SaaS, and it includes the store view code in the URL path. On the PeopleSoft side it accepts the full customer hostname, port, and Integration Broker node name, since there is no shared base URL, and sends Basic Auth with the OPRID and password. Because PeopleSoft delivered REST is read-only, writes go through SOAP Component Interfaces, so ml-connector parses the PeopleSoft XML rowset format rather than JSON. It polls Adobe Commerce for completed orders, invoices, and credit memos on a schedule, since PeopleSoft cannot self-register for Adobe Commerce webhooks. SKUs are mapped to PeopleSoft items and storefront totals to PeopleSoft ChartFields before any write, so each posting lands on a valid account. Adobe Commerce uses increment_id for duplicate detection because it has no idempotency key, and PeopleSoft rejects a voucher that already exists by its invoice number, so re-runs do not double-post. The connector backs off on PeopleSoft 401 and 503 responses and on Adobe Commerce payment 429 limits, and every record carries a full audit trail and can be replayed if a downstream call fails. Common gotchas it handles: the PeopleSoft service operation must be activated by an admin, the customer firewall must whitelist the connector egress range, and the B2B module must be enabled in Adobe Commerce for company and purchase order objects.

A real-world example

A mid-sized industrial parts distributor runs Oracle PeopleSoft for finance and inventory and sells to trade buyers through an Adobe Commerce B2B storefront. Before the integration, staff exported completed web orders each morning and re-keyed the invoice totals and new buyer accounts into PeopleSoft, and the storefront often showed stock and prices that no longer matched the ERP. With Oracle PeopleSoft and Adobe Commerce connected, each completed order and invoice posts into PeopleSoft as an AR voucher allocated to the right ChartField, new company accounts create matching customer master rows, and PeopleSoft item, price, and stock updates flow out to the catalog. The morning re-keying step is gone and the storefront stays in step with the ledger.

What you can do

• •Post completed Adobe Commerce orders, invoices, and credit memos into Oracle PeopleSoft as AR vouchers and GL journal lines.
• •Create PeopleSoft customer master rows from new Adobe Commerce customers and B2B company accounts.
• •Push PeopleSoft item, price, and stock data to the Adobe Commerce product catalog.
• •Bridge Adobe IMS or OAuth 1.0a on the storefront with PeopleSoft Basic Auth on a customer-supplied URL and node name.
• •Poll on a schedule you control, with retries, duplicate detection, and a full audit trail on every record.

Questions

Which direction does data move between Oracle PeopleSoft and Adobe Commerce?

The main flow is Adobe Commerce into Oracle PeopleSoft. Completed orders, invoices, credit memos, and new customer or company accounts move from the storefront into PeopleSoft as AR vouchers, journal lines, and customer master rows. In the reverse direction, PeopleSoft item, price, and stock data flows out to the Adobe Commerce product catalog so the storefront reflects current ERP inventory.

Why does the integration write to PeopleSoft over SOAP instead of REST?

PeopleSoft's delivered Integration Broker REST endpoints are read-only inquiry services for invoice status, payments, requisitions, and similar lookups. Creating an AR voucher, customer record, or GL journal requires a Component Interface exposed as a SOAP web service, such as AP_VOUCHER, CUSTOMER_CI, or JOURNAL_ENTRY_CI. ml-connector therefore reads from REST where useful and writes through SOAP, parsing the PeopleSoft XML rowset format that those services return.

How does the connector handle the two different authentication models?

ml-connector stores both credential sets encrypted and adapts to each side. Adobe Commerce uses OAuth 1.0a signed credentials on PaaS or IMS OAuth 2.0 client credentials on the SaaS Cloud Service, where the token expires in about 24 hours and is refreshed before expiry. PeopleSoft uses HTTP Basic Auth with an OPRID and password against the customer-supplied hostname, port, and Integration Broker node name, since PeopleSoft is self-hosted and publishes no shared base URL.