LESSON 6 INTERNAL PROGRAM MODULARIZATION

INTERNAL PROGRAM MODULARIZATION:

An ABAP program is a collection of processing blocks. A processing block is a passive section of program code that is processed sequentially when called.Processing blocks are the smallest units in ABAP. They cannot be split, which also means that they cannot be nested.

There are various kinds of ABAP processing blocks:

Event blocks are ABAP processing blocks that are called by the runtime system. Event blocks can logically belong to the executable program, to the selection screen, to the list or to the screen. This unit deals with event blocks that belong to the executable program. You can find information on event blocks that belong to the selection screen, the list or the screen in the units on user dialogs.

Subroutine processing is triggered by an ABAP statement. Parameters can be passed to

subroutines using an interface and subroutines can contain local variables.

Modules are special ABAP processing blocks for processing screens. Therefore modules are dealt with in the User Dialogs: Screens unit.

Memory areas are made available for all a program's global data objects when that program is started. Declarative ABAP statements are therefore not components of ABAP processing blocks but are collected from the overall source code using a search when the program is generated. The exceptions to this are local data objects in subroutines.

In all of the programs that we have seen so far in this course, there has only been one processing block in addition to the data declaration. In this case, there is no need to declare the processing block explicitly. However, in more complex programs, we will require several different processing blocks and will need to specify the type and name.

The program shown above is an example of event blocks. It contains an input value for a date on a selection screen. The default value is the date from the week before. This cannot be realized by a default value from the PARAMETERS statement, since a calculation is required. The DEFAULT addition to the PARAMETERS statement ensures that the data object is filled with the default value at the start of the program.

Default values can be literals or fields from the sy structure. The runtime system fills the sy-datum field with the current date at the start of the program. You can use the INITIALIZATION event block to change variables at runtime but before the standard selection screen is sent. START-OF-SELECTION is an event block for creating lists.

All global declarations are recognized as such by the system by the declarative ABAP key words that they use, and these form a logical processing block (regardless of where they are placed in the program code). When you generate the program, the system searches the entire program code for declarative statements. However, for the sake of clarity, you should place all declarative statements together at the beginning of your programs. The PARAMETERS statement is one of the declarative language elements. When the program is generated, a selection screen is also generate d along with the information on the elementary data object of the type specified.

The easiest events to understand are those for an executable program (type 1).

The ABAP runtime system calls event blocks in a sequence designed for generating and processing lists:

First, the INITIALIZATION event block is called

Then a selection screen is sent to the presentation server

After the user leaves the selection screen, START-OF-SELECTION is called

If the START-OF-SELECTION event block contains the ABAP statements WRITE, SKIP or ULINE, a list buffer is filled.

The list buffer is subsequently sent to the presentation server as a list.

Event blocks are processing blocks that are called by the ABAP runtime system. The sequence in which they are processed is determined by the runtime system.

In executable programs, there are different event blocks for the various tasks involved in creating lists.

In an ABAP program, an event block is introduced with an event key word. It ends when the next processing block starts. There is no ABAP statement that explicitly concludes an event block.

Event blocks are called by the ABAP runtime system. The order in which you arrange the event blocks in your program is irrelevant - the system always calls them in a particular order.

START-OF-SELECTION is the first event for generating a list. It is called by the ABAP runtime system as soon as you have pressed the execute button.

INITIALIZATION is an event that you can use if you need to set a large number of default values.

This event block allows you to set default values that can only be determined at runtime. In the above example, the date 'A week ago' is calculated and placed in data object pa_date. The ABAP runtime system then sends a selection screen to the presentation server containing the calculated value as a default. The value can, of course, still be changed by the user.

Subroutines are processing blocks with a defined interface that can be called from any processing block using the ABAP statement. Subroutines provide internal program encapsulation.

You can navigate from the program object list to the subroutines.

The where-used list for a subroutine displays all the program lines that call the subroutine.

Ideally, all you need to do to determine the functional scope of the subroutine is to examine the subroutine name, the interface and the comments. If the subroutine contains the functionality you require, then you need the following information to be able to call the subroutine:

Subroutine name

Interface parameters it accesses (read-only): the parameters are listed after the USING addition.

The type and sequence of the interface parameters is important.

Interface parameters it changes: the parameters are listed after the CHANGING addition. The type and sequence of the interface parameters is important.

When a subroutine is called, all the interface parameters have to be filled with values. A distinction is made between the following parameters:

After USING, the parameters that the subroutine only needs to read are listed.

After CHANGING, the parameters that are changed in the subroutine are listed.

If the subroutine is called from the ABAP processing block by a PERFORM statement, the system interrupts the processing block to process the subroutine sequentially. When the last line of the subroutine (ENDFORM.) is reached, the system carries processing after the PERFORM statement.

You can track runtime behavior in the debugging mode. This gives you various options:

You can go through the entire program, including the subroutine, line by line, using Single Step

You can go through a processing block line by line using Execute. Subroutines are then executed as a whole

You can leave single -step processing of a subroutine and return to the calling program using Return

The method used for calling the interface parameters is set in the subroutine interface. The

parameters can be called either by reference or by value.

Calling by reference: The address of the actual parameter is called. Within the subroutine, the variable is addressed using the formal parameter name. Changes have an immediate effect on the global variable. If only the formal parameter name is specified in the subroutine interface, then the parameter is called by reference.

Calling by value: When the subroutine is called, a local variant is created with the formal parameter name and the actual parameter value is copied to the formal parameter. There are two types of call by value:

Calling by value: the formal parameter is listed in the interface after the USING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter only affect the local copy, not the actual parameter.

Calling by value and result: the formal parameter is listed in the interface after the CHANGING clause with the addition VALUE( ). When the subroutine is called, the actual parameter is copied to the formal parameter. Changes made to the formal parameter initially only affect the local copy. When the ENDFORM statement is reached, the formal parameter value is copied back to the actual parameter.

The parameters in the interface are called formal parameters , and the parameters that you pass to the subroutine are called actual parameters .

You must have the same number of actual parameters as formal parameters. You cannot have optional parameters. Parameters are assigned in the sequence in which they are listed.

When you call a subroutine using PERFORM, the system checks whether the types of the actual parameters in the PERFORM statement are compatible with the formal parameters. Different kinds of checks are performed for different types:

Complete type checks:

TYPE D, F, I, T or . These types are fully specified. The system checks to see if the data type of the actual parameter is identical to the type of the formal parameter in its entirety.

Partial type checks of generic types

TYPE C, N, P or X. The system checks whether the actual parameter has the type C, N, P or X. The length of the parameter and the number of decimal places in the DECIMALS addition (type P) are passed from the actual parameter to the formal parameter.

TYPE all unspecified information from generic

Dictionary types is inherited by the formal parameter from an actual parameter.

The interface is defined in the FORM routine. USING and CHANGING in the PERFORM statement are purely documentary.