Structuring source code

This article focuses on the two particular modularization units used for structuring the source code - includes and macros.

ABAP Workbench uses include techniques extensively, especially in
Module Pool or Function Pool programs. This should not be new to you 
ABAP programmers. However, macros (the other way of structuring your
source code) are used in many SAP standard areas like HR, Business 
Object Repository, Web applications, etc. and you need to know what 
they are and how they work.

This article focuses on the two particular modularization units
used for structuring the source code - includes and macros.


There are two kinds of modularization units: 
Those that allow you to structure tasks and those 
that allow you to structure source code.
The modularization units used for performing a task are:

Internal subroutine
External subroutine
Function module
Method
Transaction
Report (SUBMIT)
Dialog module (obsolete)
Screen (CALL SCREEN)
Selection screen (CALL SELECTION SCREEN)
GUI Status and title
Module
ABAP Event
Context

The modularization units that you can use to structure your source code are:

Includes
Macros


Let's have a look at the Includes and Macros.


Include Programs

You use include programs to create shared program sections or to 
divide programs into smaller parts that are easier to maintain.
The INCLUDE statement has the same effect as copying the source code
of the include program into the main program at the point where it occurs.
When you check the syntax of an include, the system combines the 
current contents of the Editor with the contents of the TOP include to 
form a unit whose syntax and semantics can be checked sensibly. 

Refer to the menu item Program->Check->Main program. This is the only way that 
everything is checked (for example, whether a subroutine called using 
PERFORM exists). The reason for the otherwise incomplete check is 
that the syntax check is optimized for performance. Since subroutines 
normally occur in a different include to the PERFORM statements that 
call them, a full check will require too many includes to be checked.
Includes are not loaded dynamically at runtime, they are expanded
when the program is generated.


Include programs do not have a parameter interface. They are used in 
the main programs of function modules, module pools and more and more
in executable programs (or reports) to group together parts of the program
that logically belong together.

Include programs can not run independently, but must be embedded in 
other programs. You can embed includes within other includes, but 
recursive calls are not allowed.

You can use the where-used list function in the Repository Browser to find
the programs in which a particular include is used.


Macros

You define macros using the following statement block

DEFINE 
 
  .
 
  
   
END-OF-DEFINITION.

You must specify full statements between the DEFINE and 
END-OF-DEFINITION statements. The statements may contain up to 
nine placeholders &1, &2, ?, &9. The definition of a macro must appear
in the program before it is called.
You run a macro using the statement 
   
     [
     
     
       ? 
      
       ].

DATA: result TYPE I.

DEFINE operation.
    result = &1 &2 &3.
    output  &1 &2 &3 result.
END-OF-DEFINITION.

DEFINE output.
    WRITE: / 'The result of &1 &2 &3 is', &4.
END-OF-DEFINITION.

operation 4+ 3.
operation 2 ** 7. 

The output generated by the program will be:

The result of 4 + 3 is 7
The result of 2 ** 7 is 128


When a program is generated, the macro is replaced by the corresponding
statements, and the placeholders &I are replaced by the parameters 
       
        . 
Macros may call other macros, but may not call themselves.

The above example contains definitions for two macros,
OPERATION and OUTPUT. OUTPUT is nested within OPERATION. 
OPERATION is called twice with different parameters. Note how the
placeholders &1, &2, &3 are replaced.

The disadvantage of macros is that the macro call is difficult to
interpret, especially if the definition and call are a long way apart 
in the program. Another disadvantage is that the Debugger does not step
through macros' statements. Instead, it executes them in a single step. 
Macros should not be used, since if they become too complicated, you will
be the only person to understand them. Use instead a subroutine. However,
since macros are used in some programs in the SAP standard, you need to 
know what they are and how they work.

You'll find a number of macros with their statements in the table TRMAC,
a very well known one being the BREAK macro. Take a look at it, try it in
your program and discover a very personal way of starting the Debugger.

You can learn more about 'include programs' in SAP Classes BC400 
(ABAP Workbench Concepts and Tools), BC410 (ABAP Workbench User Dialogues),
and BC425 (Enhancements and Modifications).


For information about these and all other SAP Educational Services 
classes, visit us at 
         
SAP Education Online

       
      
     
    
   
  
 

This was first published in October 2001

Dig deeper on SAP ABAP

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchManufacturingERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchFinancialApplications

Close