Oracle E-Business Suite and Asana integration

What moves between them

The main flow runs from Oracle E-Business Suite into Asana. ml-connector polls EBS for new and changed purchase orders and AP invoices and creates or updates a task per record in the chosen Asana project, writing the PO number, supplier name, amount, currency, and operating unit into custom fields. The reverse flow reads completed Asana approval tasks and their custom field values through webhooks so the approval decision and any reference notes are visible to EBS. Reference data such as suppliers and GL account or cost center codes is pushed into Asana custom fields so each task references a valid EBS dimension. Cadence is a scheduled poll on the EBS side, near real time on the Asana side via webhooks.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the EBS side it accepts the full customer base URL, obtains a session token, sends the responsibility and operating unit org ID context on every call, and re-authenticates when a request returns 401 because EBS tokens expire on the server session timeout. On the Asana side it sends the bearer token and always passes opt_fields, since Asana returns only gid and name by default and omitting opt_fields makes records look empty. EBS purchase orders and invoices map to Asana tasks, with EBS fields landing in custom fields resolved by GID rather than name because names can be renamed. EBS has no webhooks, so reads are polled on a schedule against open interface views filtered on last update date and paged with limit and offset, kept to low concurrency since EBS is a shared on-premises system with no rate limiter and overload shows up as timeouts. Asana task changes arrive by webhook, whose HMAC-SHA256 signature is verified and whose handshake secret is stored; because Asana auto-deletes a webhook after 24 hours of failed delivery, ml-connector re-registers it when missing. EBS writes are asynchronous through open interface tables, so a 200 means a row was queued, not imported, and a SOURCE value plus the natural key is set to avoid duplicates since neither side offers an idempotency key. Failed calls retry with backoff and every record keeps a full audit trail.

A real-world example

A mid-sized manufacturer with about 600 employees runs Oracle E-Business Suite for procurement and AP and uses Asana to coordinate work across plant, engineering, and finance teams. Before the integration, buyers raised purchase orders in EBS but tracked approvals and follow-up in email and spreadsheets, so finance had no single place to see which POs and invoices were waiting on a sign-off, and month-end chased missing approvals by hand. With Oracle E-Business Suite and Asana connected, each new PO and AP invoice appears as an Asana task in the right project with the amount and supplier in custom fields, approvers act in Asana, and the completed status is read back. The approval trail is in one place and the manual chase is gone.

What you can do

• •Turn new Oracle E-Business Suite purchase orders and AP invoices into tracked Asana tasks with supplier, amount, and operating unit in custom fields.
• •Read completed Asana approval tasks back so the sign-off decision is visible to the finance team in Oracle E-Business Suite.
• •Push EBS supplier and GL or cost center reference data into Asana custom fields so each task references a valid dimension.
• •Bridge Oracle E-Business Suite Basic Auth or session token and the Asana bearer token, re-authenticating on 401.
• •Poll EBS on a schedule at low concurrency while receiving Asana task changes by signed webhook, with retries and a full audit trail.

Questions

Which direction does data move between Oracle E-Business Suite and Asana?

The main flow is Oracle E-Business Suite into Asana. Purchase orders and AP invoices are read from EBS and become Asana tasks with financial details in custom fields. Completed Asana approval tasks are read back so the decision is visible, and supplier and account reference data is pushed into Asana so each task points at a valid EBS dimension.

Asana has no invoice or purchase order objects, so how does this work?

Asana is a work management tool with no native finance objects, so EBS purchase orders and invoices map to Asana tasks and the financial values land in customer-defined custom fields such as PO number, supplier, and amount. Custom fields are resolved by GID rather than name, so a renamed field does not break the mapping. This keeps EBS as the system of record while Asana handles the approval and tracking work.

How does the integration get changes when Oracle E-Business Suite has no webhooks?

EBS does not offer SaaS-style webhooks, so ml-connector polls its open interface views on a schedule, filtered on last update date and paged with limit and offset, at low concurrency because EBS is a shared on-premises system with no rate limiter. Asana task changes arrive the other way as signed webhook events that are verified with HMAC-SHA256. Because Asana auto-deletes a webhook after 24 hours of failed delivery, the connector re-registers it when it goes missing.