Modularization Techniques

In: Funtion Module| Modularization Techniques| RFC

Comment!

Processing blocks that are called from ABAP programs:

1. Subroutines
2. Function modules
3. Methods
Procedures
Procedures contain a set of statements, and are called from other ABAP programs.
The processing blocks that you call from ABAP programs are called procedures
You define procedures in ABAP programs. When the program is generated, they remain
as standalone modules. You can call procedures in the program in which they are defined,
or from external programs. Procedures have an interface for passing data, and can also
contain local data.
ABAP contains the following kinds of procedures:
Subroutines
Subroutines are principally for local modularization, that is, they are generally called from the
program in which they are defined. You can use subroutines to write functions that are used
repeatedly within a program. You can define subroutines in any ABAP program.
Function Modules
Function modules are for global modularization, that is, they are always called from a different
program. Function modules contain functions that are used in the same form by many different
programs. They are important in the R/3 System for encapsulating processing logic and making it
reusable. Function modules must be defined in a function group, and can be called from any
program.
Methods
Methods describe the functions and behavior of classes and their instances in ABAP Objects.
Methods must be defined in classes. When you call them, you must observe certain special rules
of object-oriented programming.

Subroutines
Subroutines are procedures that you can define in any ABAP program and also call from any
program. Subroutines are normally called internally, that is, they contain sections of code or
algorithms that are used frequently locally. If you want a function to be reusable throughout the
system, use a function module.
subroutine is a block of code introduced by FORM and concluded by ENDFORM.
FORM [USING ... [VALUE(][)] [TYPE LIKE ] ] [CHANGING... [VALUE(][)] [TYPE
LIKE ] ].

ENDFORM.
subroutines cannot be nested. You should therefore place your subroutine definitions at the end
of the program
Calling Subroutines
PERFORM [USING ... ... ] [CHANGING... ... ].
Subroutines can call other subroutines (nested calls) and may also call themselves (recursive
calls). Once a subroutine has finished running, the calling program carries on processing after the
PERFORM statement. You can use the USING and CHANGING additions to supply values to
the parameter interface of the subroutine.

Function Modules
Function modules are procedures that are defined in function groups (special ABAP programs
with type F) and can be called from any ABAP program. Function groups act as containers for
function modules that logically belong together.
Unlike subroutines, you do not define function modules in the source code of your program.
Instead, you use the Function Builder. The actual ABAP interface definition remains hidden from
the programmer. You can define the input parameters of a function module as optional. You can
also assign default values to them. Function modules also support exception handling. This
allows you to catch certain errors while the function module is running.
Function groups are containers for function modules. You cannot execute a function group.
When you call an function module, the system loads the whole of its function group into the
internal session of the calling program (if it has not already been loaded).
This is used by the system to create the components of the group (main program and
corresponding include programs). When you create a function group or function module in the
Function Builder , the main program and include programs are generated automatically.
The main program SAPL contains nothing but the INCLUDE statements for the following
include programs:

LTOP. This contains the FUNCTION-POOL statement (equivalent for a function group of the
REPORT or PROGRAM statement) and global data declarations for the entire function group.
LUXX. This contains further INCLUDE statements for the include programs
LU01, LU02, These includes contain the actual function modules.
The include programs LF01, LF02, can contain the coding of subroutines that can be called
with internal subroutine calls from all function modules of the group.
All of the function modules in a function group can access the global data of the group. For this
reason, you should place all function modules that use the same data in a single function group.
Function modules can have the following interface parameters:
Import parameters. These must be supplied with data when you call the function module,
unless they are flagged as optional. You cannot change them in the function module.
Export parameters. These pass data from the function module back to the calling program.
Export parameters are always optional. You do not have to receive them in your program.
Changing parameters. These must be supplied with data when you call the function module,
unless they are flagged as optional. They can be changed in the function module. The changed
values are then returned to the calling program.
Tables parameters. You use these to pass internal tables. They are treated like CHANGING
parameters. However, you can also pass internal tables with other parameters if you specify the
parameter type appropriately.
You can specify the types of the interface parameters, either by referring to ABAP Dictionary
types or elementary ABAP types. When you call a function module, you must ensure that the
actual parameter and the interface parameters are compatible.
Interface parameters are, by default, passed by value. However, they can also be passed by
reference. Tables parameters can only be passed by reference. You can assign default values to
optional importing and changing parameters. If an optional parameter is not passed in a function
module call, it either has an initial value, or is set to the default value.
Exceptions are used to handle errors that occur in function modules. The calling program checks
whether any errors have occurred and then takes action accordingly.
Calling Function Modules in ABAP
To call a function module, use the CALL FUNCTION statement:
CALL FUNCTION [EXPORTING f1 = a 1.... f n = a n] [IMPORTING f1 = a 1.... f n = a n]
[CHANGING f1 = a 1.... f n = a n] [TABLES f1 = a 1.... f n = a n] [EXCEPTIONS e1 = r 1.... e n
= r n [ERROR_MESSAGE = r E] [OTHERS = ro]].

You can specify the name of the function module either as a literal or a variable. Each interface
parameter is explicitly assigned to an actual parameter . You can assign a return value to each
exception . The assignment always takes the form = . The equals sign is not an assignment
operator in this context.
After EXPORTING, you must supply all non-optional import parameters with values
appropriate to their type. You can supply values to optional import parameters if you wish.
After IMPORTING, you can receive the export parameters from the function module by
assigning them to variables of the appropriate type.
After CHANGING or TABLES, you must supply values to all of the non-optional changing or
tables parameters. When the function module has finished running, the changed values are
passed back to the actual parameters. You can supply values to optional changing or tables
parameters if you wish.
You can use the EXCEPTIONS option to handle the exceptions of the function module. If an
exception is raised while the function module is running, the system terminates the function
module and does not pass any values from the function module to the program, except those that
were passed by reference. If is specified in the EXCEPTION option, the calling program handles
the exception by assigning to SY-SUBRC. must be a numeric literal.
If you specify of ERROR_MESSAGE in the exception list you can influence the message
handling of function modules. Normally, you should only call messages in function modules
using the MESSAGE RAISING statement. With ERROR_MESSAGE you can force the
system to treat messages that are called without the RAISING option in a function module as
follows:

Messages of classes S, I, and W are ignored (but written to the log in a background job).

Messages of classes E and A stop the function module as if the exception

ERROR_MESSAGE had occurred (SY-SUBRC is set to ).

If you specify OTHERS after EXCEPTIONS, the system assigns a single return code to all other
exceptions that you have not specified explicitly in the list.
You can use the same number for several exceptions.
You can trigger exceptions in the function module using either the RAISE or the MESSAGE
RAISING statement. If the calling program handles the exception, both statements return control
to the program. The MESSAGE .. RAISING statement does not display a message in this
case. Instead, it sets the following system fields:
1. Message class SY-MSGID
2. Message type SY-MSGTY

3. Message number SY-MSGNO

4. SY-MSGV1 to SY-MSGV4 (contents of fields to , included in a message).
You can use the system fields to trigger the message from the calling program.
Raising Exceptions
There are two ABAP statements for raising exceptions. They can only be used in function
modules:
RAISE .
and
MESSAGE.. RAISING .
The effect of these statements depends on whether the calling program handles the exception or
not. If the name of the exception or OTHERS occurs in the EXCEPTIONS addition of the CALL
FUNCTION statement, the exception is handled by the calling program.
If the calling program does not handle the exception

The RAISE statement terminates the program and switches to debugging mode.

The MESSAGE .. RAISING statement display the specified message. How the
processing continues depends on 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 SYMSGV4.

Remote Function Modules

To implement a remote function module in ABAP, perform the following steps:
1. Register the module as remotely callable in the RFC server system.
In the function module Administration screen (transaction code SE37), set the field Can be called
via REMOTE CALL. Registering a module as remote causes an RFC stub to be generated for it.
Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user
does not have to wait for their completion before continuing the calling dialog. There are three
characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:

When the caller starts an asynchronous RFC, the called server must be available to accept
the request.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to
the server.

Asynchronous RFCs allow the user to carry on an interactive dialog with the remote
system.

The calling program can receive results from the asynchronous RFC.

You can use asynchronous remote function calls whenever you need to establish communication
with a remote system, but do not want to wait for the functions result before continuing
processing. Asynchronous RFCs can also be sent to the same system. In this case, the system
opens a new session (or window) and allows you to switch back and forth between the calling
dialog and the called session.
To start a remote function call asynchronously, use the following syntax:
CALL FUNCTION RemoteFunction STARTING NEW TASK taskname
Destination
EXPORTING
TABLES
EXCEPTIONS
The following calling parameters are available:
TABLES
passes references to internal tables. All table parameters of the function module must contain
values.
EXPORTING
passes values of fields and field strings from the calling program to the function module. In the
function module, the correponding formal parameters are defined as import parameters.
EXCEPTIONS
see Using Pre-Defined Exceptions for RFC
RECEIVE RESULTS FROM FUNCTION func is used within a FORM routine to receive the
results of an asynchronous remote function call. The following receiving parameters are
available:
1. IMPORTING
2. TABLES
3. EXCEPTIONS

The addition KEEPING TASK prevents an asynchronous connection from being closed after
receiving the results of the processing. The relevant remote context (roll area) is kept for re-use
until the caller terminates the connection.
Call a transaction asynchronally and display it in an amodal window:
DATA: MSG_TEXT(80) TYPE C. Message text

* Asynchronous call to transaction SM59 ->

* Create a new session
CALL FUNCTION ABAP4_CALL_TRANSACTION STARTING NEW TASK TEST
DESTINATION NONE
EXPORTING
TCODE = SM59
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE MSG_TEXT
SYSTEM_FAILURE = 2 MESSAGE MSG_TEXT
IF SY-SUBRC NE 0.
WRITE: MSG_TEXT.
ELSE.
WRITE: O.K.
ENDIF.
You must not use IMPORTING when calling aRFCs.

Transactional Remote Function Calls

RfcInstallTransactionControlinstalls four functions to control transactional behaviour.
RFC_ON_CHECK_TIDis called when a local transaction is starting.
RfcCreateTransID Get a unique transaction-ID for calling an
ABAP function module using the transactional RFC Interface
RfcIndirectCall Call an ABAP function module using the
transactional RFC Interface
RFC_ON_COMMIT is called when a local transaction ends.
RFC_ON_CONFIRM_TID is called when a local transaction is
completed.
RFC_ON_ROLLBACK is called when a local transaction ends with
failure.
RFC_ONCALL

Transactional Remote Function Call

Theoretical Processing Flow of a Transactional RFC:

(1a) At the COMMIT WORK statement, function Remote is called as asynchronous RFC with
destination NONE.
(1b) Immediate response that function module can be called remotely.
(2a) Process the program.
(2b) Process the function module. Start the tRFC administration (database tables ARFCSSTATE
and ARFCSDATA), which plans the call of function module Remote in system SYS2 as batch
job.
As well as modularization in processing blocks, ABAP allows you to modularize source code by
placing ABAP statements either in local macros or global include programs.
INCLUDE AND MACROS:
When you modularize source code, you place a sequence of ABAP statements in a module. Then,
instead of placing all of the statements in your main program, you just call the module.
Include programs are global R/3 Repository objects. They are solely for modularizing source
code, and have no parameter interface.
They have the following functions:
Library: Include programs allow you to use the same source code in different programs. For
example, this can be useful if you have lengthy data declarations that you want to use in different
programs.
Order. Include programs allow you to manage complex programs in an orderly way. Function
groups and module pools use include programs to store parts of the program that belong together.
The ABAP Workbench supports you extensively when you create such complex programs by
creating the include programs automatically and by assigning them unique names.

Creating Your Own Include Programs

If you create an include program yourself, you must assign it the type I in its program attributes.
An include program cannot run independently, but must be built into other programs. Include
programs can contain other includes.
The only restrictions for writing the source code of include programs are:

Include programs cannot call themselves.

Include programs must contain complete statements.

The INCLUDE statement has the same effect as copying the source code of the include program
into the program. In the syntax check, the contents of the include program are also analyzed.
Include programs are not loaded at runtime, but are expanded when the program is generated.
Once the program has been generated, the load version contains static versions of all of its
includes. If you subsequently change an include program, the programs that use it are
automatically regenerated.
***INCLUDE STARTTXT.
WRITE: / Program started by, SY-UNAME,/ on host, SY-HOST, date:, SY-DATUM,
time:, SY-UZEIT.ULINE.
We can then include this program in any other ABAP program to display a standard list header.
PROGRAM SAPMZTST.INCLUDE STARTTXT.

This could produce the following output:

Program started by KELLERH
on host ds0025 date: 03/19/1998 time: 09:00:39

Macros
If you want to reuse the same set of statements more than once in a program, you can include
them in a macro. For example, this can be useful for long calculations or complex WRITE
statements. You can only use a macro within the program in which it is defined, and it can only
be called in lines of the program following its definition.
The following statement block defines a macro :
DEFINE .
END-OF-DEFINITION.

Macros do not belong to the definition part of the program. This means that the DEFINEENDOF-DEFINITION block is not interpreted before the processing blocks in the program. At the
same time, however, macros are not operational statements that are executed within a processing
block at runtime. When the program is generated, macro definitions are not taken into account at
the point at which they are defined
A macro definition inserts a form of shortcut at any point in a program and can be used at any
subsequent point in the program. As the programmer, you must ensure that the macro definition
occurs in the program before the macro itself is used. Particular care is required if you use both
macros and include programs, since not all include programs are included in the syntax check
(exception: TOP include).
To use a macro, use the following form:
[ ... ].
When the program is generated, the system replaces by the defined statements and each
placeholder &i by the parameter
. You can use macros within macros. However, a macro cannot call itself.
DATA: RESULT TYPE I,N1 TYPE I VALUE 5,N2 TYPE I VALUE 6.
DEFINE OPERATION. RESULT = &1 &2 &3.OUTPUT &1 &2 &3 RESULT.END-OFDEFINITION.
DEFINE OUTPUT. WRITE: / The result of &1 &2 &3 is, &4.END-OF-DEFINITION.
OPERATION 4 + 3.OPERATION 2 ** 7.OPERATION N2 N1.
The produces the following output:
The result of 4 + 3 is 7
The result of 2 ** 7 is 128
The result of N2 N1 is 1
Inserting the macro changes nothing in the generated form of the program.