Capture one ABAP run in the debugger
abap_debugDebug ABAP code on a connected SAP system by setting breakpoints, running unit tests or an OData GET, and capturing call stacks and variables in one call.
Instructions
Debug ABAP code on the connected SAP system in ONE call: arm breakpoints (lines or class methods in CLAS, PROG or FUNC objects, optionally with an ABAP condition; or where a message is issued, a statement kind runs, an exception is raised; watchpoints, set at the first stop, then stop wherever a variable changes), run the code (its harmless ABAP Unit tests, an OData GET, or wait while you run it yourself as the same SAP user), and at every stop of that one run record the position, the call stack, the variables and optional steps — then release the program and remove the breakpoints. The program runs once, however many stops you ask for: a breakpoint in a loop with hits 5 shows five iterations of the same run. Nothing stays stopped after the call returns, so name every variable you need up front; to look again, run another capture — or start an interactive session (interactive: true) and decide each move with abap_debug_session. Lines are numbered as abap_source shows the ACTIVE source. Per capture: at most 20 breakpoints and 50 stops, and as many steps as the budgets allow — the run is followed until its result size (maxResultKB, default 40 KB) or inspection time (maxSeconds, default 120 s) runs out, then goes on without stopping. Past 20 steps from one stop, the steps come back as a compact trace; until ends them at a line or once a variable changed. Result: hit; breakpoints (set, with the hits they made, or refused with SAP's reason); debuggee; stops (at, stoppedAt, stack and variables on a breakpoint's first stop — its later stops carry only values, unchanged structures and tables marked so; steps, or a trace of a long run: path = the lines executed per frame, (9-12)×300 = a loop, changes = values where they changed); release; trigger; warnings. Without a stop: reason and hint. A call answers within ABAP_DEBUGGER_CALL_SECONDS (default 50 s). A capture still waiting for its stop or following its run then answers running: true with its session id, and goes on: abap_debug_session action wait picks up its result, action end stops it. It never changes variables or the program flow, never debugs system code, and only debugs the session's own SAP user; it refuses when Eclipse or VS Code already debugs that user.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | trigger=http: a host-relative OData path on the connected system, e.g. /sap/opu/odata4/sap/zui_travel/srvd/sap/ztravel/0001/Travel?$top=1. GET only: saves and actions need a unit test or trigger=none. | |
| line | No | Shorthand for one breakpoint at this 1-based line of type + name. | |
| name | No | Object name of `line`, and the default of every breakpoint and of the unit-test trigger. | |
| type | No | Object type of `line`, and the default of every breakpoint: CLAS, PROG or FUNC. | |
| steps | No | Steps after each stop (default 0; with until and no steps: step until it holds). Up to 20 come back one entry each (position and variables); more come back as a compact trace — the lines executed, loops folded as (9-12)×300, the variables only where they changed. Only maxSeconds and maxResultKB bound how far it goes. | |
| until | No | End the steps early: once the run stands on a line of the source the steps started in, and/or once a variable changed. | |
| watch | No | Watchpoints (max 5), set in the run at its first stop, after that stop's steps: the run then also stops wherever a variable changes — where does LV_STATUS change, or become 'E' with a condition? Each stop says from and to. The variable must be visible at that first stop (a local of its method, an attribute ME->…, a global); SAP refuses it otherwise. | |
| trigger | No | What runs the code. unittest (default): the harmless ABAP Unit tests of triggerName, else of type + name, else of the first breakpoint object (FUNC: its function group). http: a GET of url. none: the capture only waits timeoutSeconds while you run the code yourself (Fiori app, SE38, Postman) as the SAME SAP user. | |
| stepMode | No | over (default): stay in the method; into: follow calls into the called method; out: return to the caller. | |
| variables | No | Read at every stop and after every step: LV_TOTAL, LS_HEAD-VBELN, LT_ITEMS, LT_ITEMS[3], ME->MV_STATE, SY-SUBRC (max 20). Structures expand one level, tables show their first 5 rows. Default: every variable of the stopped frame (up to 60). The run is released when the call returns, so ask for everything up front. | |
| maxSeconds | No | Time budget of the inspection once the run stopped (default 120): long step runs need more — each step costs two or three requests to SAP. The server's ceiling applies (ABAP_DEBUGGER_MAX_SECONDS, default 600). The program waits in a work process meanwhile. | |
| breakpoints | No | The stops of the run (max 20): each a line, a CLAS method, a message, a statement kind or an exception class. One run can stop in several objects. | |
| interactive | No | true: an interactive session — return at the first stop and keep the program waiting there, then drive it call by call with abap_debug_session (step, continue, inspect, end), deciding each move from what you see. steps, if given, run before this call returns. The program holds a work process until the session ends; it is released after a while without a call. Default false: the whole capture in this one call. | |
| maxResultKB | No | Size budget of the result in KB of JSON (default 40, about 10k tokens); the server's ceiling applies (ABAP_DEBUGGER_MAX_RESULT_KB, default 200). | |
| triggerName | No | trigger=unittest: the class, program or function group whose unit tests run the code, when it is not the breakpoint object. | |
| exceptionClass | No | Also (or only) stop where this exception class is raised, e.g. CX_SY_ZERODIVIDE. | |
| timeoutSeconds | No | How long to wait for the first stop (1-900, default 60). |