Service Bindings Part 5: Troubleshooting 404, 403, Metadata and Cache

📌 KEY POINTS
✅ 404 → not published or wrong URL; 403 → missing role or service authorization.
✅ Metadata errors → check /IWFND/ERROR_LOG and the binding status.
✅ Stale UI after changes → clear metadata caches.
⚠️ Always reproduce with the failing user before changing code.

▶ THE METHOD: STATUS CODE FIRST, THEN LAYER
Most time lost on OData issues comes from guessing — reactivating objects, clearing random caches. Instead, find the exact failing request and its HTTP status code, then go to the layer that code points to.
How to get the failing request:

• In the browser: developer tools (F12) → Network tab → filter "odata" or "$batch" → open the failed request and its response body. For $batch, the real status is inside the batch response part.
• In the backend: /IWFND/ERROR_LOG (Gateway hub) and /IWBEP/ERROR_LOG (backend) list recent errors with the request and the error text. Replay with /IWFND/GW_CLIENT.

404 NOT FOUND — "THE SERVICE OR INSTANCE DOES NOT EXIST HERE"
Two very different meanings:
A. Service not found (error mentions the service or no service found for the URL):

1. Is the binding published in THIS system? V4: /IWFND/V4_ADMIN → service groups; V2: /IWFND/MAINT_SERVICE. (Most common cause after a transport — see Part 3.)
2. Is the URL correct? Copy it from the binding editor; check version (0001) and that the binding name (e.g. _O4) is in the path.
3. Are the ICF nodes active in SICF (/sap/opu/odata4 for V4, /sap/opu/odata for V2)?
4. Is the system alias for the service correct (usually LOCAL for embedded deployment)?

B. Entity instance not found (the service works, one key does not):

• Wrong key format, missing IsActiveEntity for draft services, or the instance was deleted. In unmanaged RAP, check that your read method returns the instance (Unmanaged series, Part 3).

401 / 403 — "WHO YOU ARE / WHAT YOU MAY DO"

• 401: authentication failed — wrong user/password, expired certificate, or wrong communication user (cloud Web API).
• 403 before your code runs: the user lacks the service start authorization. Run SU53 for that user directly after the failed call, or use the authorization trace STAUTHTRACE. Fix the PFCG role (S_SERVICE for the service/service group). In the cloud: missing business role with the IAM app, or missing communication arrangement.
• 403 or "not authorized" from your business object: your get_global_authorizations / get_instance_authorizations returned unauthorized. The error text usually comes from RAP. Check the business role against the authorization object the BDEF checks.
• Empty list without error: often not an error at all but a CDS access control (DCL) filtering the rows for this user.
• 403 on POST/PATCH only: often a missing or invalid CSRF token in a client that is not SAP UI5. Fetch the token with a GET (header x-csrf-token: Fetch) first.

400 / 412 / 428 — "YOUR REQUEST IS NOT ACCEPTABLE"

• 400 Bad Request: invalid JSON, wrong property name or type, unknown field — compare the payload with $metadata.
• 412 Precondition Failed: ETag mismatch — the instance changed since it was read. Correct behavior; the client must reload. If it happens constantly after your own changes, in unmanaged RAP the read method probably does not return buffered ETag values.
• 428 Precondition Required: the client did not send If-Match although the entity has an ETag.

500 AND METADATA ERRORS — "THE SERVICE ITSELF IS BROKEN"

• $metadata fails: an inconsistency in projection, service definition, annotations or associations. Reactivate in order: CDS views → metadata extensions → BDEF → service definition → binding, and read the activation log. /IWBEP/ERROR_LOG shows the exact element.
• 500 on a specific operation: usually a short dump in your handler — check ST22 for the time of the call, then debug with an external breakpoint for the calling user.
• Business error messages (validation texts) with 400: that is your BO working correctly.

"I CHANGED THE CODE BUT NOTHING CHANGED" — CACHE PROBLEMS
Metadata is cached in several places. Clear them from the backend outwards:

1. Backend/Gateway metadata cache — OData V4: in /IWFND/V4_ADMIN use the cleanup cache function for the service group. OData V2: /IWBEP/CACHE_CLEANUP (backend) and /IWFND/CACHE_CLEANUP (hub).
2. Fiori launchpad and UI5 caches — reload with cache disabled in developer tools, or clear the browser cache; your organization may also run UI5 cache invalidation jobs after deployments.
3. Only if needed: republish (unpublish and publish) the binding in DEV.

Clearing caches only fixes caching — if the problem survives a cleared cache, stop clearing and go back to the status code.

━━━━━━━━━━━━━━━━━━━━
▶ THE DECISION TREE IN SHORT
404 service → publication, URL, SICF, alias.
404 entity → key, draft key, read method.
401/403 → authentication, service authorization (SU53), business authorization, CSRF.
400/412/428 → payload, ETag.
500 → ST22 dump or metadata inconsistency (/IWBEP/ERROR_LOG).
Change not visible → caches, backend first.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT YOU HAVE AFTER PART 5
A repeatable way to find the failing layer in minutes. Part 6 closes the series with preview, metadata reading and Fiori Elements annotations.

After a release, users reported that the Purchase Request app showed "Service not available" for some users but not others. The first reaction was to reactivate the binding and clear every cache in DEV, which changed nothing, because the problem was in PRD.
Following the status-code method: browser developer tools showed the $metadata call returned 403, not 404 or 500. SU53 for an affected user showed a failed S_SERVICE check for the service group. The PRD role had been built from an older role version that did not include the new service. Adding the service to the role and regenerating the profile fixed it in ten minutes.
The team then added "$metadata with a business-role user" to their post-import checklist, so the same class of problem is caught before users see it.

• Reactivating objects or clearing caches before identifying the failing request and status code.
• Reading only the outer $batch status (200) and missing the failed inner request.
• Treating every 403 as a role problem — it can be CSRF, business authorization in the BDEF, or a cloud communication arrangement.
• Treating an empty list as an error when a CDS access control is filtering correctly.
• Debugging ABAP handlers for a 404 caused by missing publication.
• Clearing only the browser cache when the Gateway metadata cache is stale (or the reverse).
• Ignoring 412 errors instead of making the client reload — they are concurrency protection working correctly.

• Always start from the exact failing request, its status code and response body.
• Keep a troubleshooting table like the one in the code example in your team wiki.
• Run SU53 immediately after an authorization failure, as the affected user.
• Clear caches in order: Gateway/backend metadata first, then launchpad and browser.
• After every fix, replay the request in /IWFND/GW_CLIENT and check the error logs are clean.
• Write down each incident's root cause; the same few causes (publication, roles, cache) repeat.

Scenario questions are standard: "A Fiori RAP app shows an error for some users — how do you analyze?", "What does 412 mean in OData?", "Where do you find OData errors in the backend?"
Strong answer: capture the failing request in developer tools, read the status, then branch: 404 → publication, URL, SICF; 401/403 → authentication, S_SERVICE via SU53, business authorization, CSRF; 400/412/428 → payload and ETag; 500 → ST22 or metadata; stale behavior → caches. Name /IWFND/ERROR_LOG, /IWBEP/ERROR_LOG, /IWFND/GW_CLIENT and /IWFND/V4_ADMIN. Explaining that 412 is correct optimistic-concurrency behavior shows depth.