Oracle JD Edwards and Microsoft Dynamics 365 Sales integration

What moves between them

Customer and vendor masters flow from JD Edwards F0101 and F0401 into Dynamics 365 Sales accounts and contacts, synced on a daily schedule tied to the UPMJ (date updated) field in JD Edwards. Sales quotes and orders created in Dynamics 365 Sales flow back into JD Edwards as F4301 purchase orders or sales orders on a daily schedule, using Dynamics webhooks for near-real-time notification and polling as fallback. Changes to contact addresses in Dynamics sync back to F0101 for customers. The sync is one-way for most master data and two-way for quote and order transactions.

How ml-connector handles it

ml-connector stores the JD Edwards AIS Server URL and service account credentials encrypted per customer, refreshes the session token before expiry, and polls F-tables on a daily schedule since JD Edwards has no webhooks. It queries with UPMJ date filters and uses pagination via maxPageSize to handle large datasets. On the Dynamics side, it uses OAuth 2.0 to obtain bearer tokens from Entra ID and creates or updates accounts and contacts using OData Create and Update operations. For orders, it registers a webhook listener for ConvertQuoteToSalesOrder and GenerateInvoiceFromOrder events; if webhooks fail, polling provides fallback sync. Every record is validated against the target schema before insert and includes the source record ID in a lookup field for traceability. ml-connector retries failed writes with exponential backoff, logs every operation to an audit trail, and flags records that fail validation so you can review them before retry.

A real-world example

A mid-market distributor runs JD Edwards for order-to-cash and uses Dynamics 365 Sales for pipeline management across a 15-person sales team. Before the integration, sales reps saw stale customer records in Dynamics, missed recent price changes, and quotes created in Dynamics had to be manually re-keyed into JD Edwards orders, creating delays and entry errors. With the integration, F0101 customer masters and pricing sync into Dynamics nightly, so reps always see current terms and open balances. When a rep closes a deal and converts a quote to an order in Dynamics, ml-connector automatically creates the corresponding JD Edwards sales order, pre-populated with the customer, items, and amounts. The quote-to-order cycle that used to take two days now completes in minutes.

What you can do

• •Sync JD Edwards customer and vendor masters (F0101, F0401) into Dynamics 365 Sales accounts and contacts on a daily schedule.
• •Pull sales quotes and orders from Dynamics 365 Sales back into JD Edwards as sales orders, triggered by Dynamics webhooks with polling fallback.
• •Authenticate JD Edwards via session token against your on-premises AIS Server and Dynamics 365 Sales via OAuth 2.0 Entra ID client credentials.
• •Validate every record against the target schema before insert and maintain a full audit trail of all synced records.
• •Handle Dynamics webhook timeouts and token expiries with retries and scheduled reconciliation polling.

Questions

Which direction does data move between JD Edwards and Dynamics 365 Sales?

Customer and vendor masters flow from JD Edwards into Dynamics 365 Sales daily. Sales quotes and orders created in Dynamics flow back into JD Edwards as sales orders, either in near real-time via Dynamics webhooks or on a scheduled daily poll. Contact address updates in Dynamics sync back to JD Edwards F0101 records.

How does ml-connector handle the fact that JD Edwards is on-premises with no webhooks?

ml-connector polls JD Edwards on a daily schedule using UPMJ (date updated) filters on F0101, F0401, and other key tables, and tracks the last-polled timestamp to avoid re-syncing unchanged records. It requires the customer to provide the full AIS Server URL and accepts session tokens with 30 to 60 minute lifetimes; it refreshes the token before expiry to keep the connection alive.

What happens if a sales order created in Dynamics fails to write to JD Edwards?

ml-connector logs the failure to the audit trail, flags the record for review, and retries with exponential backoff on the next scheduled sync cycle. You can review failed records, correct the source data in either system, and trigger a manual retry without losing history or creating duplicates.