Hi Friends,

I use a quite simple example to demonstrate:

/wp-content/uploads/2013/11/clipboard1_325257.png

Execute the report, debugger will stop at line 23.

Click this button:

/wp-content/uploads/2013/11/clipboard2_325258.png

/wp-content/uploads/2013/11/clipboard3_325283.png

The debugger will automatically show tab as below:

/wp-content/uploads/2013/11/clipboard4_325284.png

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

/wp-content/uploads/2013/11/clipboard5_325285.png

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.

/wp-content/uploads/2013/11/clipboard6_325286.png

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

/wp-content/uploads/2013/11/clipboard7_325287.png

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.

/wp-content/uploads/2013/11/clipboard8_325288.png

click F5, now <first> is filled.

/wp-content/uploads/2013/11/clipboard9_325289.png

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

/wp-content/uploads/2013/11/clipboard10_325290.png

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.

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

    1. Jerry Wang Post author

      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,

      Jerry

      (0) 
    2. Suhas Saha

      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 … ℹ

      (0) 
    1. Jerry Wang Post author

      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,

      Jerry

      (0) 
      1. Fabio Pagoti

        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.

        Cheers,

        Fabio Pagoti

        (0) 
  1. walker cabay

    If we want to reuse the same set of statements more than once in a program, we need to include them in a macro. For example, a macro can be useful for long calculations or for writing complex WRITE statements. We can only use a macro within a program in which it is defined. Macro definition should occur before the macro is used in the program.

    Macros are designed based on placeholders. Placeholder works like pointers in C language. You can define a macro within the DEFINE…END-OF-DEFINITION statement.

    Following is the basic syntax of a macro definition

    DEFINE <macro_name>. <statements>
    END-OF-DEFINITION.
    ……

    <macro_name> [<param1> <param2>….].

    More Informations: http://sapabapcentral.blogspot.in/p/125-sap-abap-macros.html

    (0) 
    1. Richard Harper

      I think we know how to define a macro.  As to their use,  I use them for common parameter screen definitions.  For example defining a block:

      Define Begin_Of_Block.
             Selection-Screen Begin Of Block &1 With Frame Title Text-&1.
      End-Of-Definition.

      Or data declarations

      Define Standard_Table.
             Types: &1 Type standard table of &2 with default key.
      End-Of-Definition.
      
      
      Standard_Table: Dynpro_Updates         Dynpro_Update,
                      Interface_Descriptions Interface_Description.

      Even to the extent of defining getter and setter methods in local classes.

      Macros are a good tool when used properly and make code a lot easier to read and modify.

      Rich

      .

      (0) 

Leave a Reply