Oracle JD Edwards and Jira integration

What moves between them

The main flow runs from Oracle JD Edwards into Jira. ml-connector polls JD Edwards work order tables on a schedule (typically daily or on demand) and creates Jira issues in a dedicated project, with title, description, assignee, and priority mapped from JD Edwards work order attributes. Status updates in Jira then flow back into JD Edwards via a custom audit table or webhook-triggered orchestration call, so production managers can see which work orders are in progress, blocked, or complete. The connector does not write financial data into Jira; it creates issues for workflow coordination only. Change orders and exception records can also be synced as Jira issues to ensure manufacturing teams are aware of deviations from the schedule.

How ml-connector handles it

ml-connector stores the JD Edwards AIS Server hostname and service account credentials encrypted, then authenticates with a session token (refreshing when the 30 to 60 minute lifetime expires or when a 444 HTTP response signals token invalidation). It polls the work order detail table and related tables at configurable intervals, tracking the last successful poll timestamp to avoid re-creating duplicate issues. For each new or updated work order, it constructs a Jira issue with fields mapped from JD Edwards: order number as issue key, order description and specs as the issue title and description, requested date as due date, and priority tier from the work order priority code. On the Jira side, ml-connector registers a webhook that captures jira:issue_updated events and uses the issue ID and updated status to call a JD Edwards orchestration endpoint that posts the status back into an audit table. The connector handles Jira webhook expiry by monitoring the 30 day refresh window and calling PUT refresh before expiration. Because JD Edwards session tokens time out, the connector caches the token and re-authenticates on each failed request that returns 444. Custom field IDs in Jira are per-instance, so the mapping is stored per customer. Work order due dates and priority are synced in both directions so if a field team marks a Jira issue as blocked due to a parts shortage, a callback can mark the JD Edwards work order as on hold.

A real-world example

A discrete manufacturing company with a head plant and two contract machining partners runs Oracle JD Edwards for ERP and uses Jira for shop floor coordination and engineering change tracking. Before the integration, the production scheduler entered work orders into JD Edwards each morning, then re-entered them into a Jira project board for the floor to track, and manually updated JD Edwards when field teams marked jobs complete or flagged issues in Jira comments. This dual-entry process caused orders to be scheduled twice, status mismatches during month-end close, and delays when the floor found a part was out of stock. After connecting JD Edwards to Jira, new work orders appear automatically as Jira issues in the shop floor project, the team updates status in Jira, and the status flows back into JD Edwards within minutes. The scheduler now sees real execution state in the ERP, change orders that the plant manager adds to Jira trigger alerts in the system, and month-end reconciliation is done because the ERP and Jira agree on which orders shipped and which are still in progress.

What you can do

• •Poll Oracle JD Edwards work orders daily or on demand and create Jira issues in a project dedicated to manufacturing execution.
• •Map work order attributes (order number, description, priority, due date, assigned team) from JD Edwards to Jira issue fields with per-customer field mapping.
• •Receive Jira status updates via webhooks and post them back into JD Edwards audit tables or call orchestration endpoints so the ERP sees real-time execution state.
• •Refresh Jira webhooks automatically every 25 days to prevent expiration and maintain a continuous notification stream.
• •Authenticate to JD Edwards via session token with automatic refresh on timeout, and to Jira via OAuth 2.0 or Basic auth with per-instance field ID validation.

Questions

What data moves between Oracle JD Edwards and Jira?

Work orders and change orders flow from JD Edwards into Jira as tracked issues. Jira status updates flow back into JD Edwards via webhooks and orchestration calls, so the ERP always reflects the live execution state. JD Edwards financials, GL accounts, and vendor data stay in the ERP; Jira provides workflow and task coordination only.

How does ml-connector handle JD Edwards session tokens and Jira webhook expiry?

JD Edwards session tokens expire after 30 to 60 minutes. ml-connector caches the token and re-authenticates automatically when a request returns HTTP 444 (invalid token) or the lifetime is reached. Jira webhooks expire after 30 days; ml-connector monitors the registration timestamp and calls the refresh endpoint every 25 days to keep the webhook active.

How are work order fields mapped to Jira issue fields?

Work order number maps to the Jira issue key or summary, description and specs map to the issue description, priority code maps to Jira priority, due date maps to due date, and assigned team maps to assignee. Custom field IDs vary by Jira instance, so the field mapping is stored per customer and can be adjusted without code changes.