ABAP Developmentintermediate

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

Key takeaway

Design 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.

Explanation

📌 KEY POINTS
✅ IMPORTING = input (read-only in the method), EXPORTING = output, CHANGING = in/out, RETURNING = one result usable in expressions.
✅ Default passing is by reference (fast, no copy); VALUE( ) passes a copy — required for RETURNING.
✅ OPTIONAL/DEFAULT make parameters optional; IS SUPPLIED tells you whether the caller passed one.
⚠️ EXPORTING by reference is not cleared automatically — initialize output parameters yourself.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 6–7 created classes. A good method interface makes the method easy to call correctly — and hard to misuse.

━━━━━━━━━━━━━━━━━━━━
▶ 1. PARAMETER KINDS

IMPORTING iv_carrid TYPE s_carr_id — input; cannot be changed inside the method (by reference).
EXPORTING et_flights TYPE ty_flights — output.
CHANGING ct_flights TYPE ty_flights — in and out.
RETURNING VALUE(rv_count) TYPE i — exactly one result, always by value; enables functional calls: IF lo->count( ) > 0.
RAISING zcx_flight_error — declared exceptions (not a parameter, but part of the interface).

━━━━━━━━━━━━━━━━━━━━
▶ 2. BY REFERENCE VS BY VALUE

Reference (default): no copy — efficient for large tables. IMPORTING by reference is protected against change.
VALUE( ): copy — safe but costs time for large data; required for RETURNING and RFC/update FMs.
⚠️ EXPORTING by reference: the target keeps its old content until you overwrite it — CLEAR outputs at the start (or use VALUE( ), which starts initial).

━━━━━━━━━━━━━━━━━━━━
▶ 3. OPTIONAL, DEFAULT, IS SUPPLIED
METHODS get_flights IMPORTING iv_carrid TYPE s_carr_id iv_max_rows TYPE i DEFAULT 100 iv_date TYPE s_date OPTIONAL.
IF iv_date IS SUPPLIED. … ENDIF.
Use sparingly — many optional parameters hide different behaviors; consider separate methods.

━━━━━━━━━━━━━━━━━━━━
▶ 4. TYPING

Concrete (TYPE s_carr_id, TYPE ty_flights) — syntax check catches mismatches; preferred.
Generic (TYPE any, TYPE ANY TABLE, TYPE data) — for truly generic utilities; needs field symbols/RTTI inside.

━━━━━━━━━━━━━━━━━━━━
▶ 5. DESIGN RULES

Prefer RETURNING for single results; keep EXPORTING for several outputs.
Few parameters (≤ 3–4); group related data in structures.
Avoid CHANGING unless the method genuinely modifies the caller's data.
Name by direction: iv_/it_/is_ input, ev_/et_/es_ output, cv_ changing, rv_ returning (or your team's convention).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
Run the code example: RETURNING in an expression, EXPORTING not cleared, DEFAULT and IS SUPPLIED behavior.

✅ CHECKPOINT: your method interfaces are clear, efficient and safe to call.

Code example

ABAP Code

REPORT zmod_part8. TYPES ty_flights TYPE STANDARD TABLE OF sflight. CLASS lcl_flights DEFINITION.  PUBLIC SECTION.    CLASS-METHODS read      IMPORTING iv_carrid   TYPE s_carr_id                iv_max_rows TYPE i DEFAULT 100          " optional with default                iv_from     TYPE s_date OPTIONAL          " optional, check IS SUPPLIED      EXPORTING et_flights  TYPE ty_flights.              " by reference: CLEAR it!    CLASS-METHODS count_full      IMPORTING it_flights     TYPE ty_flights            " by reference, read-only      RETURNING VALUE(rv_count) TYPE i.                   " by value, functional    CLASS-METHODS add_surcharge      IMPORTING iv_percent TYPE i      CHANGING  ct_flights TYPE ty_flights.               " modifies caller dataENDCLASS. CLASS lcl_flights IMPLEMENTATION.  METHOD read.    CLEAR et_flights.                                     " important for EXPORTING    IF iv_from IS SUPPLIED.      SELECT * FROM sflight INTO TABLE et_flights UP TO iv_max_rows ROWS        WHERE carrid = iv_carrid AND fldate >= iv_from.    ELSE.      SELECT * FROM sflight INTO TABLE et_flights UP TO iv_max_rows ROWS        WHERE carrid = iv_carrid.    ENDIF.  ENDMETHOD.   METHOD count_full.    DATA ls_f TYPE sflight.    LOOP AT it_flights INTO ls_f WHERE seatsocc >= seatsmax.      rv_count = rv_count + 1.    ENDLOOP.  ENDMETHOD.   METHOD add_surcharge.    FIELD-SYMBOLS <ls_f> TYPE sflight.    LOOP AT ct_flights ASSIGNING <ls_f>.      <ls_f>-price = <ls_f>-price * ( 100 + iv_percent ) / 100.    ENDLOOP.  ENDMETHOD.ENDCLASS. START-OF-SELECTION.  DATA lt_flights TYPE ty_flights.   lcl_flights=>read( EXPORTING iv_carrid = 'LH'                 " DEFAULT 100 rows                     IMPORTING et_flights = lt_flights ).  lcl_flights=>read( EXPORTING iv_carrid = 'LH' iv_from = sy-datum iv_max_rows = 20                     IMPORTING et_flights = lt_flights ).   IF lcl_flights=>count_full( lt_flights ) > 0.                  " RETURNING in expression    WRITE: / 'some flights are full'.  ENDIF.   lcl_flights=>add_surcharge( EXPORTING iv_percent = 5                              CHANGING  ct_flights = lt_flights ).

Real project scenario

A validation method had an EXPORTING table of error messages and didn't clear it. When called in a loop, errors from the previous document remained in the table, so valid documents were rejected with the previous document's errors.
Adding CLEAR at the beginning — and later changing the method to RETURNING a message table — fixed the bug. The team's review checklist now includes "EXPORTING parameters initialized?".

Common mistakes

Not clearing EXPORTING parameters.
Many OPTIONAL parameters instead of separate methods.
Using CHANGING for pure outputs.
VALUE( ) copies of large tables without need.
Generic typing where concrete types are possible.

Best practices

RETURNING for single results.
Concrete, dictionary-based typing.
Initialize outputs at the start of the method.
Few, well-named parameters; structures for groups.
Use IS SUPPLIED only when behavior genuinely differs.

Interview angle

Questions: "IMPORTING vs EXPORTING vs CHANGING vs RETURNING?", "Pass by reference vs value?", "What does IS SUPPLIED do?"
Strong answer: IMPORTING inputs (protected), EXPORTING outputs, CHANGING in/out, RETURNING one by-value result usable in expressions; reference passing avoids copies but EXPORTING references keep old content unless cleared; VALUE( ) copies; OPTIONAL/DEFAULT make parameters optional and IS SUPPLIED checks whether the caller passed them; prefer concrete typing.

Practice this lesson

Quick check

1. A method calculates exactly one value (a price). Which parameter kind makes it usable in expressions like IF calc( ) > 100?

2. What is the effect of IMPORTING VALUE(iv_qty) instead of IMPORTING iv_qty in a method?

3. When should you use a CHANGING parameter?

Interview questions

1. A pricing routine uses several global variables and CHANGING parameters, and nobody knows which values it changes. How do you clean up its interface?

Answer it in your own words first, then compare.

2. Report crashes because a FORM reads an uninitialised global variable. How do you prevent it?

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.