OData V4 Part 5: Troubleshooting HTTP Errors, Metadata and Payloads

📌 KEY POINTS
✅ Read the status code AND the error body — the body usually tells the real cause.
✅ 403 = CSRF or authorization; 404 = URL/publish/key; 412/428 = ETag; 400 = request or business error.
✅ Backend logs: /IWFND/ERROR_LOG, /IWBEP/ERROR_LOG, ST22; traces: ABAP Cross Trace, ST05.
💡 A good incident report contains method, full URL, sanitized body, status, error body and time.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–4 built calls. This part is the playbook for failures.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE ERROR BODY
RAP returns errors in the OData V4 format:
{ "error": { "code": "…", "message": "Supplier 100045 is blocked", "target": "Supplier", "details": [ { "code": "…", "message": "…", "target": "…" } ] } }

• message — the main text (often your REPORTED message).
• target — the field (from %element).
• details — further messages.

━━━━━━━━━━━━━━━━━━━━
▶ 2. STATUS CODES AND FIRST CHECKS

• 400 Bad Request — malformed JSON, unknown property, wrong type, invalid $filter syntax — or a business rejection (validation, feature control). Read the message.
• 401 Unauthorized — authentication failed (user, password, certificate, SSO).
• 403 Forbidden — "CSRF token validation failed" → fetch token and send cookies; otherwise missing role/service authorization or RAP authorization (%fail-cause unauthorized).
• 404 Not Found — service not published, wrong URL/version, or entity key not found (wrong UUID, IsActiveEntity missing/wrong).
• 405 Method Not Allowed — operation not offered (e.g. DELETE not in projection BDEF).
• 409 Conflict — typically a lock: the instance is locked by another user or draft.
• 412 Precondition Failed — ETag mismatch: data changed since read (Part 6).
• 428 Precondition Required — If-Match header missing although an ETag is required.
• 500 Internal Server Error — dump or unexpected exception → ST22 and error log.

━━━━━━━━━━━━━━━━━━━━
▶ 3. BACKEND TOOLS

• /IWFND/ERROR_LOG (gateway hub) and /IWBEP/ERROR_LOG (backend) — failed requests with details and call stack.
• ST22 — short dumps for 500 errors.
• ABAP Cross Trace (ADT) — which RAP operations, determinations and validations ran and what they returned.
• External breakpoint for the calling user — step into handlers.
• ST05 / SAT — performance problems (timeouts).

━━━━━━━━━━━━━━━━━━━━
▶ 4. METADATA PROBLEMS

• Client says "property not found": compare the client's model with current $metadata (renamed field?).
• Changes not visible: clear metadata caches (client, launchpad, and gateway cache on hub systems).

━━━━━━━━━━━━━━━━━━━━
▶ 5. THE INCIDENT REPORT TEMPLATE
Method + full URL + headers (without secrets) + sanitized body + status + error body + timestamp + user. With this, most issues are solved without a call.

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

1. Reproduce each status in the code example deliberately against your test service.
2. Find each failed call in /IWFND/ERROR_LOG.
3. Record one Cross Trace for a validation error and match it to the error body.

✅ CHECKPOINT: you can classify any OData failure within minutes.

An integration team escalated "random 400 errors" to the RAP team, attaching only the status codes. After introducing the incident template, the next report included the error body: "Quantity must be greater than 0", target "Quantity". The partner system sent empty quantities for some catalog items.
The partner fixed their mapping in a day. Over the following month, the team found that over 80% of reported OData errors were resolvable from the error body alone, and escalations dropped sharply.

• Looking only at the status code, not the error body.
• Treating every 403 as missing authorization.
• Forgetting IsActiveEntity in keys and getting 404.
• Using If-Match: * to "fix" 412 and overwriting newer data.
• Debugging code before checking the error logs.
• Incident reports without URL, body or time.

• Always log and report the full error body.
• Map status codes to first checks (table above).
• Use /IWFND/ERROR_LOG, Cross Trace and external breakpoints in that order.
• Make RAP messages clear with %element so "target" is meaningful.
• Standardize an incident template for consumers.

Questions: "How do you troubleshoot a failing OData call?", "What does 412 mean?", "Why can a POST return 403 although the user has roles?"
Strong answer: read status and error body; 400 request/business error, 401 authentication, 403 CSRF vs authorization, 404 URL/publish/key (IsActiveEntity), 405 operation not exposed, 409 lock, 412 ETag mismatch, 428 missing If-Match, 500 dump. Tools: /IWFND/ERROR_LOG, /IWBEP/ERROR_LOG, ST22, ABAP Cross Trace, external breakpoints; clear metadata caches for contract changes.