How to transition from legacy polling loops to reactive sub-second push notifications using SAP BTP WebSocket gateways, Server-Sent Events (SSE), and SAP Event Mesh.
In legacy enterprise web apps, frontend developers frequently implemented periodic polling: every 5 or 10 seconds, thousands of browser tabs fired HTTP GET requests to S/4HANA to check if a sales order status changed or if an approval arrived. In a 5,000-user enterprise, this generates over 30,000 requests per minute of completely wasted compute, overloading HANA database engines and saturating network gateways.
| Dimension | Periodic Client Polling (Legacy) | Event-Driven Push Architecture (Clean Core) |
|---|---|---|
| Latency | High (Lag equal to polling interval, 5-30 seconds) | Sub-second (< 200ms instantaneous push) |
| Backend Load | Severe (Constant queries even when no data has changed) | Near zero idle load (Connection stays open in memory) |
| Clean Core Fit | Anti-pattern (Unnecessary load on Tier-1 core) | 100% Compliant (Decoupled event-driven mesh) |
| Transport Protocol | Standard HTTP request/response loops | WebSocket (Full Duplex) or Server-Sent Events (SSE) |
A production push notification solution involves three decoupled layers:
SalesOrder.Created) via SAP Event Mesh."ws": true) and updates the local JSON model reactively.Because WebSockets upgrade normal HTTP connections, the SAP BTP App Router must be configured with "ws": true in xs-app.json:
{
"source": "^/ws/notifications",
"target": "/ws/notifications",
"destination": "push-gateway-srv",
"ws": true,
"authenticationType": "xsuaa"
}
Use our free web utility to generate BTP Push Gateways, SAPUI5 WebSocket controllers, and App Router configuration files:
→ Open SAP Real-Time WebSocket & Push Notification Architect (Tool #76)
Master real-time event streaming, Solace/Event Mesh architectures, and Clean Core UX design in our flagship publications.