Oracle JD Edwards and Asana integration

What moves between them

The primary flow runs from Oracle JD Edwards into Asana. ml-connector reads JD Edwards purchase orders and AP vouchers that need a review or approval and creates or updates an Asana task for each, writing the order number, supplier, amount, GL account, due date, and approval status into mapped Asana custom fields. When an Asana approval task is completed, the completion flows back so ml-connector calls the matching JDE orchestration to advance the purchase order status or release the voucher. Supplier and item reference data can sync the same direction to keep Asana custom field options aligned with JDE. Because JD Edwards has no outbound webhooks, the JDE side is read by scheduled polling, while Asana changes arrive by webhook.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It accepts the full AIS Server URL per customer, since JD Edwards publishes no shared base address, posts the JDE username and password to obtain a session token, and sends that token in the jde-AIS-Auth header on every call. The auth bridge matters because the two sides are unrelated: an on-premises AIS host with a JDE environment and role on one side, an Asana workspace GID and bearer token on the other. Field mapping is the core of this pair. Because Asana has no finance objects, each JDE purchase order or voucher becomes an Asana task and its figures land in custom fields resolved by GID, set up once per customer, and every Asana read passes opt_fields so the custom field values come back rather than sparse objects. JD Edwards has no native webhooks, so ml-connector polls the data service tables on the UPMJ date-updated field and tracks the last-polled timestamp between runs; writes back to JDE go through a configured orchestration name rather than a direct table post. On the Asana side it registers a webhook, echoes the X-Hook-Secret during the handshake, verifies the HMAC-SHA256 signature on every event, and re-registers because Asana deletes a webhook after 24 hours of failed delivery. Real edge cases are handled: a JDE session token returns HTTP 444 when it expires or the AIS Server restarts, so ml-connector re-authenticates automatically; the AIS allowlist returns HTTP 405 if the connector egress IP is not registered, which is surfaced as a setup alert; and because neither API offers an idempotency key, the connector checks for the existing JDE record and the stored Asana task GID before creating, so a retry does not duplicate. Asana 429 responses with Retry-After are backed off, JDE has no published limit so calls are throttled with backoff, and every record carries a full audit trail and can be replayed.

A real-world example

A 600-person industrial distributor runs Oracle JD Edwards EnterpriseOne for procurement and accounts payable on-premises, while buyers and operations managers coordinate day to day in Asana. Before the integration, accounting emailed lists of purchase orders and supplier vouchers waiting on a manager's sign-off, the managers approved them late or lost them in their inbox, and the buying team had no easy view into what was stuck. With Oracle JD Edwards and Asana connected, each order or voucher that needs review becomes an Asana task assigned to the right person, with the supplier, amount, GL account, and due date in custom fields. The manager completes the task, ml-connector advances the purchase order status in JD Edwards through an orchestration, and the buying team sees an approved queue instead of an email thread.

What you can do

• •Create and update Asana tasks from JD Edwards purchase orders and AP vouchers that need review or approval.
• •Carry the JDE order number, supplier, amount, GL account, due date, and approval status in mapped Asana custom fields by GID.
• •Write Asana task completion back to JD Edwards through a configured orchestration to advance the order status or release the voucher.
• •Bridge the JD Edwards AIS session token and the Asana bearer token, re-authenticating automatically on HTTP 444 token expiry.
• •Poll JDE tables on the UPMJ date-updated field, verify Asana HMAC-SHA256 webhooks, and back every change with retries and an audit trail.

Questions

Can Asana hold the purchase orders and vouchers from Oracle JD Edwards?

Not as native objects. Asana has no invoice, purchase order, or GL account entities, so ml-connector represents each JD Edwards purchase order or AP voucher as an Asana task. The financial detail, such as supplier, amount, GL account, and due date, is written into Asana custom fields that map to the JDE fields. Those custom fields are matched by GID rather than name, because Asana lets field names be renamed.

Which direction does data move between Oracle JD Edwards and Asana?

The primary flow is JD Edwards into Asana, creating tasks for purchase orders and vouchers that need a review. Asana task completion then flows back, so ml-connector calls a configured JDE orchestration to advance the purchase order status or release the voucher. Supplier and item reference data can also sync into Asana to keep custom field options aligned.

How are changes detected given JD Edwards has no webhooks?

Oracle JD Edwards has no native outbound webhooks, so ml-connector polls the AIS data service tables on the UPMJ date-updated field and tracks the last-polled timestamp between runs. Writes back go through a named orchestration rather than a direct table post. Asana changes, by contrast, arrive by webhook signed with HMAC-SHA256, which ml-connector verifies on every event and re-registers after Asana auto-deletes it on repeated delivery failures.