difference between includes,macros,subroutine,function module

[Former Member]

Hi all,

can anyone eloborate the difference between include program and a macro,

and also the difference between subroutine and function module.

Thanks,

[Former Member]

Hi See link below :

http://abapcode.blogspot.com/2007/05/modularization-techniques.html

Reward points if helpful.

Regards.

Srikanta Gope

[Former Member]

check...

http://abapcode.blogspot.com/2007/05/modularization-techniques.html

u will get the differences

[Former Member]

Function modules

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 ... [)] ... ] [CHANGING... [)] ... ].

...

ENDFORM.

subroutines cannot be nested. You should therefore place your subroutine definitions at the end of the program

Calling Subroutines

PERFORM... .

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 [EXCEPTIONS e1 = r 1.... e n = r n ].

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:

Message class ® SY-MSGID

Message type ® SY-MSGTY

Message number ® SY-MSGNO

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 SY-MSGV4.

[Former Member]

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.

The function group of the function module is loaded into an internal session of the context, and is retained. What this means is that, if repeated calls of function modules belonging to the same destination and the same function group are made, the global data of this function group can be accessed collectively. When functions are called in external systems, this behavior is simulated by the API of the RFC library. A connection and its context is retained until it is explicitly closed, or until the calling program is finished. To close a connection explicitly, the function module RFC_CONNECTION_CLOSE can be used, or the API functions RfcAbort and RfcClose.

Reward Points

[Former Member]

Here is the notes of differences bet. FM and Subroutines.

Hi Function modules are for modularization urpose. You can the Function Module in any program. That is available all over in the SAP system.

Where as subroutine is program specific. Once you create a subroutine in one program then you can use that in that program and related programs like includes in the program or you have to call the subroutine specifically using the main program name.

Finally subroutines are for program modularization. Not for generic use.

FM's are for generic use. Not program dependent.

FMs are mainly used when a routine is to be performed by many programs.

Subroutines (forms) are generally only executed within one program.

You can perform routines from other programs, but it's not often done.

both forms and FMs are reusable modularization units.

To distinguish we generally say that forms are used for internal modularization and

FMs are used for external modularization.

To decide on which to implement, consider whether you need the content to be used just for a limited program

or wheteher it can be called from many independent programs.

For the first purpose it is better to implement a form whereas for the second we implement an FM.

However, ABAP does not isolate the usage context.

That is; you can call a form from another program within whose code the form is not actually implemented.

However, this requires attention since the form may utilize global variables.

The same issue holds for FMs.

FMs are encapsulated in function groups and function groups may have global variables that can be globally

used by all FMs inside it.

-

---

A macro is not a program, but a kind of "subroutine" (similar to FORMs), here's an example:

• Macro Definition-------------------------------------------------*

• Application server File opening and reading.

DEFINE READ_DATASET_INPUT.

OPEN DATASET &1 FOR INPUT IN TEXT MODE.

IF SY-SUBRC NE 0.

PERFORM ERROR USING &3 SY-DATUM 'E' 'ZERRS' '101' &1

SPACE SPACE SPACE SPACE SPACE SPACE.

ELSE.

DO.

READ DATASET &1 INTO &2.

IF SY-SUBRC NE 0.

EXIT.

ELSE.

APPEND &2.

CLEAR &2.

ENDIF.

ENDDO.

ENDIF.

CLOSE DATASET &1.

END-OF-DEFINITION.

• You call it like this on the program:

READ_DATASET_INPUT P_FILE T_MAIN G_PROGRAM.

From help: "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."

For modularization purposes, it's preferable to use Forms of Function modules.

http://help.sap.com/saphelp_nw2004s/helpdata/en/9f/db972835c111d1829f0000e829fbfe/content.htm

An INCLUDE program is a non-executable program which generally has something complementary to the main program (for example type/data declarations or Form subroutines).

http://help.sap.com/saphelp_nw2004s/helpdata/en/9f/db973535c111d1829f0000e829fbfe/content.htm

Rewards,

Pavan

[Former Member]

hi ANIL

<b>INCLUDE PROGRAM</b>

<b>Rules</b>

1) Can’t run independently.

2) Must be called from another executable or include program.

3) Resolved before program generation

4) After generation program contains the source code of all include programs it use.

<b>Example.</b>

INCLUDE ZILX0004.

WRITE: / ‘User’, SY-UNAME,

/ ‘Date’, SY-DATUM.

PROGRAM ZRPM0001.

INCLUDE ZILX0004.

<b>MACROS </b>

<b>DEFINE … END-OF-DEFINITION</b>

<b>Basic Form DEFINE macro</b>

Define a section of source code that you can address using the name macro.

Source code must consist of complete ABAP statements.

Conclude a macro with END-OF-DEFINITION statement.

Parameters

Can use placeholders &N (where N = 1, 2, 3 ..9).

During generation of program &N is replaced with Nth current parameter.

Can call Macro from another macro but a macro can’t call itself.

<b>

Example.</b>

DATA: number1 TYPE I VALUE 1.

DEFINE increment.

ADD 1 to &1.

WRITE &1.

END-OF-DEFINITION.

Increment number1.

WRITE number1.

Output: 2 2

<b>SUBROUTINE</b>

<b>

Program modules which can be called from ABAP/4 programs.</b>

<b>Defining subroutines</b>

Block of code between FORM and ENDFORM

FORM <Subroutine> [<pass>].

<Statement block>.

ENDFORM.

<Subroutine> = Name of the subroutine

<pass> = Parameters being passed

<b>Types</b>

<b>Internal subroutine </b>

Subroutine defined in same program being called.

Can access all the data objects declared in the main ABAP/4 program.

<b>External subroutine </b>

Subroutine defined outside the program being called.

Need to use the <pass> option or declare data objects in common parts of memory

<b>Function Modules</b>

<b>Overview</b>

General purpose ABAP/4 routines that anyone can use.

Large Number of standard function Modules.

Organized into Function Groups: Collections of logically related functions.

A Function Module is always associated with a Function Group.

Transaction SE37.

Called Using “Call Function <function module>” in ABAP/4 program.

<b>Information Associated with Function Module</b>

Administration

Import/Changing/Export parameters.

Table Parameters/Exceptions.

Documentation

Source code – L<fgrp>U01

FUNCTION <function module>

<Statements>

ENDFUNCTION.

Global Data - L<fgrp>TOP

Global data for the function group- Accessible across function modules in the function group.

Main Program - SAPL<fgrp>

Contains the list of all the include files for that function group

<b>

Calling subroutines</b>

Can be written at the end of function module in source code.

Include program L<fgrp>F<xx> is used for subroutines across function modules.

Can call any number of external subroutines.

REGARDS

RAVISH

<b>plz dont forget to reward points if useful</b>

[Former Member]

hi,

go thru following thread

<b>difference between subroutine and function module</b>

<b>difference between include program and a macro</b>

<b>plz reward if useful</b>

Swati

[Former Member]

Modularization Techniques

All ABAP programs are modular in structure and made up of processing blocks. There are two

kinds of processing blocks, those that are called from outside a program by the ABAP runtime

system, and those that can be called by ABAP statements in ABAP programs.

Processing blocks that are called using the ABAP runtime system are:

• Event blocks

• Dialog modules

Processing blocks that are called from ABAP programs are:

• Subroutines

• Function modules

• Methods

The processing blocks that you call from ABAP programs are called procedures.

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.

Modularization makes ABAP programs easier to read and maintain, as well as avoiding

redundancy, increasing the reusability of source code, and encapsulating data.

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.

Source code modules help you to avoid repeatedly writing the same set of statements and to

make your programs easier to read and understand. They are not used to modularize tasks

and functions. You should use procedures for this purpose.

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 <macro>:

DEFINE <macro>.

<statements>

END-OF-DEFINITION.

Include Programs:

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. A special include is the TOP include of a program. If

you name it according to the naming convention, it is always included in program

navigation and in the syntax check.

Creating Your Own Include Programs:

If you create an include program yourself, you must assign it the type I in its program

attributes. You can also create or change an include program by double-clicking on the name

of the program after the INCLUDE statement in your ABAP program. If the program exists, the

ABAP Workbench navigates to it. If it does not exist, the system creates it for you.

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.

You must ensure that the statements of your include program fit logically into the source code

of the programs from which it is called. Choosing Check while editing an include program in

the ABAP Editor is normally not sufficient for this.

Procedures:

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.

You can call procedures either internally or externally. If you call procedures externally, it is

important that you understand how memory is organized in the R/3 System, how screens are

processed, and how interface work areas are used.

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.

Defining Subroutines:

A subroutine is a block of code introduced by FORM and concluded by ENDFORM.

FORM <subr> [USING ... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ]

[CHANGING... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ].

...

ENDFORM.

<subr> is the name of the subroutine. The optional additions USING and CHANGING define

the parameter interface. Like any other processing block, subroutines cannot be nested. You

should therefore place your subroutine definitions at the end of the program, especially for

executable programs (type 1). In this way, you eliminate the risk of accidentally ending an

event block in the wrong place by inserting a FORM...ENDFORM block.

Subroutines can access all of the global data in the program in which they are defined (main

program). You therefore do not need to define a parameter interface if you do not want to

change any data in the subroutine, or if very little data is involved.

FORM HEADER.

WRITE: / ’Program started by’, SY-UNAME,

/ ’on host’, SY-HOST, ’date:’, SY-DATUM, ’time:’, SY-UZEIT.

ULINE.

ENDFORM.

This example creates a subroutine called HEADER, which, like the example of an include

program, displays a list header.

However, if you want subroutines to perform complex operations on data without affecting the

global data in the program, you should define a parameter interface through which you can

pass exactly the data you need. In the interests of good programming style and encapsulation,

you should always use a parameter interface, at least when the subroutine changes data.

You call subroutines using the statement

PERFORM... [USING ... <pi>... ]

[CHANGING... <pi>... ].

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 allow you to encapsulate and reuse global functions in the R/3 System.

They are stored in a central library. The R/3 System contains a wide range of predefined

function modules that you can call from any ABAP program.

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. You can test

function modules without having to include them in a program using the Function Builder.

Function Groups:

Function groups are containers for function modules. You cannot execute a function group.

When you call a function module, the system loads the whole of its function group into the

internal session of the calling program.

Calling Function Modules in ABAP:

To call a function module, use the CALL FUNCTION statement:

CALL FUNCTION <module>

[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 <module> either as a literal or a variable.

Each interface parameter <fi> is explicitly assigned to an actual parameter <a i>. You can

assign a return value <r i> to each exception <e i>. The assignment always takes the form

<interface parameter> = <actual parameter>. 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 <e i > 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 <e i > is specified in the EXCEPTION option,

the calling program handles the exception by assigning <r i > to SY-SUBRC. <r i > 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:

Structure of the Subroutine:

The FORM-ENDFORM statement defines a subroutine. The basic structure of a subroutine is:

FORM <sbrtn> [<formal_param>].

<statement block>.

ENDFORM.

Where,

<sbrtn> is the name of the subroutine and

<formal_param> is the list of formal parameters. Formal parameters are optional.

Structure of the Subroutine:

Formal Parameters:

Parameters are data passed to and from the subroutine. The FORM statement defines formal

parameters when the subroutine is declared. Three keywords define the formal parameters:

TABLES, USING and CHANGING. These keywords correspond to passed tables, passed input

variables, and passed output variables, respectively.

The syntax is:

FORM <subrtn> [TABLES <for_tab1> <for_tab2> .]

[USING <for_inp1> <for_inp2> .]

[CHANGING <for_out1> <for_out2> .].

The precedence of formal parameters in the FORM statement is: TABLES, USING and

CHANGING.

These keywords correspond to passed tables, passed input variables, and passed output

variables, respectively.

Actual Parameters

The PERFORM statement calls the subroutine. If formal parameters declare the subroutine, the

PERFORM statement must also define these parameters as actual parameters. The sequence

of the actual parameters must be identical to that of the formal parameters in the FORM

statement.

The syntax of the PERFORM statement is:

PERFORM <subrtn> [TABLES <act_tab1> <act_tab2> .]

[USING < act_inp1> <act_inp2> .]

[CHANGING < act_out1> <act_out2> .].

Creating a Subroutine:

Using the Workbench tools, there are two ways to create a subroutine:

• Object Browser

• ABAP/4 Editor

From the Object Browser Initial screen, select the Program object radio button and click the

Edit button to create a subroutine. On the Program Objects screen select the Subroutine radio

button, enter the name of the subroutine and the name of the program in which you wish to

use the subroutine.

In the ABAP/4 Editor, write the PERFORM statement to call the subroutine. Do not declare the

subroutine. Double click the name of the subroutine in the PERFORM statement to create it.

The system will guide you as you create the subroutine.

Of course, you may always elect to simply write the FORM-ENDFORM statement in the ABAP/4

program code rather than using the Workbench tools.

Global and Local Data:

There are two ways you can declare data which is accessible to the subroutine: globally,

within the main program and locally, within a subroutine.

If you declare data globally using the DATA statement in the main program, then any internal

subroutine can access it. External subroutines cannot access this data unless it is declared as

Common Part.

Internal or external subroutines may also contain local data. This data is declared within the

subroutine itself, and is not available to the rest of the program.

LOCAL Statement:

Normally, when global data is processed within the subroutine, the changes to the data are

retained at the completion of the subroutine. You can change this default process by using the

LOCAL statement within the subroutine.

The syntax is: LOCAL <data>.

In this case, any change in the value of the field within the subroutine is not reflected in the

main program. When the program exits the subroutine, the global data contains its previous

value.

Special Subroutines:

A function module in the SAP R/3 system is a reusable subroutine commonly called from

several programs. Typically, subroutines increase program efficiency and are used to avoid

redundant code. The function library is the central repository where function modules are

stored together in function groups. A single function group contains logically related function

modules that perform similar tasks.

Advantage of a Function Group:

Besides logically grouping similar function modules, a function group offers other advantages.

While executing a function module, the SAP R/3 system loads the entire corresponding

function group into memory. This function group remains in memory throughout the execution

of the current task. It is not reloaded during successive calls to function modules of the same

function group. This process can significantly decrease the execution time of the application.

Creating a Function Group:

The name of a function group can have a maximum of four characters. The name of a userdefined

function group must start with either Y or Z.

Function Modules:

The name of a function module can have a maximum of 30 alphanumeric characters. The

name of a user-defined function module must begin with Y_ or Z_.

The Function Module:

There are six components of a function module:

1. administration (attributes and text description)

2. interface (import/export parameters and exceptions)

3. documentation (documentation maintenance)

4. source code (the ABAP/4 code in the body of the module)

5. global data (data definitions that may be used by all function modules in a function

group)

6. main program (the ABAP/4 global data definitions and all function modules of the

function group)

Function Module Interfaces:

Function module interfaces enable data communication between function modules and the

calling program. There are five types of interfaces in a function module: Import, Changing,

Export, Tables, and Exceptions. Each has corresponding parameters. The function module

interface is defined when the function module is created. Click on a parameter for more

information.

Attributes of Import/Export Interfaces:

When you define an interface for a function module, you specify attributes for the interface.

You have six attributes for Import parameters: import parameter, reference field, ref,

proposal, optional, and reference. Changing parameters have the same set of attributes as

Import parameters. Export parameters do not have proposal and optional attributes. Click the

attribute fields for more information about the attributes.

Attributes of Table/Exceptions Interface:

The attributes for the Table/Exceptions interface are defined in a similar manner to those of

the Import/Export interface. The attributes for table parameters are: Table parameters, Ref.

structure, Reference type, and Optional. The Exceptions parameter has only one attribute:

exception (name). Click on the attributes for more information.

Exception Handling:

You can call a function module from several programs. There may be an unpredictable event

or error in a function module pertaining to a calling program. SAP refers to these events as

exceptions, and provides exception-handling methods.

In handling exceptions, you declare Exception parameters while defining the function module.

Whenever an error occurs in the function module, you trigger the exception by using the

RAISE <exception parameter> statement. If you include the MESSAGE....RAISING statement,

you can also display a message to the user which specifies the error.

Program Structure of the Function Module:

The SAP R/3 system generates a template for the function module using the interfaces you

define while creating the module. The Interface parameters appear as comment lines in the

ABAP/4 source code of the module. The program structure begins with a FUNCTION statement

and ends with an ENDFUNCTION statement.

You write the declaration statements and the module code between the FUNCTION and

ENDFUNCTION statements.

Calling a Function Module:

You evoke a function module by coding the CALL FUNCTION statement. The syntax of the

CALL FUNCTION statement is:

CALL FUNCTION .<function_name>..

The ABAP/4 Editor Insert statement screen is used to obtain a template of the CALL FUNCTION

statement for a given function. This template provides all interface parameters for the

function. You must provide the program objects to be passed between your program and the

function. The Insert statement screen is accessed from the Edit -> Insert Statement menu

path or by the Pattern button.

Defining Function Module Parameters:

Communication between the program and the function module is done with parameters. There

are several types of parameter categories.

When you insert the CALL FUNCTION <function_Name> statement into the ABAP/4 program

by selecting the Edit -> Insert statement menu path, the appropriate parameter structure

unique to the particular function module is automatically generated with the statement. You

can then manually enter the variable names for each of the required parameters. There must

be a corresponding import parameter in the function module for every export parameter sent

by the calling program, and vice versa.

Handling Exceptions:

Within a function, errors are called exceptions. When an error condition occurs in the function,

it raises the appropriate exception. When a function raises an exception, the function ends. It

then passes the exception back to the calling program through the exception interface, which

assigns a unique SY-SUBRC value to each exception. The calling program checks SY-SUBRC

after the function call. If SY-SUBRC is not zero, then an exception occurred.

When you use EDIT -> INSERT to put the function call template in your program, the template

contains each exception defined for the function and maps each to a number beginning with

one and incrementing by one for each exception. Each number is the SY-SUBRC value

returned if that exception occurs. The last exception on the list is always OTHERS. OTHERS

applies, if the function raises an exception that you are not checking for in your program. This

can occur because an exception was added to the function after your program was written. For

example, if a function has 15 exceptions, but you only need to check two of them individually,

delete the ones you don’t need (leaving OTHERS). If a deleted exception occurs, the OTHERS

SY-SUBRC code will be returned.

regards,

srinivas

<b>*reward for useful answers*</b>