Gateway Architecture: Hub, Embedded, Frontend and Backend

Explanation

SAP Gateway exposes ABAP business data as OData services over HTTP. In an embedded deployment, Gateway and backend business logic are in the same system. In a hub deployment, the Gateway frontend server is separate from the backend ECC or S/4HANA system. A developer must know where the service is registered, where the runtime code exists and where to debug. In many support issues, the service exists in backend but is not properly activated or registered on the frontend Gateway system. OData troubleshooting requires checking the full path: browser or Fiori app, Gateway service, ICF node, system alias, backend DPC_EXT code and authorization.

Code example

* Gateway troubleshooting flow:* 1. Check service registration in /IWFND/MAINT_SERVICE.* 2. Check system alias points to correct backend.* 3. Check SICF node is active.* 4. Check backend service implementation in SEGW/DPC_EXT.* 5. Check runtime user authorization. * Important:* In hub deployment, frontend and backend can be different systems.* Debugging must happen where ABAP runtime code is executed.

Real project scenario

A Fiori app calls an OData service through a Gateway hub. The service metadata loads in backend but fails from frontend because the system alias in /IWFND/MAINT_SERVICE is wrong.

Common mistakes

- Debugging backend while request fails at frontend Gateway. - Ignoring system alias. - Not checking SICF activation. - Assuming embedded and hub setup behave the same.

Best practices

- Identify deployment model first. - Check service registration. - Check system alias. - Debug in the correct backend system. - Validate runtime user authorization.

Interview angle

A strong answer should explain frontend Gateway, backend system, service registration, system alias and where runtime code is executed.