SAP Gateway
SAP Gateway Part 1: Gateway as the ABAP OData Runtime
Understand SAP Gateway as the ABAP OData runtime: what it does, embedded vs hub deployment, how RAP and SEGW services both run on it, and which Gateway components you touch as a developer.
A team's Fiori app failed after go-live with RFC errors, while it had worked in QAS. Production used a hub deployment; QAS was embedded. The service was registered on the hub but with the system alias of the wrong backend client. Once the team understood the hub architecture, they corrected the system alias in /IWFND/MAINT_SERVICE and cleaned both caches. They documented the deployment option of every landscape system, so that registration and troubleshooting steps matched the environment.
SAP Gateway Part 2: Frontend, Backend and Request Flow
Follow an OData request through Gateway step by step — ICF, frontend, system alias, backend, data provider — and understand where authentication, CSRF, authorization, caching and errors are handled.
Users of one plant received "403 Forbidden" in a Fiori app while others worked fine. The team first checked CSRF handling in the app, then the S_SERVICE authorization — both correct. The error body mentioned a missing business authorization. Mapping the request flow showed the 403 came from the backend step: the DPC_EXT GET_ENTITYSET performed an AUTHORITY-CHECK for plant, and the new plant was missing in the users' role. Adding it solved the issue. The team documented "which 403 is which" using the flow steps.
SAP Gateway Part 3: SEGW Model, Registration, Metadata and Transports
Walk through the SEGW service lifecycle: model entity types and sets, generate MPC and DPC classes, implement DPC_EXT, register the service in /IWFND/MAINT_SERVICE, check metadata, and transport everything consistently.
A SEGW service worked in DEV but returned 404 in QAS. The classes and project had been transported, but the service registration created in /IWFND/MAINT_SERVICE was saved as a local object in DEV, so QAS had no service entry. The team registered the service with a transport, imported it, cleaned the metadata caches and verified the ICF node. They added "registration in a transport?" to the SEGW release checklist.
SAP Gateway Part 4: Paging, Filtering, CSRF and Authorization
Implement Gateway services that behave well in production: server-side paging ($top/$skip), filtering and sorting via the request context, $inlinecount, CSRF handling, and authorization checks per operation.
A purchase request list app became slower every month. ST05 showed that each request read the entire ZPR_HEAD table (1.8 million rows) because GET_ENTITYSET used SELECT * and relied on generic paging. The team implemented filtering, sorting, paging and inline count from the request context, with a default sort by key. Response time dropped from 12 seconds to under 300 ms, and memory dumps on the application server during peak hours disappeared.
Interview questions covered
- What is SAP Gateway, and how do embedded and hub deployments differ?
- Trace an OData request through Gateway and say where each type of error originates.
- A SEGW list service slows down as data grows. What do you check in GET_ENTITYSET?
- When would you still use SEGW today, and how do you keep SEGW services maintainable?
- A SEGW service works in DEV but returns 404 in QAS. What are the likely causes?