FUNCTION MODULES AND GROUPS OF ABAP XXIV

FUNCTION MODULES AND GROUPS OF ABAP:


Function modules are more comfortable to use than subroutines, and have a wider range of uses. The following list, without claiming to be complete, details the essential role that function modules play in the ABAP Workbench:
Function modules ...

Are actively integrated in the ABAP Workbench. You create and manage them using the Function Builder.

Can have optional importing and changing parameters, to which you can assign default values.

Can trigger exceptions through which the return code field sy-subrc is filled.

Can be remote-enabled.

Can be executed asynchronously, allowing you to run parallel processes.

Can be enabled for updates.

Play an important role in the SAP enhancement concept.

In the Attributes of a function module, you specify its general adminstrative data and the processing type :

Remote-enabled function modules can be called asynchronously in the same system, and can also be called from other systems (not just R/3 Systems). To call a function module in another system, there must be a valid system connection.
(Communications Interfaces in ABAP).

Update function modules contain additional functions for bundling database changes. For further information, refer to the course BC414 (Programming Database Updates) and the online documentation.

When you exchange data with function modules, you can distinguish clearly between three kinds of parameters:

Importing parameters, which are received by the function module
Exporting parameters, which are returned by the function module
Changing parameters, which are both received and returned.

By default, all parameters are passed by reference. To avoid unwanted side effects, you can only change exporting and changing parameters in the function module. If you want to pass parameters by value , you must select the relevant option when you define the interface.

You can also declare importing and changing parameters as optional. You do not have to pass values to these parameters when you call the function module. Where possible, you should use this option when you add new parameters to function modules that are already in use. You can assign a default value to an optional parameter. If you do not pass a value of your own when you call the function module, the system then uses the default value instead. Export parameters are always optional.

You may specify the type of an elementary parameter. You must specify the type of a structured or table parameter. You can use either ABAP Dictionary types, ABAP Dictionary objects, predefined ABAP types (I, F, P, N, C, STRING, X, XSTRING, D, T) or user-defined types. Any type conflicts show up in the extended program check.
Tables parameters are obsolete for normal function modules, but have been retained to ensure compatibility for function modules with other execution modes.

When you save the interface, the system generates the statement framework together with the comment block that lists the interface parameters:
FUNCTION .
*"--------------
*" ...
*"--------------
...
ENDFUNCTION.


The comment block is updated automatically if you make changes to the function module later on. It means that you can always see the interface definition when you are coding the function module.

You program the statements exactly as you would in any other ABAP program in the ABAP Editor.

In the function module, you can create your own local types and data objects, and call subroutines or other function modules.

You can make a function module trigger exceptions .

To do this, you must first declare the exceptions in the interface definition, that is, assign each one a different name.

In the source code of your function module, you program the statements that trigger an exception under the required condition. At runtime, the function module is terminated when an exception is triggered.

The changes to exporting and changing parameters are the same as in subroutines. There are two statements that you can use to trigger an exception. In the forms given below, stands for the name of an exception that you declared in the interface. The system reacts differently according to whether or not the exception was listed in the function module call:

RAISE .

If the exception is listed in the calling program, the system returns control to it directly. If the exception is not listed, a runtime error occurs.

MESSAGE () RAISING .

If the exception is listed in the calling program, the statement has the same effect as RAISE . If it is not listed, the system sends message from message class with type , and no runtime error occurs.

Function modules differ from subroutines in that you must assume that they will be used by other programmers. For this reason, you should ensure that you complete the steps listed here.

Documentation (can be translated)

You should document both your parameters and exceptions with short texts (and long texts if necessary) and your entire function module. The system provides a text editor for you to do this, containing predefined sections for Functionality, Example Call, Hints, and Further Information.

Work list

When you change an active function module, it acquires the status active (revised). When you save it, another version is created with the status inactive . When you are working on a function module, you can switch between the inactive version and the last version that you activated. When you activate the inactive version, the previous active version is overwritten.

Function test

Once you have activated your function module, you can test it using the built-in test environment in the Function Builder. If an exception is triggered, the test environment displays it, along with any message that you may have specified for it. You can also switch into the Debugger and the Runtime Analysis tool. You can save test data and compare sets of results.

When you insert a function module call in your program, you should use the Pattern function. Then, you only need to enter the name of the function module (input help is available). The system then inserts the call and the exception handling (MESSAGE statement) into your program.

You assign parameters by name. The formal parameters are always on the left-hand side of the expressions:

Exporting parameters are passed by the program. If a parameter is optional, you do not need to pass it. Default values are displayed if they exist.

Importing parameters are received by the program. All importing parameters are optional.

Changing parameters are both passed and received. You do not have to list optional parameters.

Default values are displayed if they exist.
The system assigns a value to each exception, beginning at one, and continuing to number them sequentially in the order they are declared in the function module definition. You can assign a value to all other exceptions that you have not specifically listed using the special exception OTHERS.

If you list the exceptions and one is triggered in the function module, the corresponding value is placed in the return code field sy-subrc. If you did not list the exception in the function call, a runtime error or a message occurs, depending on the statement you used in the function module to trigger the exception.

When you create a function module, you must assign it to a function group. The function group is the main program in which a function module is embedded.
A function group is a program with type F, and is not executable . The entire function group is loaded in a program the first time that you call a function module that belongs to it.

The system also triggers the LOAD-OF-PROGRAM event for the function group.
The function group remains active in the background until the end of the calling program. It is therefore a suitable means of retaining data objects for the entire duration of a program. All of the function modules in a group can access the group's global data.

The same applies to screens. If you want to call one screen from several different programs, you must create it in a function group. You then create the ABAP data objects with the same names as the screen fields in the function group. The screen and data transport can now be controlled using the function modules in the group.


The implementation of the individual function modules is similar to the examples in the Internal Table Operations unit. To save space, we have only listed the ABAP coding that is relevant for the actual functions.

The types of the parameters and global data objects have been specified by referring to appropriate types in the ABAP Dictionary.

Screen 100 belongs to the function group. It is a container screen for list processing that is processed invisibly. It allows the user to display the current contents of the waiting list in a modal dialog box.

Forward navigation ensures that you always enter the correct object. Include programs are named automatically, and the relevant call statements are inserted automatically in the correct positions.

RELATED POSTS