ABAP Modularization: Macro, Subroutine & Function Module

โšก Smart Summary

Modularization in ABAP places a sequence of statements into a reusable unit that the main program simply calls. This page explains macros, include programs, subroutines, function modules, and function groups, with syntax, examples, and selection criteria for each technique.

  • ๐Ÿงฉ Core Principle: A modularization unit is generated as though its source code were physically present in the calling program, so structure improves without runtime cost.
  • โšก Macro: Defined with DEFINE and END-OF-DEFINITION, usable only inside the program that defines it, and only after the definition line.
  • ๐Ÿ“„ Include Program: Carries no parameter interface and exists solely to share source code, such as long data declarations, between several programs.
  • ๐Ÿ” Subroutine: Declared with FORM and ENDFORM, called with PERFORM, and suited to logic reused locally inside one program.
  • ๐Ÿงฑ Function Module: A system-wide routine with a typed interface for importing, exporting, changing, table parameters, and exceptions.
  • ๐Ÿ“ฆ Function Group: A container whose global data is shared by every function module inside it, generated automatically with its TOP and UXX includes.
  • ๐Ÿงญ Selection Rule: Choose a macro for local shorthand, a subroutine for local logic, and a function module when the routine must be reusable across the system.

Modularization in ABAP

What is Modularization in ABAP?

When you modularize source code, you place a sequence of ABAP statements in a module. Then, instead of placing all of the statements in your main program, you just call the module. When the program is generated, the source code in the modularization unit is treated as though it were actually physically present in the main program.

Need of Modularization

  • Improve the structure of the program.
  • Easy to read the code
  • Easy to maintain the code
  • Avoid redundancy and promotes code reuse

Various Modularization Techniques

  • Use of Macros
  • Use of include files
  • Subroutines
  • Function Modules

Lets look into each of them in detail :

SAP- ABAP Macro

If you want to reuse the same set of statements more than once in a program, you can include them in a macro.

You can only use a macro within the program in which it is defined, and it can only be called in lines of the program following its definition.

Macros can be useful for long calculations or complex WRITE statements.

Syntax

DEFINE <macro_name>

'Macro Statements

END-OF-DEFINITION

Macros can use Parameters &N where N = 1,2,3…

Example:-

DATA: number1 TYPE I VALUE 1.

DEFINE increment.

ADD 1 to &1.

WRITE &1.

END-OF-DEFINITION.

Increment number1.

WRITE number1.

Output: 2

A macro is expanded at compile time inside one program only. When the same code must be shared between programs, an include program is used instead.

Include Programs

Include Programs are solely for modularizing source code, and have no parameter interface.

Include programs allow you to use the same source code in different programs. They can be useful if you have lengthy data declarations that you want to use in different programs.

Syntax

Include <include program Name>

Points to Note

  • Include programs cannot call themselves.
  • Include programs must contain complete statements.

Example:

INCLUDE ZILX0004.

WRITE: / 'User', SY-UNAME,/ 'Date', SY-DATUM.

================================

PROGRAM ZRPM0001.

INCLUDE ZILX0004.

Include programs share code but cannot receive parameters. Subroutines add that missing parameter interface.

Subroutines

Subroutines are procedures that you can define in any ABAP program and also call from any program. Subroutines are normally called internally, that is, they contain sections of code or algorithms that are used frequently locally. If you want a function to be reusable throughout the system, use a function module.

Syntax-

FORM <Subroutine> [<pass>].

<Statement block>.

ENDFORM.

<Subroutine> = Name of the subroutine

<pass> = Parameters being passed

Types of Subroutines

  1. Internal
    • Subroutine defined in same program being called.
    • Can access all the data objects declared in the main ABAP/4 program.
  2. External
    • Subroutine defined outside the program being called.
    • Need to use the <pass> option or declare data objects in common parts of memory.

Calling a Subroutine

Internal Subroutines

PERFORM <subroutine> [<pass>]

<subroutine> = Name of the subroutine

<pass> = Parameters being passed

Data declared in main program is automatically available.

External Subroutines

PERFORM <subroutine>(<Program>) [<pass>].

PERFORM <subroutine> (<Program>) [<pass>] [IF FOUND].

PERFORM (<subroutine>) IN PROGRAM  (<Program>) [<pass>] [IF FOUND].

PERFORM <index> OF <subroutine1> <subroutine2> <subroutine3> [<pass>].

Points to Note

  • Nested calls are allowed in subroutines (i.e. PERFORM within a FORM … ENDFORM ).
  • Recursive calls are also possible.
  • To define local data, use the DATA statement after FORM . Each time you enter the subroutine, the data is recreated (with an initial value) and released at the end (from the stack).
  • To define global data used within a subroutine, use the LOCAL statement after FORM . The values are saved when you enter the subroutine and then released at the end (from the stack)

๐Ÿ’ก Tip: Subroutines are considered obsolete in ABAP Objects. New development should place reusable logic in methods of a class, and use function modules when a remote-enabled or system-wide interface is required.

Function Modules

Function Modules are general purpose ABAP/4 routines that anyone can use. Infact , there are a large number of standard function Modules available.

Function Modules are organized into Function Groups: Collections of logically related functions. A Function module always belongs to a Function Group.

Syntax-

FUNCTION <function module>

<Statements>

ENDFUNCTION.

Important information Associated with Function Module

  • Administration
  • Import/Changing/Export parameters.
  • Table Parameters/Exceptions.
  • Documentation
  • Source code – L<fgrp>U01 . <fgrp> is the Function Group
  • Global Data – L<fgrp>TOP .Global data for the function group- Accessible across function modules in the function group.
  • Main Program – SAPL<fgrp> . Contains the list of all the include files for that function group

Call a Function Module

To call a function module, use the CALL FUNCTION statement:

CALL FUNCTION <module>

[EXPORTING  f1 = a 1.... f n = a n]

[IMPORTING  f1 = a 1.... f n = a n]

[CHANGING   f1 = a 1.... f n = a n]

[TABLES     f1 = a 1.... f n = a n]

[EXCEPTIONS e1 = r 1.... e n = r n [ERROR_MESSAGE = r E]

[OTHERS = ro]].

Every function module lives inside a function group, so the next section explains how that container works.

Function Groups

Function groups are containers for function modules. Infact, there are a large number of standard Function Groups.
All of the function modules in a function group can access the global data of the group.

Like executable programs (type 1) and module pools (type M), function groups can contain screens, selection screens, and lists.

Points to Note

  • Function Groups cannot be executed.
  • The name of a function group can be up to 26 characters long.
  • When you create a function group or function module, the main program and include programs are generated automatically.
  • Function groups encapsulate data.

How to create a Function Group

  1. Goto Transaction SE80.
  2. Select Program in the DropDown.
  3. Write the name of the Function Group That you want to create. Generally User made Function groups start with “Z”. e.g. – <Z_FUNCTION_GROUP_NAME> . Hit Enter Key.
  4. Note that The TOP Include is create by default if the user checks the option of creating a TOP include.

How to create a Function Module

  1. Create a function Group (say “ZCAL”).
  2. Create a function module, set the attributes like (Function group, Application, Short Text and Process Type) and Save.
  3. Include file “LZCALU01” will have source code of first function module.
  4. Include file “LZCALTOP” will have global data.
  5. Main program “SAPLZCAL” contains
    • Global data Include file “LZCALTOP”
    • Function modules include file “LZCALUXX”
    • User defined Include files “LZCALF..”, “LZCALO..” and “LZCALI..”
  6. Define interface parameters and Exceptions
  7. Write the source code
  8. Activate Function Module
  9. Testing the Function Module – Single Test & Debugging
  10. Documenting and Releasing a Function Module

How to Choose the Right Modularization Technique

The four techniques overlap, so the decision depends on the scope of reuse and on whether a parameter interface is required.

Technique Scope of reuse Parameter interface Best used for
Macro One program, after the definition line Positional placeholders &1 to &9 Short repeated statements, long calculations, complex WRITE output
Include program Any program that names the include None Shared data declarations and shared source code
Subroutine (FORM) Local, or external with PERFORM … IN PROGRAM USING, CHANGING, TABLES Logic reused frequently inside one program
Function module Whole system, including remote calls IMPORTING, EXPORTING, CHANGING, TABLES, EXCEPTIONS Routines shared across applications and encapsulated in a function group

A short rule covers most cases: use a macro for shorthand inside one program, an include for shared declarations, a subroutine for local logic, and a function module whenever the routine must be callable from anywhere in the system. That is all to Modularity in ABAP.

FAQs

A macro is expanded at generation time and works only inside the program that defines it. A subroutine is a real procedure with a typed parameter interface that can also be called from another program with PERFORM.

A function module whose processing type is set to Remote-Enabled Module can be called from another SAP system or from an external application. Its parameters must be passed by value, and exceptions are handled as system failures.

A macro cannot be stepped through in the debugger, because it is expanded before generation. Move the logic into a subroutine or a method when line-by-line debugging is required, and keep macros limited to short statements.

AI code assistants inside ABAP development tools can draft a function module skeleton, its parameter interface, and its exceptions from a plain description. A developer still reviews the logic, activates the module, and tests it before transport.

AI tools scan a program, detect repeated blocks, and suggest where a subroutine, method, or function module should be extracted. The suggestion speeds up refactoring, although unit testing remains necessary to confirm identical behaviour.

Summarize this post with: