Skip to Content

ST12 – tracing a single dialog step

Imagine you change an order in VA02 and after clicking a specific button (e.g. the ATP (available to promise) check) it takes a while. Now you wonder what happens when you click this button and how you could trace exactly this click. In this blog we will explain how to trace a single dialog step with the “Particular Units” option in ST12. 

Before you start:

Please read the “Before you start” section in this blog first:

Single Transaction Analysis (ST12) – getting started

We’ll use the “Current Mode” scenario and the same tracing options as described in the above mentioned blog.

ST12 – Tracing a single step

After filling in the transaction and a comment for the trace (nr. 1 in figure 1) we select the “Particular units” option.  Note: this option is only available in the “Current Mode” Scenario. All other options are set like described in the above mentioned blog.

main screen

Figure 1 – Trace with particular units

Executing the trace for particular units

We are ready to start our trace (nr. 3 in figure 1).

All we have to do is to mark the part we want to trace while we step through VA02. The prerequisite is that you switch on the “Particular Units” option in ST12 as shown above.

If you look at figure 2 which shows the steps we execute in VA02 to do an ATP check you can see that there are some steps that we don’t want to trace:

We don’t want to trace the whole execution (dashed black arrow) between T1 and T2 but only the ATP check (solid red arrow) between T1a and T1b. Note: As you can see in figure 2 the ST05 trace (dashed green arrow) records the whole execution of the transaction but not only particular units of it.


Figure 2: Executing VA02 with current mode particular units

While  executing VA02 we have to mark which parts of the execution should be traced with the ABAP trace:


Figure 3: VA02

After you start the trace (nr. 3 in figure 1) VA02 (or the transaction /program you entered in the corresponding transaction / program field in ST12 in the main screen) will show up. Since we switched on the “Particular Units” nothing is traced so far. Now we enter the order and select it.  During selection and when we do our changes, nothing will be recorded in the ABAP trace yet. Right before we click on the ATP check button (nr. 2 in figure 3) we type “/ron” in the ok-code field (this is the field where you type in the transactions e.g. ST12 as well) and press ENTER (nr. 1 in figure 3). This marks that the ABAP trace should be recorded from now on. This is confirmed with the message “Runtime analysis enabled” at the bottom of the screen (nr. 1 in figure 3).

After that we execute the ATP check by clicking on the button (nr. 2 in figure 3). The next screen shows the result of the ATP check. We have to set the second marker now that indicates we want to stop trace recording so that nothing else is traced from this point on. We enter “/roff” in the transaction code field (nr. 3 in figure 3). We get the message “Runtime analysis disabled” at the bottom of the screen (nr. 3 in figure 3). After this, nothing else (e.g. clicking on save) will be recorded in the ABAP trace any more. If you return to ST12 and open the ABAP trace, it will only contain these parts of the execution that were running between the markers “/ron” and “/roff”. Note that the performance trace (ST05) captures the whole execution of the transaction as shown with the dashed green line in figure 2.

Alternatives for the “/ron” and “/roff”

In dialog transactions you can either work with the ok codes “/ron” and “/roff” like we have seen above. Alternatively you can use the menu path:

System – Utilities(H) – Runtime Analysis – Switch on

System – Utilities(H) – Runtime Analysis – Switch off

In your own developments (e.g. for programs running in background) you can even do it in the ABAP code with these 2 commands:



This blog demonstrated the “Particular Units” option which is very useful if you want to trace a specific part of a program e.g. a single transaction step in dialog transactions.

And with special thanks to Sandra Rossi:

See how the above mentioned ok codes can be used in modal popup windows:

More information on ST12 can be found here:

ST12 WIKI and Blogs:


You must be Logged on to comment or reply to a post.
  • Thanks Herrmann for sharing your knowledge with the community. I’d just like to add that in modal popup windows, /RON or /ROFF can’t be entered in the okcode field. To “enter” them, we can create SAPGUI shortcuts, more info here: (freshly created!)
    One more thing, I often use SE30 with option “no aggregation” when I need to know the sequence of calls (for example to know when the exits are called relatively to update function modules). That would be great if SAP could fully integrate SE30 (and ST05) into ST12 😀
    • Hi Sandra,

      thanks for your comment. I updated the Blog with your link. Appreciated.

      Have you tried the “Bottom Up” Analysis in ST12 (I will write about it). Sometimes (not always) this option helps to get information out of “possible call stacks”.

      Kind regards,


        • Hi Sandra,

          since i haven’t started with this blog so far and the next few weeks will be busy, and since you are impatient a little preview:

          all you have to do is to mark the entry in question and press the 3rd button from the left.
          (bottom up analysis, the icon with the yellow box and 3 arrows).

          The next screen shows who MIGHT call whom. Since an UNAGGREGATED trace was taken all possible and not necessarily executed call relations are shown.

          I use it often for scenarios like this:

          Let’s say we have an identical select in a SAP standard function module that is executed because the function module is called very often with similar or the same parameters. I would like to know the “driver” of this calls not the calling position of the SELECT (what i get with SE30/ST05). With the bottom up analysis i can see with the arrows who might have called this function module.

          Kind regards,


          • I meant the “none aggregation” mode, and I think you’re talking about “aggregation per calling position”, right? “No aggregation” is useful when we need to know exactly the sequence of calls (to know what standard programs do exactly for example).
          • yes, ST12 only supports aggregation per calling position but has some nice features in the analysis part (blogs will follow)
  • Hi, I can’t use ST12 on ABSO transaction and I don’t know why. I can run ABSO from ST12, but instead of return to ST12 after transaction is complete I return to SAP menu….

    Any ideas?

    • If you call ST12 again? Is there a new trace?
      Can you find the trace in SE30? (ST12 uses SE30 under the covers to record the trace)
  • Hi,

    just adding small comment:

    sometimes you can find yourself in need of creating a SQL trace of some SQL intensive code. However, the full SQL trace of the program would be hard to read. You already know (from the previous traces) that only one particular method is causing the heavy DB load and therefore you are interested in DB performance especially of that one method.

    Now, if the program does not comprise of any dialog step (as it was created the way that it runs just from start to the end with no user interaction, fx. some program used to be scheduled as a job), then the use of /ron, /roff or switching on/off via menu in the middle of the program runtime is not possible.

    In the example below, you can see, how to switch the trace on only for that one method and also you can see how this partial ABAP trace can help you to be more efficient with your SQL trace analysis later.

    Tip: the following works only if the Classic debugger is used (New debugger runs in separate session and the link between the debugger session and ST12 session is not available. Caution: if you have two sessions opened, in session #1 ST12 was already started and you just switched from New debugger to Classic debugger in ABAP Workbench in session #2, then you need to start ST12 in session #1 from scratch again so that the debugger config info is re-read).

    Now it’s necessary to set a break-point in the program before the trace is started. Let’s say M2 is our SQL-heavy method:

    call method m1( ).

    call method m2( ). “set BP at this line

    call method m3( ).

    In ST12, use Current mode and set the Particular units checkbox in ABAP trace area as recommended and in Performance area traces use SQL checkbox. Run the trace. Once the BP is hit in the debugger (don’t get confused by status message saying “ABAP trace started, SQL trace started” – only SQL trace was started while ABAP trace was not, as this will be started now by you manually), use OK-code /ron to switch trace on, press F6 to process the method M2 and then switch off the trace with OK-code /roff again.

    As mentioned by Hermann Gahm, ST05 traces all SQL statements of the whole program despite of the ABAP trace being switched on just for method M2. However, the limited ABAP trace can be used for better focusing on SQL statements on tables involved in method M2.

    Once the trace is done then in Trace analyses, column Status, the icon ICON_GENERATE is displayed until the traces are not finally collected yet. Press Refresh status icon at the top of the screen until you get the green tick. Without that, the trace collection is not complete.

    Go to ABAP trace and filter the column Type for “DB->”. Now you can see all the tables accessed by Open SQL in method M2. If the trace collection was completed as recommended before, then the click on any “DB->” will let you to the detailed SQL analysis.

    Alternatively, you can keep the names of tables in clipboard and step back, go to Performance traces – extended display of full SQL trace is displayed, go one step back again with green arrow and press Display Trace where you put the content of the clipboard to extended selection criteria for Object. Now the SQL trace is displayed only for tables accessed in method M2.

    Cheers, Michal