Architect / Cross-trackintermediate

RAP Build-Along Part 9: Production Troubleshooting — Metadata, Behavior, Messages and Save

Key takeaway

Troubleshoot the Travel app layer by layer: missing fields or actions (metadata), disabled buttons (feature control vs authorization), messages that do not appear, and save failures — with a checklist and the right tools.

Explanation

📌 KEY POINTS
✅ Localize the layer first: service/metadata → behavior (feature control, authorization) → messages → save.
✅ Field or action missing → projection, projection BDEF, service definition, binding, $metadata.
✅ Button disabled → feature control; request rejected → authorization — check which one.
💡 Tools: $metadata, ABAP Cross Trace, /IWFND/ERROR_LOG, EML test class, external breakpoints.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–8 built the Travel app. This final basics lesson is the support checklist you will use every week. Details: Service Definitions Part 4, CDS Annotations Part 5, Draft Handling Part 5, OData V4 Part 5.

━━━━━━━━━━━━━━━━━━━━
▶ 1. SYMPTOM: FIELD OR ACTION MISSING
Check in order:

Is the field in the projection view (ZC_RAP_Travel) element list?
Is the action in the projection BDEF ("use action acceptTravel;")?
Is the entity exposed in the service definition, binding refreshed/published?
Does $metadata contain it? Missing → backend layers 1–3; present → UI annotations (@UI.lineItem #FOR_ACTION, facets) or caches.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SYMPTOM: BUTTON DISABLED OR ACTION REJECTED

Disabled button → instance feature control (get_instance_features) returns disabled for this state (e.g. travel already accepted). Check the status.
Enabled but rejected with "not authorized" → authorization (get_instance_authorizations / global) or roles.
Test with EML GET PERMISSIONS or a Cross Trace to see which method decided.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SYMPTOM: ERROR BUT NO USEFUL MESSAGE

Validation fills FAILED but not REPORTED → user sees a generic error. Always add a message.
Message not attached to a field → add %element.
Old messages stay in draft → use %state_area and clear it.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 4. SYMPTOM: SAVE FAILS OR "DOES NOTHING"\n• Draft: Prepare/Activate returned validation errors (check network or message popover).
Total ETag conflict → someone changed the travel meanwhile.
Short dump in saver/additional save → ST22.
Unmanaged save / legacy call failing → errors must be raised before save (check_before_save), not in save.

━━━━━━━━━━━━━━━━━━━━
▶ 5. SYMPTOM: SLOW LIST

Check $select/$expand in the request, CDS view design, and SQL trace (ST05).

━━━━━━━━━━━━━━━━━━━━
▶ TOOLS SUMMARY

$metadata of the binding — what the service really offers.
ABAP Cross Trace (ADT) — which RAP methods ran for a request and their results.
External breakpoint for the user — debug a Fiori request.
EML test class — reproduce without UI.
/IWFND/ERROR_LOG, ST22 — errors and dumps.

✅ CHECKPOINT: you can localize any Travel app issue quickly. RAP Basics complete — continue with the deep-dive topics (CDS Views, RAP Business Objects, BDEF, Behavior Implementation, EML…).

Code example

ABAP Code

" ===== Reproduce without UI: EML console class for the Travel BO =====CLASS zcl_rap_travel_check DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    INTERFACES if_oo_adt_classrun.ENDCLASS. CLASS zcl_rap_travel_check IMPLEMENTATION.  METHOD if_oo_adt_classrun~main.    DATA(travel_uuid) = VALUE sysuuid_x16( ).   " fill with the failing travel's key     " 1. Is the action allowed? (feature control + authorization)    GET PERMISSIONS ONLY INSTANCE ENTITY zi_rap_travel      FROM VALUE #( ( TravelUUID = travel_uuid ) )      REQUEST VALUE #( %action-acceptTravel = if_abap_behv=>mk-on )      RESULT DATA(permissions)      FAILED DATA(perm_failed)      REPORTED DATA(perm_reported).    out->write( permissions ).     " 2. Execute the action and read messages    MODIFY ENTITIES OF zi_rap_travel      ENTITY Travel EXECUTE acceptTravel      FROM VALUE #( ( TravelUUID = travel_uuid ) )      FAILED DATA(failed) REPORTED DATA(reported).     COMMIT ENTITIES RESPONSE OF zi_rap_travel      FAILED DATA(commit_failed) REPORTED DATA(commit_reported).     LOOP AT reported-travel INTO DATA(msg).      out->write( msg-%msg->if_message~get_text( ) ).     " no text? -> missing REPORTED    ENDLOOP.    ROLLBACK ENTITIES.                                     " diagnostic only  ENDMETHOD.ENDCLASS. " ===== Checklist by symptom =====" field/action missing  -> projection view | projection BDEF (use) | service def | binding | $metadata" button disabled       -> get_instance_features (status!)" 'not authorized'      -> get_instance_authorizations / roles" generic error         -> FAILED without REPORTED; add message + %element" stale draft messages  -> %state_area" save fails            -> Prepare/Activate messages | total ETag | ST22 in saver" slow list             -> $select/$expand | CDS design | ST05

Real project scenario

Support received "Accept button does not work" for some travels. The developer started debugging the action implementation. Using the checklist, the first step (GET PERMISSIONS in the EML test class) showed the action was disabled by feature control because those travels already had status "accepted".
The button's disabled state was correct; users simply did not see the status. The team added the status column with criticality colors to the list and object page, and the tickets stopped — no code change to the action was needed.

Common mistakes

Debugging code before localizing the layer.
Confusing feature control (disabled) with authorization (rejected).
FAILED entries without REPORTED messages.
Forgetting projection BDEF "use" statements for new actions.
Ignoring caches after metadata changes.
Raising errors in the save phase instead of before it.

Best practices

Use the symptom checklist before debugging.
Keep an EML test class per BO for fast reproduction.
Always return a message with %element for rejections.
Use Cross Trace and $metadata as first tools.
Document recurring causes in the support wiki.

Interview angle

Questions: "An action button is missing or disabled in a RAP app — how do you analyze?", "How do you troubleshoot RAP issues in production?"
Strong answer: localize by layer — metadata/exposure (projection, projection BDEF use, service definition, binding, $metadata), behavior (feature control vs authorization, testable with GET PERMISSIONS), messages (REPORTED, %element, %state_area), save (Prepare/Activate, total ETag, ST22). Tools: Cross Trace, EML test classes, external breakpoints, /IWFND/ERROR_LOG, ST05.

Practice this lesson

Quick check

1. An action button is visible but disabled for some instances. Which method most likely decides this?

2. A RAP OData request fails with HTTP 500. Where do you look first?

3. After a transport, an action button disappeared in QAS but works in DEV. What is the most likely cause?

Interview questions

1. A RAP OData call returns HTTP 500. How do you proceed?

Answer it in your own words first, then compare.

2. The "Accept" action is disabled for some travels. How do you find out why?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.