0% found this document useful (0 votes)
35 views31 pages

MODULARISATION

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
35 views31 pages

MODULARISATION

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31

MODULARISATION

 A modularization unit is like a shell into which you can put


code.It allows you to segregate a group of lines of codes
from the rest, and then execute them at a specific time.

Need of modularization
 Improve program structure
 Make the program easier to maintain and update
 Improve readability
 Reduce redundancy
 Allow for component reuse
Modules in an ABAP program
ABAP/4 offers three types of modularization units:

 Events
 Subroutines
 Functional Module
What is an event?

 An event is a tag that identifies the section of code. The


section of event begins with an event name and ends when
the next event name is encountered. Event names are
reserved words. You cannot create new events. You can
only use existing events.
Driver program
 A driver program is one that controls another program.
 SAP supplies driver program with the R/3 system.
 When you start your program, a driver program always starts first and controls your
program by calling events within it.
 The order of the execution of events is determined by the driver program.

 Driver Program Report ztx01


 1.Trigger Initialization initialization
 write: / ‘1’

 2.Show selection screen


 3.trigger Start-of-selection Start-of-selection
 write: / ‘1’
 4.trigger End-of-selection End-of-selection
• write: / ‘1’

 5.Show list
Category & Events

 Driver
 Initialization
 At selection-screen
 Start-of-selection
 Get
 End-of-selection
Category & Events

 Program events- triggered within


program first line of new page
– Top-of-page
last line of current page
– End-of-page
 User events- driven by user interface
– At line-selection
user double clicks on a report line
– At user-command
user clicks on command button or presses
– AT pf<nn> function key
Run-Time Events

 Initialization
– Processed before the presentation of the selection
screen
– Can be used to initialize values in the selection
screen
Run-Time Events

 At selection-screen
– Processing block is started after the user has
specified all the criteria in the selection screen
– If an error message is displayed from this processing
block the system displays the selection screen again
and all input fields can be changed
Run-Time Events

 Start-of-selection
– Processing block that is executed after processing the
selection screen and before accessing database tables
using a logical database
– Use this processing block to set the value of internal
fields
– All statements that are not attached to an event
keyword or in a subroutine are processed in this
event
END-OF-SELECTION :
This is the last of the events called by the runtime environment
to occur. It is triggered after all of the data has been read from
the logical database, and before the list processor is started
Control Level Statements

1. At new <f> - beginning of a group of lines with the


same contents in the field <f> and in the fields left
of <f>
2. At end of <f> - end of a group of lines with the
same contents in the field <f> and in the fields left
of <f>
3. At first – first line of internal table
4. At last – last line of internal table
Control Level Statements

If you have sorted an extract dataset by the fields <f1>,


<f2>, ..., the processing of the control levels should
be written between the other control statements as
follows:
Loop.
At first.... ENDAT.
AT NEW <f1>....... ENDAT.
AT NEW <f2>....... ENDAT.
...
<Single line processing without control statement>
...
at end of <f2>.... ENDAT.
AT END OF <f1>.... ENDAT.
At last..... ENDAT.
Endloop.
Leaving an event
 Exit
 Check
 Stop
• Check and exit leaves the current event and continues with the next
event before start of selection
• In start of selection and the events occur after it
Check leaves the current event and continues with the next event
Exit terminates the report and shows output list
A single exception exists;within top-of-page,exit behaves like check
Subroutines
 A subroutine is a reusable section of code.It is like a mini-
program that can be called from another point in your
program.Within it you can define variables,execute
statements,compute results, and write output.The name of
a subroutine cannot exceed 30 characters.
 Types of Subroutine
 Internal subroutines - source code is in the same
ABAP program as the calling procedure
 External subroutines - source code of external
subroutines is in an ABAP program other than the
calling procedure
Syntax for subroutines
FORM <subr> [<pass>]
<Statement block>
ENDFORM.
 <subr> - name of the subroutine
 [<pass>] - data passing specification

Internal subroutine:
 PERFORM <subr> [USING ... ... ] [CHANGING... ... ].

External subroutine
 PERFORM <subr> IN PROGRAM <prog>
Parameters
 Formal parameters - defined within FORM
 Actual parameter - specified with PERFORM
 Parameter types
– Input - used to pass data to subroutines
– Output - used to pass data from subroutines
– Input/output - pass data to & from subroutines
 Call by reference
 Call by value
Calling by reference

 During a subroutine call, only the address of the


actual parameter is transferred to the formal
parameters. The formal parameter has no memory
of its own, and we work with the field of the calling
program within the subroutine. If we change the
formal parameter, the field contents in the calling
program also changes.
Calling by value

 Calling by value: During a subroutine call, the formal


parameters are created as copies of the actual
parameters. The formal parameters have memory of
their own. Changes to the formal parameters have
no effect on the actual parameters.
Calling by value and result

 During a subroutine call, the formal parameters are


created as copies of the actual parameters. The
formal parameters have their own memory space.
Changes to the formal parameters are copied to the
actual parameters at the end of the subroutine.
Parameter passing
 Passing by reference
– USING or CHANGING
 USING for input parameters that are not changed
 CHANGING for output parameters that are changed
 Passing by value
– FORM <subr> … USING value(<fi>) …
Declaration
FORM <subr> [TABLES <formal table list>]
[USING <formal input list>]
[CHANGING <formal output list>]
ENDFORM.
PERFORM <subr> [TABLES <formal table list>]
[USING <formal input list>]
[CHANGING <formal output list>]
NOTE: no comma in parameters list
Functional modules

 Functions differ from subroutines in that they are self-


contained and do not belong to a specific program. ABAP
functions accept as input any number of input parameters,
return as output any number of output parameters, and
raise exceptions if an error condition occurs.
 Function modules can be
1.Tested by itself
2.Remote enabled
3.handle exceptions
4.They have to be maintained in a function group
 Functions are invoked in ABAP programs by means of the
CALL FUNCTION statement. A very important feature of
ABAP is the ability to call function modules in another
SAP system or in an external application using the Remote
Function Call mechanism. Function groups act as
containers for function modules that logically belong
together.
Interface
A function module's interface determines how you can use the
module from within your own program. It is important that you
understand a module's programming interface before you use
the module. There are five different interface parameters
1.Import
Values transferred from the calling program to the function
module. You cannot overwrite the contents of import parameters
at runtime.
2.Export
Values transferred from the function module back to the calling
program.
3.Changing
Values that act as import and export parameters
simultaneously. The original value of a changing
parameter is transferred from the calling program to
the function module. The function module can alter
the initial value and send it back to the calling
program
4.Tables
Internal tables that can be imported and exported. The internal
table's contents are transferred from the calling program to the
function module. The function module can alter the contents of
the internal table and then send it back to the calling program.
Tables are always passed by reference.
5.Exceptions
Error situations that can occur within the function module.
The calling program uses exceptions to find out if an error has
occurred in the function module. It can then react accordingly.
Calling functions
CALL FUNCTION <function_name>
[EXPORTINGf1=a1 …fn=an]
[IMPORTING f1=a1 … fn=an]
[CHANGING f1=a1 … fn=an]
[TABLES f1=a1 …fn=an]
[EXCEPTIONS e1=r1 … en=rn
[ERROR_MESSAGE = re]
[OTHERS = ro]].
Passing Parameters
The methods for passing parameters to functional modules
are very similar to those for passing parameters to external
subroutines

 Import and export parameters are passed by value


 Changed parameters are passed by value and result
 Internal tables are passed by reference.

You might also like