Show TOC

 Understanding Function Module CodeLocate this document in the navigation structure

Naming Conventions

When you create a function group, the ABAP Workbench automatically generates a main program, global data, and source code. The system uses the format SAPL<FGRP> to name the main program where <FRGP> is the name of the function group. For each successive function module in the function group, the system automatically creates an include file and assigns it a name using the following format: L<FGRP>U<NN> .

Tip

In the function group FGRP , the first function module is stored in the include file LFGRPU01 . The subsequent function modules are stored in the include files LFGRPU02 , LFGRPU03 , LFGRPU04 , and so on.

Writing Function Modules

Once you have defined the interface of your function module, you can start writing the source code. In the Object Navigator (transaction SE80), open your function module and choose the Source Code tab page.

Note

The parameters and exceptions of the function module appear as commented lines.

A few features to bear in mind when writing function modules:

Data Handling in Function Modules
  • You do not declare export and import parameters in the source code of the function module. The system does this automatically, using an INCLUDE program that inserts a list of the parameters as commented lines in the source code.
  • You can declare local data types and objects in function modules in the same way you do that in subroutines. 
  • You can declare data using the TYPES and DATA statements in L<FRGP>TOP . This data is available to all of function modules in a function group. The system creates the data the first time a function module in the group is called. It always saves the values from the last function module that was called.
Calling Subroutines from Function Modules

You can call various subroutines from function modules.

  • You can write internal subroutines, placing them after the ENDFUNCTION statement.  These subroutines can be called from all function modules in the group. However, we recommend that you only call them from the function module in which you wrote the function module. This makes your function group easier to understand.
  • If you want to create internal subroutines and call them from all of the function modules in the function group <FGRP> , use the special INCLUDE programs L<FGRP>F<XX> .
  • You can call any external subroutines from a function module.
Triggering Exceptions

Within a function module, you can address all exceptions by using the names you have defined in the interface. Exceptions are handled either by the system or by the calling program. You define this when you call the function by assigning numeric values to the exceptions that you want to handle yourself. For more information, see Calling Function Modules From Your Programs .

There are two ABAP statements you can use to trigger exceptions:

RAISE <exception>.
MESSAGE..... RAISING <exception>.

The effect of these statements depends on whether you handle the exception in the calling program or let the system process it:

  • If you trigger the exception in the RAISE statement and the calling program has to handle it, the system terminates the processing of the function module and the numeric value assigned to the exception is placed in the system field SY-SUBRC . If the calling program fails to handle the exception, the system triggers a runtime error.
  • If you use the MESSAGE... RAISING statement and want the system to handle the exception, no runtime error is generated. The processing continues and the system displays a message with the defined type. To do this, you specify the MESSAGE-ID in the first statement of the include program L<FGRP>TOP . The MESSAGE... RAISING statement inserts values in the following system fields:
    • SY-MSGID (message ID)
    • SY-MSGTY (message type)
    • SY-MSGNO (message number)
    • SY-MSGV1 to SY-MSGV4 (contents of the fields <F1> to <F4> that are included in the message).

For more information, see the keyword documentation for the MESSAGE statement.

Tip

Suppose we have the following function module:

function my_divide  
*"-----------------------------------------------  
*"*"Local interface:  
*"         IMPORTING  
*"               VALUE(Z1) TYPE F  
*"               VALUE(M1) TYPE F  
*"         EXPORTING  
*"               VALUE(RES) TYPE F  
*"         EXCEPTIONS  
*"               DIV_ZERO  
*"------------------------------------------------   
if n1 eq 0.   
raise div_zero.   
else.   
res = z1 / n1.   
endif.  
endfunction. 

If N1 is not equal to zero, the module divides Z1 by N1 . Otherwise, it triggers the exception DIV_ZERO .

The MDTEST program calls the MY_DIVIDE function:

report mdtest.  
data: result type f.  
call function 'MY_DIVIDE'   
 exporting   
  z1 = 6   
  n1 = 4   
 importing   
  res = result   
 exceptions   
  div_zero = 1   
  others = 2.  
if sy-sybrc eq 0.   
 write: / 'Result =' , result.  
else.   
 write 'Division by zero'.  
endif. 

When you run the program, the output is: Result = 1,500000

If you replace N1 = 4 with N1 = 0 in the EXPORTING list, the program MDTEST processes the exception DIV_ZERO by assigning the value 1 to SY-SUBRC . The output is: Division by zero .

You can also use exception classes to raise exceptions. For that purpose, you must have selected the Exception classes indicator.

Tip
function fb_exception_test.  
*"---------------------------------------------------------  
*"*"Local Interface:  
*"  IMPORTING  
*"     REFERENCE(P1) TYPE  I  
*"     REFERENCE(P2) TYPE  I  
*"  EXPORTING  
*"     REFERENCE(P3) TYPE  I  
*"     VALUE(P4) TYPE  I  
*"  RAISING  
*"      CX_SY_ZERODIVIDE  
*"---------------------------------------------------------      
if p2 = 0.  
 raise exception type cx_sy_zerodivide.   
else.  
 p3 = p1 / p2.   
endif.     
endfunction.