RUN TIME ENVIRONMENT In SAP ABAP

RUN TIME ENVIRONMENT In SAP ABAP:


ABAP program contains the following components:

Source code ...

containing the ABAP statements

Screens ...


consist of the screen layout and associated flow logic . You normally create the layout of a screen using the Screen Painter. However, there are special kinds of screens, called selection screens and lists, whose layout and flow logic are designed exclusively using ABAP statements.

Interface

...contains all of the entries in the menus, the standard toolbar, the application toolbar, and function key settings. It contains titles and statuses. A status is a collection of function key settings and menus.

Text elements

... are language-specific. They can be translated either directly from the text element maintenance tool, or using a special translation tool.

Documentation

... is also language-specific. Always write documentation from the user's point of view. If you want to document the programming techniques you have used, use comments in the program code instead.

Variants

... allow you to predefine the values of input fields on the selection screen of a program.

ABAP is an event-driven programming language, and as such is suited to processing user dialogs.

The source code of an ABAP program consists of two parts:

Declarations

Declarations include the statements for global data types and objects, selection screens, and (in ABAP Objects) local classes and interfaces within the program.

Processing Blocks (indivisible program units)

Each processing block must be programmed as a single entity. There are two basic kinds of processing blocks:

Event Blocks :

Event blocks are introduced by an event keyword. They are not concluded explicitly, but end when the next processing block starts.
Dialog Modules and Procedures:

Dialog modules and procedures are introduced and concluded using keywords.

The contents of all processing blocks form the processing logic.

When you generate the program, these parts are compiled to form the load version. This is interpreted at runtime.

In the simplest case, your program will consist of a single source code unit that contains all of the relevant processing blocks. To make your programs easier to understand, and to increase the degree to which your programs can be reused, you should use include programs.

When you create a program from the Object Navigator, the system proposes to create a TOP include for the pro gram. This option is particularly useful when you create module pools.

When you create a processing block, the system always asks in which include program it should insert the relevant ABAP code.

If the include program does not exist, the system creates it and inserts an INCLUDE statement for it in the main program.

If you name your program according to the naming convention SAPM{Y|Z} and then create a new processing block, the system proposes the name of the new include using the following convention:

M{Y|Z}.

When you create further processing blocks, the system automatically proposes the appropriate include program.

In this way, the system helps you to create programs whose structures are easy to understand. The standardized naming convention will help you to find your way around other people's programs.

The R/3 System is based on a client/server architecture with the three tiers data base server, application server, and presentation server. It allows a large number of users with inexpensive and relatively slow machines to take advantage of a smaller number of faster, expensive application servers by occupying work processes on them.

Each work process on an application server is assigned to a work process on the (expensive, even more powerful) database server. User dispatching is the process by which the individual clients at presentation server level are assigned to a work process for a particular length of time. The work process in turn is linked to a work process in the database.

Once the user input from a dialog step has been processed, the user and program context is "rolled out" of the work process so that the work process can be used for another dialog step from another user while the first user is making entries on the next screen. This makes the best possible use of the resources available on the application server.

The three-tier architecture makes the system easily scalable . To add extra users, you merely have to install more inexpensive presentation servers. You can also increase the efficiency of the whole system by adding extra application servers with their associated work processes.

The work processes in the middle layer - often called the application server - are software components that are responsible for processing dialog steps. They are implemented as "virtual machines". This ensures that ABAP programs can run independently of the hardware platform on which the R/3 System is installed.
Work processes contain other software components that are responsible for various tasks within a dialog step:

Screen processor

The screen processor is responsib le for communication between the SAPgui and the work process (via the dispatcher). It processes the screen flow logic and passes field contents to the processing logic in the program.

ABAP processor

The ABAP processor executes the processing logic in the ABAP program and communicates with the database interface. The screen processor tells the ABAP processor which part of the program (module) needs to be processed (according to the screen flow logic).

Database interface

The database interface is responsib le for the communication with the database. It allows access to tables and Repository objects (including ABAP Dictionary objects), controls transaction execution (COMMIT and ROLLBACK), and administers the table buffer on the application server.

The individual processing blocks are called in a predetermined sequence at runtime, regardless of the position in which they occur in the program. Once a processing block has been called, the statements within it are processed seqeuentially.

Event block

If the system program or a user triggers an event for which the corresponding event block has been written in the processing logic, that event block is processed. The program flow is controlled either by the system or the user.

Modularization unit

When the system encounters a modularization unit call within a processing block, it calls the corresponding processing block. In this case, the program flow is controlled by the programmer.

Assigning transaction codes

To allow a module pool to be executed, you must assign a transaction code to it. You can (but do not have to) assign a transaction code to an executable (type 1) program.
You assign a dialog transaction to a module pool. The following steps occur when you run a dialog transaction:

First, the LOAD-OF-PROGRAM event is triggered. Once this event block has been executed, the ABAP processor passes control to the screen processor. For an example of how to use this new event, refer to the example in the Function Groups and Function Modules unit.

The screen processor processes the intial screen specified in the transaction definition. The initial screen can be a selection screen (regardless of the program type). The PROCESS BEFORE OUTPUT event is triggered and control passes to the ABAP processor, which processes the first PBO module.

The ABAP processor executes the processing block and returns control to the screen processor. Once all PBO modules have been processed, the contents of any ABAP fields with identically named corresponding fields on the screen are transported to the relevant screen fields. Then the screen is displayed (screen contents, active title, active status).

Once the user has chosen a dialog function (such as ENTER), the contents of the screen fields are transported back to the corresponding identically-named fields in the ABAP program, and the processing blocks that belong to the PROCESS AFTER INPUT event are processed. The system then continues by processing the next screen.

The only processing logic that is processed in a dialog transaction are the statements belonging to the LOAD-OF-PROGRAM event and those occurring in the various module s.

However, you can also use the statement LEAVE TO LIST-PROCESSING. This makes all of the list processing events available to you.

You can only assign a report transaction to an executable (type 1) program. In a report transaction, the system calls particular events in a fixed sequence, and calls a series of standard screens. The following steps occur when you run a report transaction:

First, the LOAD-OF-PROGRAM event is triggered.

Then the INITIALIZATION event is triggered.

Next, the standard selection screen is called (if you have declared one), and its corresponding events are triggered: AT SELECTION-SCREEN OUTPUT and AT SELECTION-SCREEN.

Next, the START-OF-SELECTION event is triggered. (This is the default event block. If you omit this event keyword, all statements that are not assigned to another processing block are treated as though they belong to it.)

If you have attached a logical database to your program, the system triggers the GET and GET LATE events.

Then the END-OF-SELECTION event is triggered.

You can also include screen processing (as in module pools) by using the CALL SCREEN statement. You can start executable (type 1) programs without using a transaction code. You can also run them in the background.

If you fill the list buffer of the basic list (using the WRITE, SKIP, and ULINE statements), two further events are triggered: At the beginning of each new page, the TOP-OF-PAGE event is triggered, and the END-OF-PAGE event is triggered at the end of each page.

Once the END-OF-SELECTION event block has been processed, interactive list processing starts.

The system displays the formatted basic list . The user can now trigger further events.

If the user double -clicks a line or triggers the function code PICK in some other way, the AT LINE-SELECTION event is triggered. In the standard list status, this function code is always assigned to function key . In turn, is always assigned for a mouse double -click.

If you fill the list buffer of the detail list (of which you may have up to twenty) using the WRITE, SKIP, and ULINE statements, two further events are triggered:
At the beginning of each new page, the TOP-OF-PAGE DURING LINE-SELECTION event is triggered, and the END-OF-PAGE DURING LINE-SELECTION event is triggered at the end of each page. (These events are not displayed in the graphic.) Interactive list processing is started again. The system displays the formatted detail list (screen 120).

Any other function codes that have not been "trapped" by the system trigger the eent AT USERCOMMAND. The following types of programs cannot be executed directly. Instead, they serve as containers for modularization units that you call from other programs. When you call one of these modularization units, the system always loads its entire container program.

Further information about this is provided later on in the course.

Function group (type F)

A function group can contain function modules, local data declarations for the program, and screens. For further information, refer to the Function Groups and Function Modules unit.

Include program (type I)

An include program can contain any ABAP statements.
For further information, refer to the Program Organization section of this unit.

Global interface (type J)

An interface pool can contain global interfaces and local data declarations.
For further information, refer to the Introduction to ABAP Objects unit.

Global class (type K)

A class pool can contain global classes and local data declarations.
For further information, refer to the Introduction to ABAP Objects unit.

Subroutine pool (type S) (external subroutines)

A subroutine pool can contain subroutines and local data declarations.
Caution! Type S programs are obsolete and have been replaced by function groups .