ERPClimb logoERPClimb
Login
Modularization
ABAP Developmentbeginner

Modularization Part 1: Why and How to Split ABAP Programs

Key takeaway

Understand ABAP modularization units — includes, FORM routines, function modules, methods and classes — what each is for, and how to structure a classic report into clear, reusable pieces.

What this complete series covers

Learn Modularization in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of Modularization.
Prerequisites
Basic SAP navigation and ABAP syntax help. For hands-on practice, use an ABAP system with ADT or the relevant ABAP development tools.
Final outcome
By the end, you should be able to explain Modularization clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.
  1. Part 1: Modularization Part 1: Why and How to Split ABAP Programs

    Use INCLUDE programs to organize large classical ABAP sources, but recognize that includes are source-code structure rather than true encapsulation or reusable modular design.

  2. Part 2: Modularization Part 2: FORM Routines — Legacy but Still Important

    Maintain FORM routines safely in classic ABAP while keeping new reusable business logic in methods and classes, using procedural wrappers only where legacy programs or exits still require them.

  3. Part 3: Modularization Part 3: FORM vs Method vs Function Module

    Choose methods, function modules or legacy FORM routines based on reuse boundary, testability and compatibility, preferring OO methods for new application logic while preserving st

  4. Part 4: Modularization Part 5: Update Function Modules and IN UPDATE TASK

    Understand update function modules and the SAP LUW: IN UPDATE TASK registers work for execution at COMMIT WORK, so update logic must be transaction-safe, deterministic and independently monitorable.

  5. Part 5: Modularization Part 4: Function Modules and Function Groups

    Understand function modules as globally callable procedural interfaces hosted in function groups, with shared function-group state and special runtime capabilities such as RFC or u

  6. Part 6: Modularization Part 6: Methods and Local Classes

    Use classes and methods as the default modularization unit for new ABAP business logic because they provide encapsulation, interfaces, exceptions, dependency injection and straightforward unit testing.

  7. Part 7: Modularization Part 7: Global Classes vs Local Classes

    Use local classes for program-scoped helpers and global classes for reusable business or technical services, choosing the boundary from ownership, reuse, testability and lifecycle

  8. Part 8: Modularization Part 8: Parameter Passing — IMPORTING, EXPORTING, CHANGING and RETURNING

    Design ABAP method interfaces with clear input and output intent: use IMPORTING for inputs, RETURNING for one primary result, EXPORTING for additional outputs and CHANGING only for

  9. Part 9: Modularization Part 9: Reusable Service Class Design

    Design reusable ABAP service classes around one business capability with stable typed methods, explicit dependencies and no UI or selection-screen assumptions so the same logic can

  10. Part 10: Modularization Part 10: Modularization for Unit Testing and Regression Safety

    Structure ABAP business logic behind small deterministic methods and interfaces so ABAP Unit can verify critical rules quickly and protect enhancements from regression across reports, APIs and jobs.

System and release assumptions: Examples follow modern ABAP practices. Exact syntax, available APIs, and tools can vary by SAP release, so release-dependent points are called out where needed.

Explanation

📌 KEY POINTS
✅ Modularization = splitting code into named units with clear inputs and outputs.
✅ Source code units (includes, macros) only organize text; processing units (FORMs, function modules, methods) encapsulate logic.
✅ New code: methods in classes; FORMs and function modules still matter in existing programs, RFC and update tasks.
💡 A good unit does one thing, has a meaningful name and passes data via parameters — not via globals.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

  • Part 1 — why and how to split programs (this lesson)
  • Part 2 — FORM routines
  • Part 3 — FORM vs method vs function module
  • Part 4 — function modules and function groups
  • Part 5 — update function modules and IN UPDATE TASK
  • Part 6 — methods and classes
  • Part 7 — global vs local classes
  • Part 8 — parameter passing
  • Part 9 — reusable service classes
  • Part 10 — modularization for unit testing

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHY MODULARIZE

  • Readability: a 3,000-line START-OF-SELECTION is impossible to understand.
  • Reuse: the same logic (e.g. "calculate free seats") used in several places.
  • Testability: small units with parameters can be tested.
  • Change safety: a change in one unit doesn't break others.

━━━━━━━━━━━━━━━━━━━━
▶ 2. SOURCE CODE UNITS

  • Include programs (INCLUDE zflight_top.) — split a program into files: TOP (declarations), SEL (selection screen), F01 (FORMs), classes. No encapsulation — just text inserted.
  • Macros (DEFINE … END-OF-DEFINITION) — text replacement; hard to debug; avoid.

━━━━━━━━━━━━━━━━━━━━
▶ 3. PROCESSING UNITS

  • FORM routines — subroutines inside a program (PERFORM). Obsolete for new code, but everywhere in old reports and user exits.
  • Function modules — in function groups; callable across programs, remote-enabled (RFC/BAPI), update tasks.
  • Methods — in local or global classes; the modern standard.

━━━━━━━━━━━━━━━━━━━━
▶ 4. A TYPICAL CLASSIC REPORT STRUCTURE
ZFLIGHT_REPORT with INCLUDE zflight_report_top (global data, types), zflight_report_sel (selection screen), zflight_report_cls (local classes, or F01 with FORMs), and START-OF-SELECTION calling the main method. SE80 creates such includes automatically for module pools and function groups.

━━━━━━━━━━━━━━━━━━━━
▶ 5. RULES OF THUMB

  • Keep event blocks (START-OF-SELECTION, AT SELECTION-SCREEN) short — call units.
  • Pass data via parameters; minimize global data.
  • One unit = one responsibility.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
Compare the unstructured and structured versions in the code example — same output, very different maintainability.

✅ CHECKPOINT: you know the modularization units and when each is used.

Code example

ABAP Code
* ===== BEFORE: everything in one event block =====* START-OF-SELECTION.*   SELECT ... (50 lines)  checks ... (80 lines)  WRITE ... (60 lines) * ===== AFTER: structured report (main program) =====REPORT zflight_report. INCLUDE zflight_report_top.     " global types and data (keep small)INCLUDE zflight_report_sel.     " selection screenINCLUDE zflight_report_cls.     " local class with the logic START-OF-SELECTION.  lcl_report=>run( p_carr ).    " event block only calls the logic * ===== Include ZFLIGHT_REPORT_SEL =====* PARAMETERS p_carr TYPE s_carr_id OBLIGATORY. * ===== Include ZFLIGHT_REPORT_CLS =====* CLASS lcl_report DEFINITION.*   PUBLIC SECTION.*     CLASS-METHODS run IMPORTING iv_carr TYPE s_carr_id.*   PRIVATE SECTION.*     CLASS-METHODS read_flights IMPORTING iv_carr TYPE s_carr_id*                                EXPORTING et_flights TYPE ty_flights.*     CLASS-METHODS display IMPORTING it_flights TYPE ty_flights.* ENDCLASS.* CLASS lcl_report IMPLEMENTATION.*   METHOD run.*     DATA lt_flights TYPE ty_flights.*     read_flights( EXPORTING iv_carr = iv_carr IMPORTING et_flights = lt_flights ).*     display( lt_flights ).*   ENDMETHOD.*   METHOD read_flights.*     SELECT carrid connid fldate seatsocc seatsmax FROM sflight*       INTO TABLE et_flights WHERE carrid = iv_carr.*   ENDMETHOD.*   METHOD display.  " ALV or WRITE*   ENDMETHOD.* ENDCLASS. * ===== Classic equivalent you will meet in old programs =====* START-OF-SELECTION.*   PERFORM read_flights USING p_carr CHANGING gt_flights.*   PERFORM display USING gt_flights.

Real project scenario

A support team inherited a 5,000-line interface program written as one long START-OF-SELECTION with global variables. Every change took days because nobody could predict side effects, and two consecutive fixes broke other parts.
The team restructured it step by step into includes and a local class with methods per task (read, validate, map, send, log), passing data via parameters. The next changes were localized to one method each, and ABAP Unit tests covered the mapping logic.

Common mistakes

  • Huge event blocks without modularization.
  • Using includes as if they provided encapsulation.
  • Macros for logic.
  • Passing everything through global variables.
  • Creating new FORM routines in new development.

Best practices

  • Short event blocks that call units.
  • Methods in local/global classes for new code.
  • Includes only to organize large programs.
  • Parameters instead of globals.
  • One responsibility per unit with a descriptive name.

Interview angle

Questions: "What modularization techniques exist in ABAP?", "Difference between an include and a FORM?", "What do you use for new code?"
Strong answer: source code units (includes, macros) only organize text; processing units (FORM routines, function modules, methods) encapsulate logic with parameters; new code uses methods in classes, function modules remain for RFC/BAPI/update tasks, FORMs appear in legacy code and exits; keep event blocks short and avoid globals.

Practice this lesson

Quick check

1. A 6,000-line report is split into TOP, SEL and F01 includes. What has this achieved?

2. Which is the main benefit of modularizing an ABAP program into units with parameters?

3. In a classic report, which event block should mainly call the modules that read and process data?

Interview questions

1. When would you use INCLUDE programs?

Answer it in your own words first, then compare.

2. A 6,000-line SD report with everything in START-OF-SELECTION is hard to change. How do you restructure it into maintainable modules?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics