SAP Gateway

SAP Gateway splits OData processing into a hub side and a backend side, which can run in the same system or in two systems:

1. An SAP Fiori app sends an OData request to a URL under the ICF path for OData services.
2. The hub component receives it, checks that the service is registered and active, and checks the user's start authorization for the service (authorization object S_SERVICE).
3. The hub uses the service's system alias to route the request to the backend that implements it — the same system in an embedded setup, or a backend reached through an RFC connection in a hub setup.
4. The backend component runs the service implementation: a RAP business object, CDS-based logic or the classes of a SEGW project.
5. The response travels back the same way, and any error is written to the hub or backend error log.

SAP Gateway is therefore the traffic layer between SAP Fiori apps and ABAP business logic, not the place where that logic lives.

SAP documents two deployment options for SAP Gateway as part of the SAP Fiori front-end server:

The hub option once gave central control over several backends and a separate upgrade cycle for the UI layer. For SAP S/4HANA, SAP now recommends the embedded deployment and has announced the deprecation of the standalone hub, which will become obsolete in a future release, with a documented migration path from standalone to embedded. Landscapes still serving older SAP ERP backends from one hub need a separate plan. For a new SAP S/4HANA system, the SAP Gateway deployment decision is effectively made: embedded.

The /IWFND/ prefix belongs to the hub component and the /IWBEP/ prefix to the backend component; in an embedded deployment both sets run in the same system. Knowing which side a transaction belongs to is the fastest way to orient yourself in SAP Gateway.

• SAP S/4HANA on-premise and Private Edition: customers or their operations partner administer SAP Gateway directly, with the transactions above.
• SAP ERP (ECC): SAP Gateway serves SAP Fiori apps for SAP ERP as well, often from a hub that also hosts the SAP Fiori Launchpad. Features depend on the SAP NetWeaver release; OData V4 exposure, for example, needs SAP NetWeaver 7.50 SP04 or higher.
• SAP S/4HANA Cloud Public Edition: the SAP Gateway transactions in this entry are documented for on-premise and Private Edition systems; in Public Edition, APIs are exposed to other systems through communication arrangements.
• SAP BTP: ABAP environment services are published through RAP service bindings and exposed to other systems through communication scenarios, and CAP serves OData itself, so the work happens in these tools rather than in the SAP Gateway transactions.

SAP Gateway is an administration topic mainly where the customer runs the ABAP stack.

When an SAP Fiori app at Alder Manufacturing shows "no data" or a generic error, work through the layers in order:

1. Find the failing request. In the browser developer tools, locate the OData call (often inside a $batch) and note the HTTP status and message.
2. 401 or 403: check the user's start authorization for the service with SU53, and confirm the ICF node is active in SICF.
3. 404 or "service not found": check the service registration and system alias in /IWFND/MAINT_SERVICE, or the service group in /IWFND/V4_ADMIN.
4. 500 errors: open /IWFND/ERROR_LOG, then follow the entry into /IWBEP/ERROR_LOG for the backend cause.
5. Behavior unchanged after a transport: clean up the metadata caches on both sides.
6. Reproduce the request in /IWFND/GW_CLIENT to rule out the app.

A frequent complaint in practitioner communities is time lost debugging SAPUI5 code when the cause sat in configuration. Checking SAP Gateway layer by layer separates registration and authorization gaps from code defects.