OData V2 Part 3: Production Troubleshooting — Gateway Logs and Metadata

📌 KEY POINTS
✅ Evidence first: method, full URL, headers, body, status, error body, time and user.
✅ /IWFND/ERROR_LOG (hub) and /IWBEP/ERROR_LOG (backend) show failed calls with details.
✅ Reproduce with /IWFND/GW_CLIENT; trace a user with /IWFND/TRACES.
⚠️ "Changes not visible" is often a metadata cache — clean it, don't redeploy.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–2 built and used V2 services. This part is the production playbook (for RAP V4 errors see OData V4 Part 5).

━━━━━━━━━━━━━━━━━━━━
▶ 1. COLLECT EVIDENCE
From the reporter or browser DevTools: HTTP method, full URL, request headers (without secrets), body, status, error body, timestamp, user. For $batch, the inner request that failed.

━━━━━━━━━━━━━━━━━━━━
▶ 2. GATEWAY TOOLS

• /IWFND/ERROR_LOG — on the gateway (hub or embedded): failed requests, error text, call stack, and "Replay" in GW client.
• /IWBEP/ERROR_LOG — on the backend: errors from data provider classes.
• /IWFND/GW_CLIENT — send requests as the logged-on user (like Postman inside SAP), including $batch.
• /IWFND/TRACES — activate payload and performance trace for a specific user; reproduce; analyze.
• ST22 — dumps behind 500 errors; SM21 system log; ST05/SAT for performance.
• /IWFND/MAINT_SERVICE — service registration, system alias, ICF node status.

━━━━━━━━━━━━━━━━━━━━
▶ 3. TYPICAL ERRORS

• 404 on the service root → service not registered/activated in /IWFND/MAINT_SERVICE or ICF node inactive (SICF).
• 403 → CSRF token missing, or user lacks S_SERVICE / role for the service.
• 400 → invalid $filter syntax, unknown property, wrong key format, business exception.
• 500 → dump or unhandled exception in DPC_EXT — ST22.
• "Resource not found for segment" → wrong entity set name or key.
• Metadata errors after a model change → cache.

━━━━━━━━━━━━━━━━━━━━
▶ 4. METADATA CACHE
Gateway caches metadata on hub and backend. After model changes (new field, new entity), clients may still see the old model.

• Clean up: /IWFND/CACHE_CLEANUP (hub) and /IWBEP/CACHE_CLEANUP (backend), or "Cleanup cache" in /IWFND/MAINT_SERVICE for the service.
• Also clear browser/launchpad cache for Fiori apps.

━━━━━━━━━━━━━━━━━━━━
▶ 5. SYSTEM ALIAS (HUB SCENARIO)
In a hub deployment, the service is registered on the gateway system with a system alias pointing to the backend. Wrong alias → service calls the wrong backend or fails with RFC errors.

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

1. Take one failed call from /IWFND/ERROR_LOG and replay it in GW client.
2. Activate /IWFND/TRACES for your user, reproduce, read the payload.
3. Change a model field in DEV; observe stale metadata; clean the cache; verify.

✅ CHECKPOINT: you can solve V2 incidents with evidence. OData V2 series complete.

After a transport added a new field to a SEGW service, the Fiori app still did not show it in QAS. The team transported the service again twice. The field was present in the backend model, but the gateway hub served cached metadata.
Running /IWFND/CACHE_CLEANUP on the hub and /IWBEP/CACHE_CLEANUP on the backend (plus a browser cache refresh) made the field appear immediately. "Clean metadata cache after model transports" was added to the deployment checklist.

• Starting without the failing URL, body and error text.
• Redeploying instead of cleaning the metadata cache.
• Treating every 403 as missing authorization.
• Forgetting the ICF node or system alias in hub scenarios.
• Not using /IWFND/TRACES for user-specific issues.
• Raising generic exceptions without business messages.

• Standardize incident evidence.
• Use error logs, GW client and traces before debugging.
• Clean hub and backend caches after model changes.
• Verify registration, ICF node and system alias.
• Raise business exceptions with clear messages in DPC_EXT.

Questions: "How do you troubleshoot a failing OData V2 service?", "A new field is not visible — what do you do?", "Which gateway transactions do you use?"
Strong answer: collect evidence; check /IWFND/ERROR_LOG and /IWBEP/ERROR_LOG, replay in /IWFND/GW_CLIENT, trace with /IWFND/TRACES, dumps in ST22; verify registration, ICF node and system alias in /IWFND/MAINT_SERVICE/SICF; for stale metadata run /IWFND/CACHE_CLEANUP and /IWBEP/CACHE_CLEANUP; map status codes to causes (404 registration, 403 CSRF/S_SERVICE, 400 syntax/business, 500 dump).