SAP Gateway Part 2: Frontend, Backend and Request Flow

📌 KEY POINTS
✅ Flow: client → ICF node → Gateway frontend → system alias → backend → service implementation → response.
✅ Authentication happens at ICF; CSRF and service authorization in the Gateway frontend.
✅ In SEGW, each operation maps to a DPC_EXT method (GET_ENTITYSET, GET_ENTITY, CREATE_ENTITY…).
💡 Knowing the step tells you where to look when a request fails.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced Gateway. Now we trace one request: GET /sap/opu/odata/sap/ZPURCHREQ_SRV/PurchaseRequestSet?$top=20.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 1 — ICF

• The ICF node /sap/opu/odata (and the service node beneath) must be active (SICF).
• Authentication: user/password, SSO (SAML, Kerberos), X.509 certificate, depending on configuration.
• Fails here → 401, or 404/403 if the node is inactive.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 2 — GATEWAY FRONTEND (/IWFND)

• Identifies the service and version from the URL.
• Checks service authorization: the user needs start authorization for this service (S_SERVICE via a role with the service's entry).
• Handles CSRF for modifying requests.
• Reads metadata from cache or requests it from the backend.
• Unpacks $batch into individual operations.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 3 — SYSTEM ALIAS

• Embedded: LOCAL — no network hop.
• Hub: RFC call to the backend defined by the alias (trusted RFC, user mapping).

━━━━━━━━━━━━━━━━━━━━
▶ STEP 4 — BACKEND (/IWBEP) AND IMPLEMENTATION

• SEGW service: the runtime calls the data provider class (DPC_EXT) method for the operation:

– GET collection → <ENTITYSET>_GET_ENTITYSET
– GET single → <ENTITYSET>_GET_ENTITY
– POST → _CREATE_ENTITY, PUT/MERGE → _UPDATE_ENTITY, DELETE → _DELETE_ENTITY
– deep insert → CREATE_DEEP_ENTITY, function import → EXECUTE_ACTION

• RAP service: the RAP runtime executes the BO/query (interaction phase, save sequence).
• Business authorization (AUTHORITY-CHECK, RAP authorization, DCL) happens here.

━━━━━━━━━━━━━━━━━━━━
▶ STEP 5 — RESPONSE

• Data is serialized (JSON/XML); errors from exceptions become OData error bodies; logs are written on failure.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE TO LOOK WHEN IT FAILS

• 401 → ICF authentication.
• 403 → CSRF or S_SERVICE (frontend) or business authorization (backend) — read the message.
• 404 → service/ICF node/registration.
• RFC errors → system alias (hub).
• Wrong data or 500 → implementation (DPC_EXT / RAP) — backend logs, ST22.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Check the ICF node of your service in SICF.
2. Find the service's system alias in /IWFND/MAINT_SERVICE.
3. Set an external breakpoint in DPC_EXT GET_ENTITYSET and call the service from GW client.
4. Walk up the call stack to see the Gateway layers.

✅ CHECKPOINT: you can place any Gateway error at the right step.

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.

• Not distinguishing frontend (S_SERVICE, CSRF) from backend (business) authorization.
• Inactive ICF nodes after system copies.
• Debugging DPC_EXT for problems that occur at ICF or frontend level.
• Missing business authorization checks in DPC_EXT.
• Ignoring the system alias in hub scenarios.

• Trace failures along the flow: ICF → frontend → alias → backend → implementation.
• Implement business authorization in the backend for every operation.
• Keep S_SERVICE role assignments aligned with apps.
• Use external breakpoints for the calling user.
• Document the flow and error mapping for support.

Questions: "Describe the flow of an OData request through SAP Gateway", "Where is authorization checked?", "Which DPC method handles a GET on an entity set?"
Strong answer: ICF (active node, authentication) → Gateway frontend (service identification, S_SERVICE, CSRF, metadata cache, $batch) → system alias (LOCAL or RFC) → backend runtime → DPC_EXT method (GET_ENTITYSET/GET_ENTITY/CREATE/UPDATE/DELETE/CREATE_DEEP_ENTITY/EXECUTE_ACTION) or RAP → response. Business authorization belongs in the implementation.