Oracle Fusion Cloud ERP and Asana integration

What moves between them

The main flow runs from Oracle Fusion Cloud ERP into Asana. ml-connector polls Oracle Fusion for new and updated purchase orders and invoices on a fixed schedule, and pushes this data into Asana project tasks as custom field values, tagged with supplier name, PO number, invoice status, and line-item amount. In the reverse direction, ml-connector accepts Asana webhooks when a task is marked complete and syncs that completion date back into Oracle Fusion by creating a journal line entry in a designated ledger. Reference data such as supplier names and GL accounts are synchronized on demand so Asana tasks link to valid Oracle financial dimensions. Oracle Fusion data is read-only except for journal lines, so ml-connector never modifies invoices or purchase orders in Oracle.

How ml-connector handles it

ml-connector stores both credential sets encrypted in Postgres and refreshes the Oracle OAuth token on each API call if the prior token is within 5 minutes of expiry. For each customer, it accepts the Oracle pod URL and region per the customer's tenant, and polls the purchase order and invoice endpoints every 10 minutes using a ?q=LastUpdateDate>={timestamp} filter to fetch only changed records since the last poll. On the Asana side, ml-connector registers a workspace-level webhook for task-change events, decrypts the webhook signature on each push using a customer-specific shared secret, validates it constant-time, and immediately accepts 2xx to prevent webhook expiry. When a task is marked complete in Asana, the webhook payload contains the task ID and completion date; ml-connector looks up the corresponding Oracle purchase order via the custom field PO number, creates a journal entry in Oracle with the project cost allocated to the PO's cost center, and stores the job ID from Asana's webhook to prevent duplicate posts. HTTP 429 responses from either API trigger an exponential backoff retry loop. Every record moved is logged with source ID, destination ID, timestamp, and the full record body, so if a downstream Oracle journal post fails, the record can be replayed without re-fetching from Asana.

A real-world example

A mid-sized professional services firm uses Oracle Fusion Cloud ERP for accounting and procurement, and Asana for project planning and delivery. Before the integration, procurement sent purchase orders and invoice updates to projects via email, and the project team manually updated task status in Asana; at month-end, the finance team had to reconcile project task completions back to Oracle invoices by hand, often finding mismatches due to stale data. With Oracle Fusion and Asana connected, each purchase order and invoice update appears in Asana task custom fields automatically, showing the team current costs and commitments, and task completions flow back into Oracle as cost journals allocated to the project. Month-end close starts with project costs and invoices already reconciled, and the manual reconciliation step is eliminated.

What you can do

• •Poll Oracle Fusion Cloud ERP for new and updated purchase orders and invoices, and push supplier name, PO number, and line-item amount into Asana project task custom fields.
• •Accept Asana task webhooks and sync task completion dates back into Oracle Fusion as journal line entries allocated to the project cost center.
• •Refresh Oracle OAuth tokens on each call and validate Asana webhook signatures with constant-time comparison to prevent replay attacks.
• •Handle HTTP 429 rate limits from both APIs with exponential backoff retries, and log every record moved with source ID, destination ID, and full data for replay.
• •Encrypt all credentials (Oracle OAuth client secret, Asana personal access token, webhook secret) in Postgres and present them to each API on demand.

Questions

Which direction does data move between Oracle Fusion Cloud ERP and Asana?

Purchase orders and invoices from Oracle Fusion flow into Asana as custom field values on project tasks, so the team sees current costs and commitments. Task completion dates flow back into Oracle Fusion as journal line entries, so finance records reflect actual project status. Oracle Fusion invoice and PO data are read-only; ml-connector creates only new journal lines.

How does ml-connector handle OAuth token expiry and Asana webhook delivery?

ml-connector checks the Oracle OAuth token on each call and refreshes it if within 5 minutes of expiry, so token expiry never causes a downstream call to fail. For Asana webhooks, ml-connector validates the webhook signature using constant-time comparison, returns 2xx immediately to prevent webhook auto-deletion, and then processes the payload asynchronously so Asana sees the receipt before the journal post completes.

What happens if an Asana webhook fails to deliver or an Oracle API call times out?

If Asana webhook delivery fails or ml-connector is unreachable for 24 hours, Asana auto-deletes the webhook and the connection stops pushing events; the customer must re-register the webhook. If an Oracle Fusion API call times out, ml-connector backs off with exponential jitter and retries up to 5 times before surfacing an alert, so transient failures do not block the job.