How to add WhatsApp to Infor XA on IBM i
Short answer
XA runs on IBM i with Db2 for i, so the clean path is a small middle layer outside the partition that watches XA for events (journal, trigger or data queue), sends approved WhatsApp template messages through the Cloud API or a BSP, and writes replies back through a controlled program call. You never expose the IBM i directly to the internet.
Many Infor XA sites still run the green screen on an IBM i partition that has been stable for twenty years. The people who actually move the business, buyers, dispatchers, plant managers and field service techs, live on WhatsApp. They ask the same questions all day: is the PO confirmed, did the truck leave, can you release this order.
Closing that gap does not require changing XA. The IBM i already offers everything a messaging layer needs: Db2 for i tables that can be journaled or trigger-monitored, data queues that RPG programs can write to, and ways to call a program with parameters over JDBC or a stored procedure. WhatsApp is just the delivery channel at the far end.
The hard part is policy rather than code: Meta's template and opt-in rules, who is allowed to approve what, and making sure a reply from a phone becomes a validated XA transaction instead of a raw database write.
What teams use it for
Shipment and ASN alerts to customers
When a shipment confirmation posts in XA, send a template message with the order number, carrier and tracking link to the customer contact who opted in.
Supplier PO confirmation by reply
Message a supplier's buyer when a PO is released and parse a Yes, No or revised date reply into a pending acknowledgement that a buyer approves in XA.
Purchase approvals on the phone
Send a quick-reply message with Approve and Reject buttons to the approver when a requisition crosses their limit, and record the decision with their identity.
Late order escalation
A nightly job finds customer orders past their promise date and alerts the account owner with the part, quantity and last known status.
Field service dispatch notes
Notify a service technician of a new work order with the site address, and accept a photo reply stored against the order in the document store.
Infor XA (on IBM i) integration surface
- Db2 for i is the system of record. Files can be read over JDBC (the IBM Toolbox for Java / JTOpen driver) or ODBC from IBM i Access. Exact XA file and field names vary by release and by modification, so map them from your own data dictionary.
- Database triggers on key files, or journal receivers read with the journal APIs, give you change events without editing the RPG that XA ships. Check with your IBM i admin that journaling is already on for the files you care about.
- Data queues (DTAQ) let a small RPG or CL exit program push an event that an external listener drains. They are fast and simple, but plan for a dead letter table because a queue entry is gone once read.
- To write back safely, call an existing XA-supported program or a purpose-built RPG wrapper through a Db2 stored procedure, not an UPDATE on production files. Business rules and audit fields live in the programs.
- Depending on release and licensing, Infor ION and its APIs may be available for event publishing. Many older XA installs do not run it, so confirm before designing around it.
- The IBM i also has SMTP, FTP and IFS stream files, useful as fallbacks when you only need to export a CSV that the gateway picks up.
How it works
- 1
Pick the event sources
List the six or so XA events worth a message (PO release, shipment confirm, order past due, approval needed). For each, decide trigger, journal read or scheduled query.
- 2
Stand up a gateway outside the partition
A small service on a Windows or Linux host in your DMZ or internal network reads events from IBM i over a private connection and talks outbound to WhatsApp. IBM i makes only outbound or internal calls.
- 3
Register the WhatsApp Business account
Use Meta's Cloud API directly or a business solution provider. Verify the business, set a display name and create message templates for each use case. Templates need approval before use.
- 4
Build the contact and consent table
Map customer and supplier contacts to phone numbers and store explicit opt-in with a timestamp. Without this table the gateway must refuse to send.
- 5
Handle inbound webhooks
WhatsApp posts replies to a public HTTPS endpoint on the gateway. Verify the signature, match the sender to a known contact and a known open request, then queue the action.
- 6
Write back through a controlled call
Call a stored procedure that wraps an XA-side program. It validates the order status, applies the same checks as the green screen, and returns a result the gateway sends back as a confirmation.
- 7
Log and monitor
Keep every outbound and inbound message with the XA key it relates to. Alert on template rejections, delivery failures and webhook downtime.
Example flows
Supplier confirms a purchase order
Trigger: A buyer releases a PO in XA and the trigger writes an event to a data queue.
- The gateway drains the queue and looks up the supplier contact and opt-in record.
- It sends the po_release template with PO number, lines count and requested dates.
- The supplier taps Confirm or replies with a new date.
- The gateway stores the reply as a pending acknowledgement and notifies the buyer.
Result: The buyer reviews and accepts the acknowledgement in XA, instead of chasing a reply by email.
Manager approves a requisition on the shop floor
Trigger: A requisition over a spending threshold reaches the approval step.
- The gateway reads the requisition header and lines through a read-only view.
- It sends a summary with Approve and Reject buttons to the registered approver number.
- On tap, the gateway checks that the phone belongs to that approver and the requisition is still open.
- It calls the XA approval wrapper with the user ID and decision.
Result: The approval is posted with an audit trail that names the approver, not a shared service account.
Keeping data on-prem
The IBM i stays where it is. The only moving part that touches the public internet is the WhatsApp webhook receiver, which belongs in a DMZ with a reverse proxy, and it holds no XA credentials. The internal gateway pulls from IBM i and pushes to the webhook layer over a queue. WhatsApp itself is a cloud service, so message content leaves your network: keep payloads to references and short status text, and never send drawings, pricing or controlled technical data. If you want free-text questions answered from XA data, run the language model on your own GPU server so the question and the answer never go to a third-party model provider.
Security checklist
- Give the gateway a dedicated IBM i profile with object-level authority to specific views and one stored procedure, nothing else.
- Verify WhatsApp webhook signatures and bind each inbound reply to an open request ID so a stray message cannot trigger an action.
- Treat the phone number as an identity hint, not authentication. Require a second factor or a known device for high-value approvals.
- Keep PII minimal in templates and honour opt-out keywords immediately.
- Store access tokens in a secrets vault, rotate them, and log every send and every write-back call.
Ways to get it done
Marketplace messaging tool with CSV or email triggers
Effort: Days to a couple of weeks, mostly template approval and contact cleanup.
Low volume, a few alert types, and no need for replies to update XA.
Build the gateway in-house
Effort: Roughly four to ten weeks depending on how many two-way flows you need.
You have IBM i RPG skills plus a developer comfortable with webhooks.
Partner build with Netray and an XA specialist
Effort: A scoped pilot of a few weeks, then adding flows one at a time.
You want two-way flows, approvals and optional on-prem language understanding without staffing it yourself.
Pitfalls
- !Sending marketing-style content under a utility template gets the template rejected or the number flagged.
- !Business-initiated messages outside the 24-hour window must use an approved template, so free text from XA will silently fail.
- !Phone numbers stored in free-text XA contact fields come in dozens of formats. Normalise to E.164 before sending.
- !Writing straight into XA files from the gateway skips business rules and breaks audit and costing.
- !Using one shared WhatsApp number for approvals makes it impossible to say who approved what.
Frequently asked questions
Can WhatsApp talk to an IBM i directly?
Not sensibly. WhatsApp calls a public HTTPS webhook, and an IBM i should not be exposed that way. Put a gateway in front that holds the webhook and talks to the IBM i over an internal connection.
Does this need changes to the XA RPG source?
Often not. Triggers on files or reading journals avoids touching vendor source. For write-back, a separate wrapper program that calls supported routines is safer than patching standard programs, but confirm against your customisation policy.
Is WhatsApp allowed for supplier and customer communication?
Yes, if you have opt-in, use approved templates and honour opt-outs. Check your own compliance rules too: some defense and aerospace customers forbid technical data on consumer messaging platforms.
Can the person on WhatsApp ask free questions about orders?
Yes, with a language model behind the gateway that queries read-only views and answers in plain text. For regulated data, run that model on-prem so the content is not sent to an external AI provider.
What does it cost to run?
Meta charges per conversation or message category depending on current pricing, plus the BSP fee if you use one. Infrastructure is a small server. The largest cost is usually the build and template governance, not messaging.
Want WhatsApp working on your Infor XA (on IBM i)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment