LESSON 10 REUSE COMPONENTS

REUSE COMPONENTS:

The R/3 System offers several techniques that you can use to make business logic available for reuse.

Function modules: can be called from any ABAP Program. Parameters are also passed to the interface. Function modules that belong together are combined to form function groups. Program logic and user dialogs can be encapsulated in function modules.

Objects: You can use the compatible extension "ABAP objects" to create objects at runtime, with reference to central classes.

BAPIs are methods of business objects, which are made available using the Business Object Repository (BOR).

Logical databases are data collection programs that can be coupled with executable programs. In a logical database, the data are transferred using logical hierarchy structures. Logical databases also make selection screens available and contain authorization checks.

A function group is an ABAP program with type F, which is a program created exclusively for containing function modules. Function modules are modular units with interfaces that can be called from any ABAP Program. Function modules that operate on the same objects are combined to form function groups.

Each function group can contain:


Data objects , which can be seen and changed by all the function modules in the group. These data objects remain active as long as the function group remains active.

Subroutines, which can be called by any of the function modules in the group.

Screens , which can be called by any of the function modules in the group.

Function modules are modular units with interfaces. The interface can contain the following elements:

Import parameters are parameters passed to the function module. In general, these are assigned standard ABAP Dictionary types. Import parameters can also be optional.

Export parameters are passed from the function module to the calling program. Export parameters are always optional and for that reason do not need to be accepted by the calling program.

Changing Parameters are passed to the function module and can be changed by it. The result is returned to the calling program after the function module has executed. Changing parameters can be optional.

Exceptions are used to intercept errors. If an error triggers an exception in a function module, the function module stops. You can assign exceptions to numbers in the calling program, which sets the system field SY-SUBRC to that value. This return code can then be handled by the program.

Each function module can contain local data objects and access global data objects belonging to its function group. All the subroutines and screens in the function group can be called by the function module.

The global data in the function group remain after the function module has been called. The function group remains active for as long as the calling program is active. Thus, if a function module is called that writes values to the global data, other function modules in the same function group can access this data when they are called by the program.

In many programs a standard dialog box appears after the user has chosen Cancel. This dialog box always contains the sentence: "Data will be lost." The two lines following it are context-specific, as is the title. The user can choose from one of two options - "Yes" or "No."

This dialog box is encapsulated in a function module.

You could avoid programming this dialog box, if you could find an existing function module with the following properties:

Import parameters for the title and the two variable text lines

An export parameter to record whether the user has chosen "Yes" or "No"

The ability to call a screen in the function group that displays the two variable text lines and the title, and contains the "Yes" and "No" buttons.

Scenario: You are creating a program in the Object Navigator and leave the Attributes screen. You want to know if it is encapsulated in reusable form.

1. First method: In the Debugger, set a breakpoint at CALL SCREEN. If successful, the actual processing block (subroutine, function module or event block) will be listed under ' CALLS' in the Debugging mode. You can then examine the call and the parameters passed to the interface.

2. Second method: In the Debugger, set a breakpoint at CALL FUNCTION. If successful, the actual processing block (subroutine, function module or event block) will be listed under ' CALLS' in the Debugging mode. You can then examine the call and the parameters passed to the interface.

3. Third method: Click a text field in the standatrd dialog box, then press F1 and choose Technical info. Navigate to the screen and display a where-used list for programs, then look at the function modules that use it.

4. Fourth method: In the Save dialog box, display the F1 help and then Technical info. Navigate to the screen, examine the flow logic and its modules.

5. Fifth method: In the component hierarchy, mark the component that you are interested in (in this case, Basis Services), select it, navigate to the Repository Information System, look under Programming -> Function Builder -> Function modules and select Only released.

Once you have found a function module, you must find out more about its interface.
Non-optional parameters in the function module must be passed in the CALL FUNCTION
statement. To find out how to handle the other parameters, refer to the function module documentation and the documentation on interface parameters.