1.

Business Context – Why We Debug an

Unmanaged RAP Program
Typical Business Scenario (Brownfield Reality)
An organization running ECC legacy logic migrates to RAP for:

• Fiori enablement
• API exposure
• Upgrade-safe extensibility

But business logic already exists in:

• Function Modules
• Global Classes
• Update tasks
• BAPIs

Hence Unmanaged RAP + Facade Pattern

Business complaints you’ll hear:

• “Data not saved”

• “Save button spins but nothing happens”
• “Error shown but no message details”
• “Draft activated but record missing”
• “Works in backend, fails in Fiori”

All of these require deep debugging, without touching code.

2. Unmanaged RAP – Objects Involved

(Debug Perspective)
Key Technical Objects

Layer Object Why It Matters in Debug

Data Model CDS Interface View Field mapping issues
Behavior Behavior Definition Save lifecycle
Behavior Behavior Implementation Validation / action
Save Layer Saver Class Single most important debug point
Legacy FM / Class Actual DB logic
 Layer Object Why It Matters in Debug
Framework RAP Runtime Controls transaction

3. Unmanaged RAP Call Flow (What You

Debug, Not Where)
Understanding call sequence is more important than breakpoints.

Fiori UI
↓
OData Runtime
↓
RAP BO Runtime
↓
Behavior Implementation
↓
Saver Class
↓
Legacy FM / Class
↓
Database

Since we cannot inject breakpoints, we attach the debugger dynamically.

4. Debugging Without Hard-Coded

Breakpoints – Allowed Techniques
Technique Matrix (Enterprise-Safe)
Technique Allowed in Prod Used In RAP
External Breakpoint Primary
HTTP Breakpoint OData
Debugger Attachment Late
Conditional Breakpoint Advanced
Watchpoints Advanced
Logging (SLG1) Best practice
SQL Trace (ST05) Persistence
Runtime Error Analysis Dumps
Gateway Error Log UI issues
 BREAK-POINT
ASSERT misuse
Test-only logic

5. Where to Attach Debugger in

Unmanaged RAP (Critical)
Saver Class – Primary Debug Entry
This is non-negotiable.

CLASS zcl_so_saver DEFINITION

INHERITING FROM cl_abap_behavior_saver.

How to Debug (No Code Change)

1. Open class in SE24 / ABAP Dev Tools

2. Set external breakpoint on method:
o save
o finalize
3. Trigger save from Fiori / API
4. Debugger attaches automatically

This works even in QA / PROD (with authorization).

Behavior Implementation Class

CLASS lhc_salesorder DEFINITION
INHERITING FROM cl_abap_behavior_handler.

Set external breakpoints in:

• Validation methods
• Action methods
• Authorization methods

No code modification required.

6. Example – Unmanaged RAP Sales Order
Save (Debug Walkthrough)
Behavior Definition (Context Only)
define behavior for ZI_SalesOrder
unmanaged
{
create;
update;
delete;

save;
}

Saver Class – What You Inspect in Debugger

METHOD save.

LOOP AT mapped-salesorder INTO DATA(ls_map).

CALL FUNCTION 'ZFM_SALES_SAVE'
EXPORTING
is_header = ls_map
EXCEPTIONS
OTHERS = 1.
ENDLOOP.

ENDMETHOD.

Debug Focus (Without Breakpoints)

In debugger, inspect:

• mapped-salesorder
• %tky values
• Field completeness
• Data consistency

90% RAP save issues are mapping issues, not FM issues.

7. Debugging Legacy FM Called from RAP

Legacy FM (Unchanged Code)
FUNCTION zfm_sales_save.
INSERT zso_hdr FROM is_header.
ENDFUNCTION.
How to Debug

• Place external breakpoint inside FM

• Or attach debugger manually after save trigger

Key checks:

• sy-subrc
• Lock objects
• Update task usage
• Authorization checks

8. Debugging When Save Does NOT

Happen
This is common and confusing.

Scenario: Fiori Save → No DB Record

Debug Strategy

1. Attach debugger to Saver class

2. Check if save method is reached
o Not reached → validation / authorization failed
3. If reached:
o Inspect mapped-*
o Inspect FM call
4. Use ST05 SQL trace
o No INSERT → save logic not triggered
o INSERT + rollback → error later

9. Debugging Validation Failures (Without

Code Change)
Validation logic lives in Behavior Implementation.

METHOD validate_qty.
LOOP AT entities INTO DATA(ls_entity).
IF ls_entity-quantity <= 0.
APPEND VALUE #( %tky = ls_entity-%tky ) TO reported-salesorder.
ENDIF.
ENDLOOP.
ENDMETHOD.

Debug Without Breakpoints

• External breakpoint on method

• Inspect:
o entities
o reported-*
o Message severity

If reported is filled → save will never reach saver.

10. Debugging Authorization Issues (Very

Common)
Authorization failure silently blocks save.

METHOD authorization.
LOOP AT requested_authorizations ASSIGNING FIELD-SYMBOL(<auth>).
<auth>-authorized = abap_true.
ENDLOOP.
ENDMETHOD.

Debug Checks

• Is authorization method triggered?

• Instance vs global auth
• CDS DCL vs RAP authorization conflict

Tools:

• External breakpoint
• SU53
• STAUTHTRACE

11. Debugging Without Debugger – Logging

(Best Practice)
For restricted systems, logging is preferred.

Application Log (SLG1)

cl_bal_log=>create(
 EXPORTING
i_object = 'Z_RAP'
i_subobject = 'SAVE' ).

Log:

• Incoming mapped data

• FM response
• Error messages

This avoids debugger completely and is audit-safe.

12. SQL Trace – Your Only Window into

Persistence
Since RAP controls commit:

Use ST05:

• Activate SQL trace for user

• Trigger save
• Look for:
o INSERT
o UPDATE
o ROLLBACK

If no SQL → RAP never reached persistence phase.

13. Production Debugging Strategy (Real

Projects)
Problem Tool
Save not triggered External breakpoint in saver
Validation failure External breakpoint in behavior
Data not inserted ST05
Silent failure SLG1
Authorization SU53
UI error Gateway error log
14. Common Misconceptions (Corrected)
“Put breakpoint in CDS”
“Commit missing in FM”
“RAP did not call FM”
“Fiori issue”

RAP blocked save due to lifecycle rule

Mapping incomplete
Authorization failed
Validation raised error

15. Architect-Level Conclusion

Unmanaged RAP debugging is about where you attach, not what you change.

• Never inserts BREAK-POINT

• Knows exact lifecycle
• Uses external breakpoints + SQL trace
• Reads mapped, entities, reported
• Treats saver class as the single source of truth