How to add WhatsApp to SAP ECC 6.0
Short answer
SAP ECC has no native WhatsApp channel. The usual pattern is a small middleware service that calls ECC through BAPIs or OData and talks to the WhatsApp Business Platform (Cloud API or a BSP), with ECC output determination or workflow events triggering outbound messages and replies posted back through a BAPI. The ERP stays on-prem; only the message text crosses to Meta.
Most ECC 6.0 shops have buyers, planners and dispatchers who already live on WhatsApp with suppliers, transporters and customers. The ERP knows the truth (PO confirmations in EKES, delivery status in LIKP, goods receipts in MKPF), but the conversation happens in a phone app and gets typed back into ME22N or VL02N by hand.
Because ECC is a stable, heavily customised system that few teams want to touch, the integration should be additive: read through released interfaces, write only through BAPIs, and keep Z-code changes to a small trigger. That keeps the ECC side compatible with whatever migration path you pick before the end of mainstream maintenance.
What teams use it for
Supplier PO confirmation
Send a template message for a new or changed PO schedule line and let the supplier reply with a confirmed date that lands in the PO confirmation (EKES) for buyer review.
Delivery and dispatch alerts
When a delivery is post-goods-issued, send the customer the delivery number, carrier and tracking reference from the shipment record.
Approval by reply
Notify an approver about a PO or purchase requisition awaiting release and accept APPROVE or REJECT, then call the release BAPI under a service user with an audit trail.
Customer order status
Let a known customer text an order number and get back the status, expected delivery date and open items from sales order data.
Shop-floor escalations
Message a supervisor when a production order is late or a component shortage is flagged by MRP, with a link to the exact order.
SAP ECC 6.0 integration surface
- BAPIs over RFC: BAPI_PO_GETDETAIL, BAPI_SALESORDER_GETSTATUS, BAPI_PO_RELEASE and BAPI_REQUISITION_RELEASE are released, stable entry points; confirm exact names in transaction BAPI on your release.
- Output determination (NACE) with a custom output type per business object can fire a message when a PO, delivery or order is saved; a Z function module then hands the payload to middleware.
- IDocs via ALE (WE20, WE21, WE02) such as ORDERS, DESADV or ORDRSP can be emitted to a port that middleware listens on, which avoids custom code in the transaction.
- SAP NetWeaver Gateway OData services (SEGW, /IWFND/MAINT_SERVICE) are available if the Gateway add-on or embedded Gateway is installed; otherwise stay on RFC with SAP NCo, PyRFC or node-rfc.
- Customer and supplier contact numbers usually sit in ADR2 or custom fields; plan a mapping table because mobile numbers are rarely clean in ECC.
How it works
- 1
Register a WhatsApp Business Account
Use the Meta Cloud API directly or a Business Solution Provider. Verify the business, add a dedicated number, and submit message templates for each flow for approval.
- 2
Build the middleware service
A small service (Node, Python or .NET) holds the WhatsApp webhook endpoint, a queue, and an RFC or OData client to ECC. It is the only component that talks to both sides.
- 3
Define the ECC trigger
Prefer NACE output types or ALE IDoc ports over modifying standard programs. The trigger sends only a document key; middleware then reads the details itself.
- 4
Map identities and opt-in
Store a phone number to partner (LIFNR or KUNNR) mapping with a recorded opt-in. Reject inbound messages from unknown numbers.
- 5
Write back through BAPIs
Replies become structured actions: a confirmation row, a release call, or a note. Anything that changes money or quantities goes to a review queue first.
- 6
Monitor and retry
Log every message with its ECC document key, handle delivery receipts, and retry RFC failures without double-posting.
Example flows
Supplier confirms a delivery date
Trigger: A buyer saves a PO in ME21N and the output type fires.
- Middleware reads the PO with BAPI_PO_GETDETAIL.
- A template message lists items and requested dates to the supplier contact.
- The supplier replies with a date per line.
- Middleware parses the reply and proposes an EKES confirmation.
- The buyer approves the proposal in a review screen.
Result: Confirmed dates reach ECC without retyping and the buyer keeps control.
Dispatch alert to a customer
Trigger: Post goods issue on an outbound delivery.
- Output determination emits the delivery number.
- Middleware reads delivery and shipment data.
- A shipping template message goes to the registered customer number.
- The customer asks a question; it routes to the sales desk.
Result: Fewer status-chasing calls to customer service.
Keeping data on-prem
ECC itself never needs an internet connection. Place the middleware in the DMZ or inside the network with outbound HTTPS to Meta and an inbound webhook exposed through a reverse proxy. Messages are not end-to-end private from Meta, so keep payloads to document numbers, dates and statuses, and keep prices, drawings and technical data out. If you add natural-language understanding to parse free-text replies, run an open-weight model on your own GPU so supplier text and ERP context never go to a public API.
Security checklist
- Use a dedicated RFC service user with an authorization profile limited to the BAPIs and objects the flow needs (S_RFC, plus business objects).
- Never send commercial terms, prices or technical drawings over WhatsApp; send status and reference numbers.
- Verify the Meta webhook signature and allow-list the source IPs at the proxy.
- Record opt-in and opt-out per contact and honor opt-out automatically.
- Log every inbound and outbound message against the ECC document for audit.
Ways to get it done
Marketplace connector or BSP add-on
Effort: Days to a few weeks, plus per-conversation fees.
Simple notifications from ECC output with little custom logic.
Build in-house middleware
Effort: Typically 4 to 10 weeks for two or three flows.
A team with ABAP and integration skills and a clear small flow list.
Partner such as Netray
Effort: Scoped per flow; usually a pilot in weeks, then expansion.
You want two-way flows with AI parsing of replies, on-prem models and review queues.
Pitfalls
- !Free-form messages outside the 24-hour customer window require approved templates; plan the template set early.
- !Phone numbers in ECC master data are inconsistent; budget for a cleansing and mapping pass.
- !Writing replies straight into ME22N logic through batch input is fragile; use BAPIs.
- !Duplicate webhook deliveries can double-post a confirmation unless you de-duplicate by message ID.
Frequently asked questions
Does SAP ECC 6.0 support WhatsApp natively?
No. ECC predates the WhatsApp Business Platform, so you connect through middleware that uses BAPIs, IDocs or OData on the SAP side and the WhatsApp Cloud API or a BSP on the messaging side.
Do I need to modify standard SAP code?
Usually not. Output determination in NACE, ALE IDoc ports and released BAPIs cover most triggers and write-backs. A small Z function module is common, but keep it as a thin hand-off only.
Can suppliers approve things by replying?
Yes, but treat the reply as a proposal. Parse it, show it to a buyer, then post through a BAPI. Direct automatic posting of money-affecting changes is rarely worth the risk.
Is WhatsApp safe for ERP data?
Only for low-sensitivity content. Send statuses, dates and document numbers, not prices or drawings, and keep the full data inside ECC where your authorizations apply.
What happens to this after we migrate to S/4HANA?
The middleware and templates carry over. You re-point the SAP side from ECC BAPIs and IDocs to S/4HANA APIs, which is much easier if the logic lives in the middleware rather than in Z code.
Want WhatsApp working on your SAP ECC 6.0?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment