Skip to Content

Single step debugging on Macro

I use a quite simple example to demonstrate:


Execute the report, debugger will stop at line 23.

Click this button:



The debugger will automatically show tab as below:


then we can execute the macro code one by one by clicking F5:


the line 22 and 23 just represent the ABAP code CHECK strlen(&1) >= 5.

We observed after macro line 22 and 23 are executed, our internal table lt is still empty. This is working as expected, since now the APPEND statement in Macro code is not executed yet.


The internal table is filled after Macro code 27 is executed.


before Macro code line 28 is executed, <first> is not valid, since the respective ABAP code READ TABLE &2 ASSIGNING <first> INDEX 1. in line 14 is not executed yet.


click F5, now <first> is filled.


After Macro code 33~35 is executed, the string concatenation is done.


Although you can debug Macro this way, it does not mean you should not think twice when you use Macro in your code. There are already plenty of discussion and blog in SCN regarding how to use Macro wisely. Hope this blog helps you when you have to debug some complex Macro in legacy code.

You must be Logged on to comment or reply to a post.
    • Hi Janagar,

      Thank you for your information. I just tried in my system, and I could not debug the macro using system debugging. Would you please kindly share how you achieve that?

      best regards,


    • Janagar Sundaramoorthy wrote:

      I think we can also use system debugging option to debug Macro as well.. 🙂

      This is a fad & i'm sure macros cannot be debugged with the system debugging option turned on ... ℹ

    • Hi Ankit,

      Regarding the BYTE CODE, if you are referring to the screenshot in my blog, I don't think it is difficult to understand their meaning since they look something like ABAP command. But if you are referring to code like "xper 06  2F0C  0018  0016  ", I am afraid there is no public documentation on them. Why do we application developer need to understand them? Just out of curiosity? 🙂

      Best regards,


      • I haven't beforehand but now I have. Well.. I still have the same opinion. The reasons given in this blog or not enough: I disagree with some of them (code readability using macros) and some are not common problems when using ABAP (defining DSL).

        My point of view is simple:

        1 - They won't be debugged. Note that to debug a macro you have to know that it exists in your code. What if you set a breakpoint for all "PERFORM"s in code? The ones inside a macro won't stop the execution of the program. What if you set a watchpoint for a variable changed inside a macro? It will stop way after the macro. Moreover, there are many functional consultants who although are not able to write ABAP code, are able to read and debug it. So when it comes to readability in ABAP, I wear a functional hat and ask myself if a functional would be lost after a piece of code. In case of a macro, definitely he would be lost after a single line of code have changed many variables all at once.

        2 - Macros are faster: yes indeed. However based on my experience in 90% of performance issues the most timing consuming code I have founded is within SELECTions in the database and searches inside internal tables. In other words, if you can write good SELECT statements and know how to use other types of internal tables other than STANDARD, it's very likely your code won't have any performance problems.

        3 - You cannot unit test a macro. And that's why I don't use PERFORMs either.


        Fabio Pagoti