MODULARIZATION TECHNIQUES

SUBROUTINES
Re usable section of a code . Can be called by a program internally or externally . Written within FORM ENDFORM statement and called by PERFORM statement .

Syntax : form <form> [tables t1 t2 ] [using

c1 [value (c2)]] [changing c3 [value (c4)]]
All additions are options . Only form <form1> statement is mandatory . Additions , if present must be specified in the order mentioned above : tables first, then using and changing at last . Each addition is to be specified once only . No seperators are used between two parameters(except space) . Only internal tables can be passed by tables statement . A subroutine may call another subroutine or himself also .

How to Call Subroutines :

Syntax : perform <form> | <no> of <form1>

<form2> <form3> [tables t1 t2 .] [using c1 c2 ..] [changing c3 c4 .] <no> specifies the number of subroutine from subroutine list which is to be called .

Leaving Subroutines
oCheck oExit oStop

Check and exit statement leave the subroutine and control continues with the next executable statement following perform .
Stop statement leaves the subroutine and goes directly to the end-of-selection block .

Variables In Subroutine

Global

Local

Local

Data

Statics

Global data are accessible both from inside and outside the subroutine .
Local variables , local are accessible to other subroutines called by the subroutine .Local and data variables are generated and memory alloted to them when the subroutine generates and die down as the subroutine dies down .

For static , the memory alloted to it is retained even after the subroutine ends . The next time the subroutine is called , the memory for that variable becomes visible again and it will contain that value which was assigned to it the last time .
Static variable is visible to the subroutine itself , not within the subroutine which is called by the subroutine .

PASSING PARAMETERS TO SUBROUTINES

Variables declared in the FORM statement are formal parameters and those passed by the PERFORM statement are actual parameters . Number of formal and actual parameters should be the same and compatible .

Formal Parameters can be : Typed : Have data type following its name in the
FORM statement .

Untyped : Do not have any type statement . It

inherits the data type from the actual parameters .

Types of Variables That Can be Passed :

Any Elementary Datatype . Field Strings Internal Tables

Addition Method Significance

Using v1 Pass by Reference -DoChange in formal parameter changes actual parameter -Do-

Description
Passes a pointer to the original memory location -Do-

Changing v1

Using value(v1)

Pass by Value

Change in formal parameter does not change actual parameter

Change in formal parameter does affect actual parameter values only after the subroutine ends properly(not abruptly by stop or error message)

Allocates a new memory location for use within the subroutine , which is freed when the subroutine ends
Similar to pass by value , but the contents of the new memory is copied back into original memory before returning .

Changing value(v1)

Pass by Value & Result

USING and CHANGING have the same effect

Passing Field Strings

Field Strings are passed in the same way as of other variables . To access the components of a subroutine , one of the following additions are required :Like Y Structure Y Where Y is a field string or Data dictionary structure or table .

Passing Internal Tables

Internal tables can be passed to subroutines by either of the following ways :

Pass With Header Line : Passes both header and body of

internal table .
Pass Body Only : Passes only body of the internal table . IF an internal table without header line is passed with header line , then system automatically creates a header line for the internal table within the subroutine .

Different Syntaxes of Passing Internal Table

Method With Header Line Body only Body only Body only Body only Syntax Form <form1> tables <it> Form <form1> using it[] Way of Passing By reference . By reference

Form <form1> changing it[] By reference Form <form1> using value (it[]) Form <form1> changing value (it[]) By value By value and result

Making Components of Internal Table Known Within The Subroutine Method Syntax Valid Field For X

With Header line

Tables it structure X

With header line

Tables it like X

Without Header Line

Using it[] like X

Field string/DDIC structure/DDIC table/Internal table with header line Internal table without header line/internal table body(it[]) Internal table without header line/internal table body(it[])

Passing Internal table by reference

Output

Passing internal table with header line

Internal table without header line passed to subroutine as if it have a header line

Calling External Subroutines

Syntax : perform <form>(externalprogname>)[if found] Dynamic Specification : perform ( subrname ) in program ( progname ) if found When an external subroutine is called :External program containing the subroutine is loaded Entire external program is checked for syntax . Control transfers to external program , statement within the external subroutine is executed and endform transfers control back to the statement following the PERFORM statement in original program .

DISADVANTAGES
A global variable with same name in both programs , defined by Tables statement is common to both programs . A change to this variable in one program affects the other .

See program ysubrtndemo in development server for demo

INCLUDE
Syntax : include <includename> . Means of modularizing source code , with no parameter interface . Allows to use the same source code in different programs . Program attribute is I .

Macro
DEFINE <macro>.

<statements>
END-OF-DEFINITION.
Up to nine placeholders (&1, &2, ..., &9). .Macro should be defined before the point of its use in the program .

When the program is generated, macro definitions are not taken into account at the point at which they are defined. To use a macro :
<macro> [<p1> <p2> ... <p9>].

Example

I want to create a macro , which will draw a box surrounding the value of my variable . I will provide the value of the variable and approximate length of the box .
The name of my macro is write_subhendu and I pass some values to it for creating boxes by :write_subhendu : line1-tabname 10 , line1-ddtext 60 .

Now , let us see what is written in write_subhendu

data : x type i , y type i , l type i ,l1 type i ,l2 type i ,matnr type
i , cmatnr type c . DEFINE write_subhendu . x = sy-colno . y = sy-linno . skip 2 . l = &2 . l2 = strlen( &1 ) . position x . y = y - 1 . skip to line y . uline at x(l1) . y = y + 1 . position x . write : '|' , &1(l) , '|' . y = y + 1 . skip to line y . l1 = l + 4 .

skip to line y .

uline at x(l1) .
x = x + l1 - 1 . END-OF-DEFINITION

y = y - 1 .
position x . .

skip to line y .

Macro can take anything as placeholder :

Name of a variable Name of database table Name of database table column

Function Modules
Exist as an external program .
Enable parameter to be passed and returned , and parameters can be passed by value , by value and result and by reference . Leaving a function module is done by RAISE statement . Name should be a mimimum of three characters and maximum of 30 characters , and customer function modules should start with Y_ or Z_ ( the underscore is desirable , but not mandatory) .

Allows to encapsulate and reuse global functions in the R/3 System. Function modules also play an important role in database updates and in remote communications between R/3 Systems or between an R/3 System and a non-SAP system.

Function Group
Function Group is a program that contains function modules . It contains a four character identifier , called function group ID , which must begin with Y or Z for customer function groups . A function group containes :-

A main program ( saplsubh , where subh is the name of the function group) .
System places two includes within it automatically :o o include lsubhtop include lsubhuxx

Lsubhtop :- Top include , where global data( global to

all function modules within the group) are declared .

Lsubhuxx :- Cannot be modified . System automatically

place an include statement inside it for each function module created under the group .For first function module , it will be lsubhu01, for second , it will be lsubhu02 and so on .

Attributes of Function Module

Documentation Describes the purpose of the function module, lists the parameters for passing data to and from the module, and the exceptions. Informs how data can be passed to and from the function module, and which errors it handles.

Import parameters
Must be supplied with data when function module is called unless they are flagged as optional. They cannot be changed in the function module . Export parameters Pass data from the function module back to the calling program. Always optional .

Changing parameters Must be supplied with data when function module is called , unless they are flagged as optional. Can be changed in the function module and the changed values are then returned to the calling program. Tables parameters

Used to pass internal tables and treated like CHANGING parameters. However, internal tables can also be passed with other parameters if parameter type is specified appropriately .

The type of Interface Parameters(import , export, changing,tables) can be specified either by referring to ABAP Dictionary types or elementary ABAP types. Interface parameters are, by default, passed by value. They can also be passed by reference. Tables parameters can only be passed by reference. Default values can be assigned 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

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

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]].

After EXPORTING, export parameters can be received from the function module by assigning them to variables of the appropriate type. After IMPORTING, all non-optional import parameters must be supplied with values appropriate to their type. Values to optional import parameters may also be supplied . After CHANGING or TABLES, values to all of the nonoptional changing or tables parameters must be supplied. When the function module has finished running, the changed values are passed back to the actual parameters. Values to optional changing or tables parameters may be supplied. By tables parameters , internal table can be passed with header line .Others(exporting/importing/changing)passes body only .

EXCEPTIONS option is used 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 ERROR_MESSAGE is specified in the exception list the message handling of function modules can be influenced . With ERROR_MESSAGE one can ask 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 <r E >). If OTHERS is specified after EXCEPTIONS, the system assigns a single return code to all other exceptions that you have not specified explicitly in the list.

Using The message . . . Raising Statement

Syntax : message tnnn(cc) [ with v1 v2 ..] raising

xname

t is the message type(e,w,I,s,a,x) , nnn is the message no.,cc is the message class,c1 and v2 are the values to be inserted into the message text , xname is the name of the exception to be raised .
It sets the following system fields in caller program: Message class SY-MSGID Message type SY-MSGTY Message number SY-MSGNO SY-MSGV1 to SY-MSGV4 (contents of fields v1 to v4 included in a message).

For example on function module , refer to program : ysubfm1 in development server .

Click to get instructions with an example