Modularization Part 4: Function Modules and Function Groups

📌 KEY POINTS
✅ A function module lives in a function group (SAPL<group>) that holds shared includes and global data.
✅ Interface: IMPORTING, EXPORTING, CHANGING, TABLES (obsolete for new), EXCEPTIONS (classic) or class-based exceptions.
✅ CALL FUNCTION 'NAME' … EXCEPTIONS … and always check sy-subrc.
💡 Use "Pattern" in SE38/ADT to insert the call with the full interface — no typos.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 explained when function modules are needed. This part shows how to build and call them.

━━━━━━━━━━━━━━━━━━━━
▶ 1. FUNCTION GROUPS

• Created in SE80 / SE37 (Goto → Function groups) or ADT.
• Main program SAPLZFLIGHT with includes: LZFLIGHTTOP (global data), LZFLIGHTUXX (function module includes, generated), LZFLIGHTF01 (FORMs/local classes).
• All FMs of the group share its global data — useful for buffering, dangerous for hidden state.
• The group is loaded at first call and stays in the internal session.\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 2. THE INTERFACE (SE37 tabs)\n• Import — inputs; mark optional/default values; pass by value for RFC.
• Export — outputs.
• Changing — in/out.
• Tables — obsolete (header lines); use table types in Import/Export instead.
• Exceptions — classic exception names (NOT_FOUND) raised with RAISE; or declare class-based exceptions.

━━━━━━━━━━━━━━━━━━━━
▶ 3. RAISING CLASSIC EXCEPTIONS
IF … . RAISE flight_not_found. ENDIF.

• The caller receives sy-subrc = assigned number.
• If the caller didn't list the exception (and no OTHERS), a runtime error occurs.
• MESSAGE … RAISING exc — sets the message fields and raises the exception.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CALLING
CALL FUNCTION 'Z_FLIGHT_GET' EXPORTING iv_carrid = … IMPORTING es_flight = … EXCEPTIONS flight_not_found = 1 OTHERS = 2.
IF sy-subrc <> 0. … ENDIF.
Parameter names from the FM's point of view: you EXPORT to its IMPORTING parameters.

━━━━━━━━━━━━━━━━━━━━
▶ 5. RFC-ENABLED MODULES
Attribute "Remote-Enabled Module": callable from other systems (CALL FUNCTION … DESTINATION 'RFC_DEST'). All parameters by value, no generic types. BAPIs are RFC FMs following special rules (BAPI topic).

━━━━━━━━━━━━━━━━━━━━
▶ 6. GOOD PRACTICE
Keep the FM thin: validate input, call a class method, map results/exceptions. Document parameters. Test in SE37 (F8) with test data directories.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Create function group ZFLIGHT and FM Z_FLIGHT_GET (code example).
2. Test it in SE37 with F8.
3. Call it from a report with Pattern and handle sy-subrc.

✅ CHECKPOINT: you can create, test and call function modules correctly.

A report called a function module without listing its exceptions. When a flight was missing, the FM raised FLIGHT_NOT_FOUND, and — because the caller had no EXCEPTIONS clause — the job dumped with RAISE_EXCEPTION in the middle of the night.
Adding the EXCEPTIONS block with OTHERS and sy-subrc handling turned the dump into a logged message and let the job continue with the next flight. The team now always inserts FM calls via Pattern.

• Calling FMs without EXCEPTIONS and OTHERS.
• Not checking sy-subrc after CALL FUNCTION.
• Using TABLES parameters in new FMs.
• Business logic and hidden state in function group globals.
• Typos in parameter names instead of using Pattern.

• Insert calls with Pattern.
• List all exceptions plus OTHERS; handle sy-subrc.
• Use table types instead of TABLES.
• Keep FMs thin; delegate to classes.
• For RFC, handle SYSTEM_FAILURE and COMMUNICATION_FAILURE.

Questions: "What is a function group?", "How do classic exceptions in FMs work?", "What is an RFC-enabled FM?"
Strong answer: a function group is the container program (SAPL…) with includes and shared global data for its FMs; FMs have IMPORTING/EXPORTING/CHANGING/TABLES/EXCEPTIONS; exceptions are raised with RAISE or MESSAGE … RAISING and appear as sy-subrc if listed in the call, otherwise a dump; RFC-enabled FMs can be called remotely via DESTINATION with by-value parameters and communication/system failure handling.