Oracle E-Business Suite and Zendesk integration

What moves between them

Customer master records and purchase orders flow from Oracle EBS into Zendesk on a daily or weekly schedule. ml-connector reads HZ_CUST_ACCOUNTS and HZ_PARTIES from EBS, creates or updates matching Zendesk organizations with the customer's name, city, and state, and upserts Zendesk users for each customer contact with email and phone. It also polls PO_HEADERS_ALL and PO_LINES_ALL and stores order summary data in Zendesk organization custom fields so support agents can see open POs, recent invoices, and total spend without leaving the ticket. AP_INVOICES_ALL is read-only; ml-connector does not create or update invoices in EBS.

How ml-connector handles it

ml-connector stores Oracle EBS hostname, port, username, password, and required application context headers (responsibility, responsibility application, security group, language, organization ID) encrypted. On each poll cycle it obtains a session token from the EBS login endpoint using HTTP Basic Auth, then reads CUST_ACCOUNTS filtered by LAST_UPDATE_DATE and applies limit/offset pagination to handle large result sets. If the token expires mid-request (HTTP 401), ml-connector re-authenticates and retries. For each customer record, it transforms EBS city, state, and postal code into Zendesk organization fields. Purchase orders and invoice summaries are mapped to Zendesk custom fields on the organization, keyed by EBS customer number. Zendesk writes use OAuth 2.0 with a refresh token for unattended operation. Every record is validated against EBS GL_CODE_COMBINATIONS before insert to ensure data integrity, and a full audit trail tracks every sync, retry, and error.

A real-world example

A mid-market B2B distributor runs Oracle EBS for procurement and order management. When customers call with questions about their orders, the support team logs into Zendesk to create a ticket. Before the integration, agents had no visibility into order status and had to manually look up customers in EBS or ask the order desk for context. With Oracle EBS and Zendesk connected, each customer's Zendesk organization record includes their open POs, recent invoices, and total annual spend pulled from EBS. When a customer calls with a delivery question, the support agent can see the order details, status, and ship date right in the ticket, and can resolve the case in minutes instead of transferring to order management or calling back after a lookup.

What you can do

• •Automatically sync customer master records from Oracle EBS (CUST_ACCOUNTS, PARTIES) into Zendesk organizations so support has current customer context.
• •Display purchase orders and invoice summaries in Zendesk organization custom fields, refreshed daily so agents see current order status.
• •Map Oracle EBS customer attributes (city, state, payment terms) to Zendesk organization fields with full validation.
• •Handle Oracle EBS HTTP Basic Auth and session token refresh, with automatic re-authentication on token expiry.
• •Poll Oracle EBS open interface views on a daily or weekly schedule with full audit trail, error replay, and retry on transient failures.

Questions

Does ml-connector support writing customer or order data back into Oracle EBS from Zendesk?

No. Oracle EBS customer and invoice data flows one way, from EBS into Zendesk. Support agents can view order and invoice details in their Zendesk tickets, but new customers and orders are created in EBS, not in Zendesk. ap_invoices_all and ap_payments are read-only in the EBS REST API; creation requires concurrent programs, which ml-connector does not invoke.

How does ml-connector handle Oracle EBS session token expiry and the required application context headers?

ml-connector stores the hostname, port, username, password, and required context headers (responsibility, responsibility application, security group, language, organization ID) encrypted. On each poll it obtains a fresh session token from the EBS login endpoint. If a token expires mid-request and EBS returns HTTP 401, ml-connector re-authenticates and retries the request. All subsequent calls include the context headers required by your EBS instance configuration.

What happens if a customer exists in Zendesk but is deleted or archived in Oracle EBS?

ml-connector polls EBS on a fixed schedule and creates or updates Zendesk organizations for each active customer. If a customer is marked inactive in EBS, ml-connector will not create a new record for them, but it does not delete existing Zendesk organizations. This prevents accidental loss of historical ticket data if a customer name changes or becomes inactive temporarily.