Entering content frame

Creating Function Modules Locate the document in its SAP Library structure

You can only create function modules and function groups using the Function Builder in the ABAP Workbench. For further information, refer to Structure linkCreating New Function Modules. This section uses an example to illustrate how a function module is created from the point of view of ABAP programming.

Example

We are going to create a function module READ_SPFLI_INTO_TABLE to read data for a specified airline from table SPFLI into an internal table, which it then passes back to the calling program.

Function Groups and Function Modules

Firstly, we create a new function group DEMO_SPFLI to hold the function module (see Structure linkCreating a Function Group). Then, we can create the new function module (see Structure linkCreating a Function Module).

Parameter Interface

You can specify the types of interface parameters in function modules in the same way as the parameter interfaces of subroutines. Since function modules can be used anywhere in the system, their interfaces can only contain references to data types that are declared system-wide. These are the elementary ABAP data types, the system-wide generic types, such as any table, and types defined in the ABAP Dictionary. You cannot use LIKE to refer to data types declared in the framework program.

The function module READ_SPFLI_INTO_TABLE requires an import parameter to restrict the selection to a single airline. To specify the type, we can refer to the key field CARRID of the database SPFLI:

This graphic is explained in the accompanying text

Under Ref. field/structure, you can enter a column of a database table, a component of a ABAP Dictionary structure, or a whole ABAP Dictionary structure. The import parameter ID is optional, and has a default value.

The following type specification would have the same effect:

This graphic is explained in the accompanying text

Ref. type can contain any generic or full data type that is recognized system-wide. Here, the parameter is defined with reference to the elementary ABAP Dictionary type (or data element) S_CARR_ID. This is the type used to define the field SPFLI-CARRID.

To pass data back to the calling program, the function module needs an export parameter with the type of an internal table. For this, we define a system-wide table type SPFLI_TAB with the line type SPFLI in the ABAP Dictionary.

This graphic is explained in the accompanying text

We can now use this data type to specify the type of the export parameter ITAB:

This graphic is explained in the accompanying text

The internal table is passed by value. Only internal tables that are passed using tables parameters can be passed exclusively by reference.

Exceptions

Our function module needs an exception that it can trigger if there are no entries in table SPFLI that meet the selection criterion. The exception NOT_FOUND serves this function:

This graphic is explained in the accompanying text

Source Code

Having defined the parameter interface and exceptions, we can now write the source code of our function module. To do this, choose Source code in the Function Builder. This opens the ABAP Editor for the include program LfgrpUxx (see Function Groups ). This is the include in which the function module is programmed:

This graphic is explained in the accompanying text

The function of the function module can be programmed between the FUNCTION and ENDFUNCTION statements. The definitions of the parameter interface and the exceptions is displayed here in comment lines. Its real coding is generated invisibly by the Function Builder.

Data in Function Modules

You can use the TYPES and DATA statements to create local data types and objects. The interface parameters also behave like local data objects. In addition, you can access all of the global data of the main program. This data is defined in the include program LfgrpTOP. To open this include, choose Goto Global data in the Function Builder. The global data behaves like the instance attributes of a class. The first time you call a function module in a particular function group, the data is loaded into memory. It can then be accessed and changed by all of the function modules in the group. The system retains the values until the next time a function module is called.

Calling Subroutines

You use subroutines for local program modularization. Function modules can also use this technique. The function module that they call are defined in the corresponding main program.

If you only want to call a subroutine from a single function module, it is best to define them in the same include program as the function module itself, directly after the ENDFUNCTION statement. These subroutines can be called from all function modules in the function group, but for clarity, they should only be called from the function module that precedes them.

If you want to define a subroutine that will be called from several different function modules, you can define a special include program for it with the name LfgrpFxx.

Raising Exceptions

There are two ABAP statements for raising exceptions. They can only be used in function modules:

RAISE except.

und

MESSAGE.....RAISING except.

The effect of these statements depends on whether the calling program handles the exception or not. The calling program handles an exception If the name of the except exception or OTHERS is specified after the EXCEPTION option of the CALL FUNCTION statement.

If the calling program does not handle the exception

         The RAISEstatement terminates the program and switches to debugging mode.

         The MESSAGE..... RAISING statement displays the specified message. Processing is continued in relation to the message type.

If the calling program handles the exception, both statements return control to the program. No values are transferred. The MESSAGE..... RAISING statement does not display a message. Instead, it fills the system fields sy-msgid, sy-msgty, sy-msgno , and SY-MSGV1 to SY-MSGV4.

Source Code of READ_SPFLI_INTO_TABLE

The entire source code of READ_SPFLI_INTO_TABLE looks like this:

FUNCTION read_spfli_into_table.

*"------------------------------------------------------------
*"*"Local Interface:
*"       IMPORTING
*"             VALUE(ID) LIKE  SPFLI-CARRID DEFAULT 'LH '
*"       EXPORTING
*"             VALUE(ITAB) TYPE  SPFLI_TAB
*"       EXCEPTIONS
*"              NOT_FOUND
*"------------------------------------------------------------

  SELECT * FROM spfli INTO TABLE itab WHERE carrid = id.

  IF sy-subrc NE 0.
    MESSAGE e007(at) RAISING not_found.

  ENDIF.

ENDFUNCTION.

The function module reads all of the data from the database table SPFLI where the key field CARRID is equal to the import parameter ID and places the entries that it finds into the internal table spfli_tab. If it cannot find any entries, the exception NOT_FOUND is triggered with MESSAGE ... RAISING. Otherwise, the table is passed to the caller as an exporting parameter.

Calling READ_SPFLI_INTO_TABLE

The following program calls the function module READ_SPFLI_INTO_TABLE:

REPORT demo_mod_tech_fb_read_spfli.

PARAMETERS carrier TYPE s_carr_id.

DATA: jtab TYPE spfli_tab,
      wa   LIKE LINE OF jtab.

CALL FUNCTION 'READ_SPFLI_INTO_TABLE'
     EXPORTING
          id        = carrier
     IMPORTING
          itab      = jtab
     EXCEPTIONS
          not_found = 1
          OTHERS    = 2.

CASE sy-subrc.
  WHEN 1.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno.

  WHEN 2.
    MESSAGE e702(at).

ENDCASE.

LOOP AT jtab INTO wa.
  WRITE: /  wa-carrid, wa-connid, wa-cityfrom, wa-cityto.
ENDLOOP.

The actual parameters carrier and jtab have the same data types as their corresponding interface parameters in the function module. The exception NOT_FOUND is handled in the program. It displays the same message that the function module would have displayed had it handled the error.

 

Leaving content frame