ABAPBeginner
Modularization
Learn how to structure ABAP code using FORM routines, function modules, methods, includes, classes and reusable service design.
Overview
Learn how to structure ABAP code using FORM routines, function modules, methods, includes, classes and reusable service design.
Lessons in this topic
- Modularization Part 1: Why and How to Split ABAP ProgramsUnderstand 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.
- Modularization Part 2: FORM Routines — Legacy but Still ImportantRead and maintain FORM routines in existing programs: PERFORM and FORM, USING and CHANGING, pass by value vs reference, TABLES parameters, global data side effects — and how to refactor them safely.
- Modularization Part 3: FORM vs Method vs Function ModuleChoose the right unit: compare FORM routines, function modules and methods by scope, interface, reuse, remote capability, exceptions and testability — with a decision table for classic projects.
- Modularization Part 5: Update Function Modules and IN UPDATE TASKUnderstand SAP's classic update technique: logical units of work, update function modules (V1/V2), CALL FUNCTION … IN UPDATE TASK, COMMIT WORK and ROLLBACK WORK, PERFORM ON COMMIT, SM13 — and why RAP and BAPIs rely on it.
- Modularization Part 4: Function Modules and Function GroupsCreate and use function modules the classic way: function groups and their includes, the interface (IMPORTING, EXPORTING, CHANGING, TABLES, EXCEPTIONS), calling with CALL FUNCTION, handling sy-subrc, and RFC-enabled modules.
- Modularization Part 6: Methods and Local ClassesWrite your first classes for modularization: class definition and implementation, instance vs static methods, attributes, constructors, calling methods, and how a class replaces FORM-based report logic.
- Modularization Part 7: Global Classes vs Local ClassesDecide where a class belongs: local classes inside one program vs global classes in the class library (SE24/ADT) — reuse, visibility, testing, transport, naming, and how to promote a local class to a global one.
- Modularization Part 8: Parameter Passing — IMPORTING, EXPORTING, CHANGING and RETURNINGDesign method interfaces correctly: parameter kinds, pass by reference vs VALUE( ), OPTIONAL and DEFAULT, IS SUPPLIED, typing (generic vs concrete), and when RETURNING makes code clearer.
- Modularization Part 9: Reusable Service Class DesignDesign a reusable global service class for a business object: clear responsibility, small public interface, separation of data access and logic, exceptions, buffering, and how function modules, reports and BAdIs consume it.
- Modularization Part 10: Modularization for Unit Testing and Regression SafetyMake modular code testable: separate logic from database access through an interface, replace the DAO with a test double, and write ABAP Unit tests (FOR TESTING, setup, cl_abap_unit_assert) that protect you from regressions.
Interview questions covered
- Report crashes because a FORM reads an uninitialised global variable. How do you prevent it?
- How do you design a service layer for a large ABAP application?
- Difference between FORM and METHOD in ABAP.
- When would you use INCLUDE programs?
- What is the cost of many small function-module calls in a loop?
- How do you evolve a legacy function group into a service class without breaking callers?
- What is a Function Module and when is it required?
- Customer validation exists separately in three reports and one OData service. How do you move it into a class-based design?
- A customer validation rule was written as a local class in one report. Now two other programs need it. What do you do?
- The same delivery-block rule is coded separately in a report, a user exit and an OData service, and they now give different results. How do you fix this?
- Users get a success message after saving a sales-related custom document, but the record is sometimes missing in the database. What could be wrong with the update logic?
- A pricing routine uses several global variables and CHANGING parameters, and nobody knows which values it changes. How do you clean up its interface?
- A delivery user exit in MV50AFZ1 contains several FORM routines sharing global variables, and a change caused wrong values in another FORM. How do you work safely here?
- You need logic that a report uses, that an external system calls via RFC, and that runs in the update task. Would you use a FORM, a method or a function module?
- A 6,000-line SD report with everything in START-OF-SELECTION is hard to change. How do you restructure it into maintainable modules?
- A custom RFC-enabled function module is called by several external systems. What must you consider when changing it?
- A pricing rule was copied into five reports. A defect was fixed in one of them, and the others still produce wrong prices. How do you prevent this happening again?
- Where would you put business logic that must be reused by a report, a Fiori app and a BAPI?
- When should you use a subroutine (FORM), a function module, and a method?