Modularization Techniques

Presentation Overview
 Objectives
 Learn different ways of modularizing code in ABAP programs.
 Learn creation and usage of Subroutines.
 Learn creation and usage of function modules.
 Pre-Requisites
 Knowledge of ABAP data dictionary
 Knowledge of internal tables.
 Knowledge of Simple ABAP program.
 Contents
 Modularization – Need and Techniques
 Macros
 Include Programs.
 Subroutines.
 Function Modules.
 Function Groups
 Modularization
 Need of Modularization
 Improve the structure of the program.
 Easy to read the code
 Easy to maintain the code
 Avoid redundancy
 Modularization Techniques
 Use of Macros
 Use of includes
 Subroutines
 Function Modules
 Methods ( OOPS)
What is Modularization?

PERFORM COLLECT_DATA
for personal information

FORM PERFORM COLLECT_DATA

for official information
COLLECT data from the
respective tables.
ENDFORM

PERFORM COLLECT_DATA
for general information

• A Common functionality is performed multiple times can be

performed once and called many times.
Detailed design
• The detailed design (in form of Flow chart) for the case study will look as follows

Call Module 1 to write

Selection screen a standard report Module 1 – Standard Header
header

Validate Selection Module 2

screen Loop at itab_oso
Get Partner Nos
from VBPA
Get all Open Orders
from VBAK and Call Module 2 to get
VBUK and store in Call Module3 to get
partner details Partner Names
itab_oso

Write Order details

Get Description of
sales order status Module 3 – Get Partner Name
from DD07T table from KNA1
Endloop

Call Module 4 to Module 4 – Standard Footer

write standard footer

In the next unit we will see how these modules can be implemented in ABAP
System Demo

Now the Modularization types are selected for all the modules.
Call Module 1 to write
Selection screen Module 1 – Standard Header
a standard report
header

Validate Selection Module 2

screen Loop at itab_oso
Get Partner Nos
from VBPA
Get all Open Orders
from VBAK and Call Module 2 to get
VBUK and store in Call Module3 to get
partner details
itab_oso Partner Names

Write Order details

Get Description of
sales order status Module 3 – Get Partner Name
from DD07T table from KNA1
Endloop

Call Module 4 to Module 4 – Standard Footer

write standard footer
 Macros - DEFINITION
 Why Do we need this?
Basically there will be certain processing which often gets called in the
program and these usually deal with Static data in calculations. Apart from this
there will be no much of logic that will be used. This can be achieved using
Definitions.
 DEFINE … END-OF-DEFINITION
 Basic Form DEFINE macro

 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.
 Example of a DEFINITION.
 Example.

DATA: number1 TYPE I VALUE 1.

DEFINE increment.
ADD 1 to &1.
WRITE &1.
END-OF-DEFINITION.
Increment number1.
WRITE number1.

Output: 2 2
 Include Programs
 These are TYPE ‘I’ Programs created using the transaction
SE38.

 Include <include program Name>

 Same sequence of statements in several programs ex: Lengthy data
declarations.

 Rules
 Can’t run independently.
 Must be called from another executable or include program.
 Resolved before program generation
 After generation, program contains the source code of all include
programs it use.
 Example – For an Include File
 Example.
REPORT ZTEST_PROGRAM.
INCLUDE ZILX0004.

PERFORM Print_Header. “The code and declarations for this

perform will be present in the above include file.
WRITE: / ‘User’, SY-UNAME,
/ ‘Date’, SY-DATUM.

PROGRAM ZRPM0001.
INCLUDE ZILX0004.
 Subroutines
Program modules which can be called from ABAP/4 programs.
 Defining subroutines
 Block of code between FORM and ENDFORM
FORM <Subroutine> [<pass>].
<Statement block>.
ENDFORM.
<Subroutine> = Name of the subroutine
<pass> = Parameters being passed

 Types
 Internal
 Subroutine defined in same program being called.
 Can access all the data objects declared in the main ABAP/4 program.
 External
 Subroutine defined outside the program being called.
 Need to use the <pass> option or declare data objects in common parts of memory.
 Subroutines
 Calling Subroutines
 Internal Subroutines
 PERFORM <subroutine> [<pass>]
<subroutine> = Name of the subroutine
<pass> = Parameters being passed
 Data declared in main program is automatically available.
 External Subroutines
 PERFORM <subroutine>(<Program>) [<pass>].
 PERFORM <subroutine> (<Program>) [<pass>] [IF FOUND].
 PERFORM (<subroutine>) IN PROGRAM (<Program>) [<pass>] [IF FOUND].
 PERFORM <index> OF <subroutine1> <subroutine2> <subroutine3> [<pass>].
 Up to 256 subroutines are possible.
 BY making use of COMMON PART with the DATA statement.
 By passing parameters.
 Subroutines
 Passing Data by Parameters
 Formal Parameters
 Parameters that are used in FORM statement
 Actual Parameters
 Parameters that are used in PERFORM statement
 Input parameters
 Output parameters
 Input/Output parameters
FORM <subroutine> [TABLES <formal table list>]
[USING <formal input list>]
[CHANGING <formal output list>]
PERFORM <subroutine> [(<program>)] [TABLES <actual table list>]
[USING <actual input list>]
[CHANGING <actual output list>]
 Options TABLES, USING and CHANGING must be in same sequence.

Subroutines
Passing Data by Parameters
 Calling by Reference
 Address of the actual parameter is transferred to formal parameter.
 Formal parameter has no memory of it’s own.
 Change in formal parameter reflects in the calling program.
 Calling by Value
 Formal parameters are created as copies of the actual parameters.
 Formal parameters have memory of their own.
 Calling by Value and Result
 Formal parameters are created as copies of the actual parameters.
 Formal parameters have memory of their own.
 Change in formal parameters are copied to the actual parameters at the end of subroutine.

 Internal tables that are passed by tables are always called by reference.
 For calling by reference, USING and CHANGING are equivalent.
 Passing by Reference
 Passing by Value
 Passing by Value and Result.
 Function Groups
 Overview
 General purpose ABAP/4 routines that anyone can use.
 Large Number of standard function Groups.
 Transaction SE80.

 Information Associated with Function Group

 Function groups are containers for function modules.
 Function Groups cannot be executed.
 The name of a function group can be up to 26 characters long.
 When you create a function group or function module, the main program and include
programs are generated automatically.
 Function groups encapsulate data.
 All of the function modules in a function group can access the global data of the group.
 Like executable programs (type 1) and module pools (type M), function groups can contain
screens, selection screens, and lists.
 Function Groups
 How To Create a Function Group?

 Goto Transaction SE80.

 Select Program in the Drop-Down.

 Write the name of the Function Group That you want to create. Generally User made Function
groups start with “Z”.

e.g. – Z_FUNCTION_GROUP_NAME

 Note that The TOP Include is create by default if the user checks the option of creating a TOP
include.
 Overview
Function Modules
 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.
 Information Associated with Function Module
 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
 Function Modules
 Calling subroutines
 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.
 Raising Exceptions
 RAISE <exception>
 Message … RAISING <exception>

 Calling program handles the exception.

 SY-MSGID
 SY-MSGTY
 SY-MSGNO
 SY-MSGV1 to SY-MSGV4
 If the system handles the exception
 RAISE statement terminates the program and switches to debugging mode.
 MESSAGE - RAISING displays a message and continues to according to message type.

Function Modules
Building New function Module
 Create a function Group (ZCAL).
 Create a function module, set the attributes and Save.
 Function group, Application, Short Text and Process Type
 Include file “LZCALU01” will have source code of first function module.
 Include file “LZCALTOP” will have global data.
 Main program “SAPLZCAL” contains
 Global data Include file “LZCALTOP”
 Function modules include file “LZCALUXX”
 User defined Include files “LZCALF..”, “LZCALO..” and “LZCALI..”
 Define interface parameters and Exceptions
 Write the source code
 Activate Function Module
 Testing the Function Module
 Single Test & Debugging
 Documenting and Releasing a Function Module
 Messages: How to define it in a program?
 Message classes are maintained in the transaction SE91.

 Prefix of the message specifies the message type eg. E for error message. It is
followed by the message number given in SE91 for that message class.

 Using ‘&’ we can include a max. of 4 variables in message text.

 Message i001 with var1 var2. “Here Var1 & Var2 will take &1 and &2 in
Msg class
 Message ‘This is Correct’ TYPE ‘I’. “For these messages no need of Msg
class.
 Message i000(abc). “Here abc is the Message Class

 Message-id can be specified at

1. REPORT ZTEST_PRG MESSAGE-ID XXX. “That is the starting of the

Program. Here XXX is nothing but the Message class created in SE91
2. MESSAGE E001(XXX). “This can be used at any place in the program,
here also XXX is the Message class created in SE91
 Different types of messages – The Prefix of the
Message.
 A : abnormal end – terminates the program and displays text message on screen.
Transaction must be restarted

 X – Exit Like A but with short dump MESSAGE_TYPE_X

 E : error – interrupts flow of control in PAI , enables user to enter new data , PAI is
processed again, user must correct entry

 W : warning – If entry is changed then like E, if enter is pressed without changing

then processing proceeds like I.

 I : information – no interrupt in flow control

 S : success – same as informational but message displayed on next screen