Oracle JD Edwards and Slack integration

What moves between them

Data flows from Oracle JD Edwards into Slack. ml-connector polls JD Edwards on a configurable schedule (typically every 30 minutes or hourly) for four key record types: open accounts payable invoices and matching documents (F0411, F0413), GL postings and journal entries (F0911, F0911Z1), purchase order headers and detail lines (F4301, F4311), and address book updates for vendors and customers (F0101, F03012). Each polling cycle extracts records modified since the last run using the UPMJ or GL date filter. For each new or changed record, ml-connector formats a notification and posts it to a designated Slack channel via chat.postMessage, including the record ID, key amounts, affected GL account or cost center, and user or vendor name. Slack is read-only from JD Edwards perspective - no data flows back into the ERP from Slack.

How ml-connector handles it

ml-connector stores the JD Edwards AIS Server URL and session credentials encrypted at rest. On each polling cycle, it authenticates by POST to the /jderest/v2/tokenrequest endpoint with the stored username and password, receives an opaque session token, and uses that token in the jde-AIS-Auth header to query the relevant F-tables. If a token expires (HTTP 444 response), it re-authenticates transparently. Pagination is handled via the maxPageSize and moreRecords parameters, so large result sets are fetched in 100-record chunks. For Slack, ml-connector uses the OAuth2 bot token obtained during the Slack app installation, passed as a Bearer token to each chat.postMessage call. Slack enforces a 1-per-second rate limit per channel, so ml-connector queues outbound notifications and spaces them to stay under the limit. Each JD Edwards record carries a unique identifier (SYSID, batch number, or document number depending on the table), which is included in the Slack message so the receiver can trace the alert back to the source. Since JD Edwards tokens have a 30-to-60-minute lifetime, ml-connector is configured to refresh the token before it expires (tracking the request time and reusing the token within its window), rather than waiting for a 444 failure. The integration also handles the on-premises IP allowlist requirement - customer must add the ml-connector egress IP(s) to the JD Edwards AIS Server allowedHosts configuration. Every polling cycle is logged with a full audit trail so failed or missed syncs can be detected and replayed.

A real-world example

A mid-market manufacturing company uses Oracle JD Edwards on-premises for GL, AP, purchasing, and inventory. The procurement manager, accounts payable clerk, and CFO work in Slack during the day. When a high-value purchase order is created for a critical component, it currently stays in JD Edwards until someone checks the system manually. When an AP invoice arrives from a supplier, the AP clerk receives an email that may be delayed or missed in their inbox. When month-end closes and GL postings are made, the accounting manager has no real-time visibility into the entries being recorded. With the integration, a Slack channel receives a notification each time a purchase order over a threshold is created (with PO number, vendor, amount, cost center), each time an AP invoice is matched and ready for payment (with invoice number, vendor, amount, GL account), and each time a GL posting is made in a critical account (with journal entry ID, account, amount, cost center, date). The team stays informed without logging into JD Edwards, and critical events are surfaced in the chat platform they already use.

What you can do

• •Post real-time Slack notifications whenever open AP invoices and matching documents are created or updated in JD Edwards F0411 and F0413 tables.
• •Send GL posting alerts to Slack when journal entries are posted in JD Edwards F0911 and F0911Z1, mapped to account and cost center.
• •Notify Slack channels when purchase orders are created or status-changed in JD Edwards F4301 and F4311 tables.
• •Authenticate JD Edwards via session token and refresh transparently when the 30-to-60-minute token window expires, handling IP allowlist requirements.
• •Poll on a configurable schedule with per-record audit logging, so any sync miss or error can be traced and replayed.

Questions

What data moves from JD Edwards to Slack, and in which direction?

Data flows from JD Edwards to Slack only. The integration polls JD Edwards for open AP invoices and matching documents, GL postings and journal entries, purchase order headers and line detail, and vendor/customer address book changes, then posts real-time notifications to Slack channels. Slack is read-only; no data flows back into JD Edwards.

How does ml-connector handle JD Edwards session tokens and the on-premises AIS Server URL?

ml-connector stores the AIS Server URL and username/password encrypted. On each polling cycle, it authenticates via POST to /jderest/v2/tokenrequest, receives a session token valid for 30 to 60 minutes, and passes it in the jde-AIS-Auth header on all subsequent requests. The integration tracks token age and re-authenticates before expiry rather than waiting for a 444 failure. The customer must add ml-connector's egress IP to the JD Edwards allowedHosts firewall allowlist.

How are Slack rate limits handled, and what happens if a notification fails to post?

Slack enforces a 1-per-second rate limit per channel. ml-connector queues outbound notifications and spaces them to stay under the limit. Every poll cycle is logged in the audit trail with the source JD Edwards record ID, so if a Slack post fails (network issue, rate limit spike, invalid channel), the notification can be replayed once the underlying cause is resolved.