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.

LESSON 5 DATA BASE DIALOG

Database tables are administered in the ABAP Dictionary. There you can find current information about a database table's technical attributes. Database tables that have been created in the database using the same line type and name are called transparent tables in the ABAP Dictionary.

There are a couple of different ways in which you can navigate to transparent tables in the ABAP Dictionary:

Choose Tools->ABAP Workbench->Development->Dictionary to call the ABAP Dictionary directly and insert the name of the transparent table in the appropriate input field, or

Navigate directly to the ABAP Dictionary from the ABAP Editor while editing the program: This can be done by double -clicking on the name of the transparent table in the FROM clause of the SELECT statement.

You can search for database tables in several different ways:

Application hierarchy and the Repository Information System: You may choose application components from the application hierarchy and branch directly to the information system. There you can search for database tables according to their short texts (among other criteria).

If you have the name of a program that accesses the database table:

Input field on a screen; If you know of a program that contains a screen with input fields connected to the table you are looking for, choose F1->Technical info. and then navigate to to the ABAP Dictionary by double -clicking on the technical name of the screen field. This is often a field in a structure. Double -click on the data element and then use the where-used list function to search for transparent tables according to the field type.

Debugger: If you know the name of a program that accesses the database table that you are looking for, you can start this program in debugging mode and set a breakpoint at the SELECT statement.

Editor: Look for the SELECT statement

Object List in the Object Navigator: Pick out the subroutines that encapsulate the database accesses.

If you know of a structure field in the ABAP Dictionary.

Double-click on the data element and then use the where -used list function to search for transparent tables according to the field type.

As soon as you navigate to the definition of a database table in the ABAP Dictionary, information about all of the table's technical attributes is available.

The following information is of interest for enhancing the performance of database accesses:

Key Fields: If the lines requested from the database are being retrieved according to key fields, the Database Optimizer can perform access using a primary index. Checkboxes are on for all key fields.

Secondary Indexes: You may also use secondary indexes to select specific lines. These are displayed in a dialog box whenever you choose the 'Indexes' pushbutton. You can choose an index from the dialog box by simply double -clicking on it. The system then displays a screen with additional information about that index.

You use the Open SQL statement SELECT to read data from the database.

Underlying the SELECT statement is a complex logic that allows you to access many different types of database table.

The statement contains a series of clauses, each of which has a different task:

The SELECT clause specifies

Whether the result of the selection is to be a single line or several lines.

The fields that should be included in the result.

Whether the result may contain two or more identical lines.

The INTO clause specifies the internal data object in the program into which you want to place the selected data.

The FROM clause specifies the source of the data (database table or view).

The WHERE clause specifies conditions that selection results must fulfill. Thus, it actually

determines what lines are included in the results table.

For information about other clauses, refer to the keyword documentation in the ABAP Editor

for the SELECT statement.

Open SQL statements are a subset of Standard SQL that is fully integrated in the ABAP language.

They allow you to access the database in a uniform way from your programs, regardless of the database system being used. Open SQL statements are converted into database-specific SQL statements by the database interface .

The SELECT SINGLE* statement allows you to read a single line from a database table. To ensure that you read a unique entry, all of the key fields must be filled by the WHERE clause. The informs the database interface that all columns in that line of the database table should be read. If only a specific cross-section of columns is desired, a structure can be inserted instead.

The name of a structure to which you want the database interface to copy a data record is inserted after the INTO clause. The structure should have a structure identical to the columns of the database table being read and be left-justified.

If you use the CORRESPONDING FIELDS OF addition in the INTO clause, you can fill the target work area component by component. The system only fills those components that have identical names to columns in the database table. If you do not use this addition, the system fills the work area from the left-hand end without any regard for its structure.

If the system finds a table entry matching your conditions, SY-SUBRC has the value 0.

The SINGLE addition tells the database that only one line needs to be read. The database can then terminate the search as soon as it has found that line. Therefore, SELECT SINGLE produces better performance for single -record access than a SELECT loop if you supply values for all key fields.

If you do not use the addition SINGLE with the SELECT statement, the system reads multiple records from the database. The field list determines the columns whose data is to be read from the database.

The number of lines to be read can be restricted using the WHERE clause. The restrictions contained in the WHERE clause should either be made according to the database table's key fields or according to a secondary index. Further information about key fields and secondary indexes can be found in the ABAP Dictionary. For example, double -clicking on the database table included in the FROM clause will take you directly to the Dictionary.

You may only enter the names of the database table fields you want to be read in the WHERE clause.

Multiple logical conditions can be added to the WHERE clause using AND or OR.

The database delivers data to the database interface in packages. The ABAP runtime system copies the data records to the target area line by line using a loop. It also provides for the sequential processing of all of the statements between SELECT and ENDSELECT.

SY-SUBRC = 0 if the system was able to select at least one entry. After the SELECT statement is executed in each loop pass, the system field SY-DBCNT contains the number of lines read. After the ENDSELECT statement, it contains the total number of lines read.

The addition INTO TABLE causes the ABAP runtime system to copy the contents of the database interface directly to the internal table itab. This is called an array fetch.

Since an array fetch is not logically a loop, no ENDSELECT statement is used.

SY-SUBRC = 0 if the system was able to read at least one table entry.

For further information about array fetch and internal tables, refer to the Internal Tables unit of this course.

The program must contain a data object with a suitable type for each column that is required from a database table. For reasons of program maintenance, you must use the corresponding Dictionary objects to assign types to the data objects. The INTO clause specifies the data object into which you want to place the data from the database table. There are two different ways to do this:

Flat structure: You define a structure in your program that has the fields in the same sequence as the field list in the SELECT clause. Then you enter the structure name in the INTO clause. The contents are copied by position. The structure field names are disregarded.

Single data objects: You enter a set of data objects in the INTO clause.

If you use the INTO CORRESPONDING FIELDS clause, the data is placed in the structure fields that have the same name.

Advantages of this construction:

The structure does not have to be structured in the same way as the field list and does not need to be left-justified

This construction is easy to maintain, since extending the field list does not require other changes to be made to the program, as long as there is a field in the structure that has the same name and type.

Disadvantages of this construction:

INTO CORRESPONDING FIELDS is more runtime-intensive than INTO. The runtime may therefore be longer.

If you want to place data into internal table columns of the same name using an array fetch, use INTO CORRESPONDING FIELDS OF TABLE .

The SAP authorization concept recognizes a large number of different authorizations. These are all managed centrally in the user master record for every user.

Authorizations are not directly assigned to users, but stored in work center descriptions (profiles).

These profiles are generated using the Profile Generator, which administers the profiles as activity groups.

Users can belong to one or more activity groups and are then assigned the authorizations contained in those activity groups.

Release 4.6 contains a large number of pre-defined activity groups. You can use these as is or copy and tailor them to your specific needs.

You should carry out an authorization check before accessing the database. The AUTHORITYCHECK statement first checks whether the user has the authorization containing all the required values. You then check the code value in the system field SY-SUBRC. If this value is 0, the user has the required authorization and the program can continue. If the value is not 0, the user does not possess the required authorization and you should display a message and take the appropriate action.

All data in the SAP system must be protected from unauthorized access by users who do not explicitly have permission to access it.

The system administrator assigns user authorization when maintaining user master data. During this process, you should determine exactly which data users are allowed to access and what kind of access should be allowed.

This is carried out by an authorization object composed of the fields 'Activity' and 'Airline carrier' that has to be addressed both during the authorization assignment process and whenever your program performs an authorization check.

Authorization objects simply define the combination of fields that need to be addressed

simultaneously and serve as templates for both authorizations and authorization checks. They are organized into object classes in order to make it easier to find and administer them; one object class or several may exist in each application. You call the authorization object maintenance transaction from the 'Development' menu in the ABAP Workbench. A complete list of all development objects, sorted according to class and including their corresponding fields and documentation, is part of this transaction.

When making authorization checks in programs, you specify the object and values the user needs in an authorization to be able to access the object. You do not have to specify the name of the authorization.

Important: The Authority-Check statement performs the authority check and returns an appropriate return code value in SY-SUBRC. When checking this return code, you can specify the consequences of a missing authorization (for example: terminate the program or display a message and skip some lines of code).

You must specify all fields of the object in an AUTHORITY-CHECK, otherwise you receive a return code not equal to zero. If you do not want to carry out a check for a particular field, enter DUMMY after the field name.

The most important return codes for AUTHORITY-CHECK are:

0: The user has an authorization containing the required values.

4: The user does not have the required authorization.

8: The check could not successfully be carried out since not all fields of the object were

specified.

The keyword documentation for AUTHORITY-CHECK contains a complete list of return codes.

You can only specify a single field after the FIELD addition, not a selection table. There are function modules which carry out the AUTHORITY-CHECK for all values in the selection table.

If reusable components that encapsulate complex data retrieval are available , then you must use them. There are four techniques available for doing this.

Methods of global classes

Methods of business objects

Function modules

Logical databases are data retrieval programs delivered by SAP that return data in a hierarchically logical sequence.

You can find information on the various techniques in the Reuse Components unit.

Views are application-specific views of different ABAP Dictionary tables. Views can contain a selection of fields from a single very large table or fields from several different tables.

Views allow you to gather information from the fields of different tables and present it to users in the form they require when working with the R/3 System.

Views are mainly used for programming with ABAP and for F4 online help.

If there are no components available that are suitable for your purposes, you can carry out complex database access using ABAP-OPEN- SQL statements. To do this you have to compare the merits of various techniques, as using an unsuitable technique can result in considerable performance problems.

LESSON 7 USER DIALOGS-LISTS

The main purpose of a list is to output data in a manner that can be easily understood by the user; this output often takes on the form of a table. Lists in R/3 take into account special business data requirements:

They are language-independent. Texts and headers appear in the logon language whenever the appropriate translation is available.

They can output monetary values in numerous currencies.

You can output list data in the following ways:

to the screen; here you can add colors and icons

to the printer

to the Internet/intranet: Automatic conversion to HTML

you can also save lists in the R/3 System or output them for processing by external commercial software applications like spreadsheet programs

The standard list interface offers the user several navigation features:

Back

Exit

Cancel

Print

Find (in List)

Save: saves the list either as a file on the desktop, in a report tree, or to the Office

Send: sends the list in e-mail form

For further information on how you can adjust the standard list interface to fit your individual needs see Dialogs: Interfaces.

Each list can have a list header and up to four lines of column headers . There are two different ways to go about using these tools:

from within the Editor using the text element maintenance functions

from within the list itself. If you save your program, activate it and then run it to create the list, you can enter both list and column headers by choosing the menu path System -> List -> List headers.

The main advantage of using this method is that the list is still displayed on the screen. This makes it easier to position column headers.

The next time you start the program, the new headers will appear in the list automatically.

When no header text is entered, the program title is inserted in the header.

Titles and headers are part of a program's text elements. You can translate all text elements into other languages. The logon language setting on the logon screen detemines in which language text elements will be displayed.

Text symbols are another kind of text element. These are special text literal data objects. Compared to normal text literals, text symbols have the advantage that they can be translated into different languages without having to change a program's source code. Text symbols allow you to create lists independent of language.

You can write text symbols into your program in either of the following ways:

TEXT- (where xxx is a character string three characters long)

''() (where xxx is a character string three characters long)

In executable programs (type 1), lists are automatically displayed after their corresponding event blocks have been processed. These processing blocks must, however, contain a list creation statement. These are WRITE, SKIP, and ULINE.

Event blocks are called in a sequence designed for list processing:

Prior to sending the selection screen: INITIALIZATION

After leaving the selection screen: START-OF-SELECTION

All output from START-OF-SELECTION event blocks, subroutines, and function modules that is processed before a list is displayed is temporarily stored in the list buffer.

Once all list creation processing blocks (for example START-OF-SELECTION) have been processed, all data from the list buffer is output in the form of a list.

In executable programs, you can use the event block AT LINE-SELECTION to create detail lists.

The ABAP runtime system:

Displays the basic list after the appropriate event blocks have been processed (for example, after START-OF-SELECTION). In this case, system field sy-lsind contains the value 0.

Processes the event block AT LINE-SELECTION each time you double -click on an entry. If you are using a standard status, this happens automatically every time you choose the Choose icon, the Choose menu item in the Edit menu, or the function key F2.

Displays detail lists after the AT LINE-SELECTION event block has been processed and increases the value contained in sy-lsind by one.

Displays the detail list from the previous level in the list hierarchy (n-1) every time you choose the green arrow icon from the current detail list (n).

The lists in the example program should function as follows:

The basic list should display the text 'Basic List' and system field sy-lsind.

The user should be able to call the initial detail list using a double -click or by choosing its

corresponding icon from the application toolbar or its menu entry or by using the function key F2. Then the 'Detail list' appears and the system field sy-lsind has the value 1.

Repeating this action should call the second detail list, where system field sy-lsind contains the value 2 (representing the current detail list level).

Repeating this action increases the sy-lsind value by one every time up to a value of twenty (the total number of detail lists supported).

Choosing the green arrow takes the user back a single detail list level at a time until the basic

list is reached.

A detail list can be programmed as follows:

You create a basic list by filling the basic list buffer at an appropriate event block (here

START-OF-SELECTION) using either WRITE, SKIP, or ULINE.

Use the event block AT LINE-SELECTION when programming detail lists. Whenever you use WRITE, SKIP, or ULINE with this event block, you fill the detail list buffer for the next level (the detail list buffer with a level value one greater than the level on which the user

performed his or her action).

You can pre-determine navigation between detail lists by querying system field sy-lsind at the event block AT LINE-SELECTION.

We will now write a program using both basic lists and detail lists:

When the event AT LINE-SELECTION is processed, a program's data objects contain the same values as they did before the basic list display. A detail list, however, often needs data selected within the basic list itself. You can use the HIDE area to store certain data from the line that you have selected and then automatically insert where you need it in the corresponding data object for a detail list. You can predetermine which information should be classified by its line position when you are creating a basic list.

To do this, you use the ABAP keyword HIDE followed by a list of the data objects that you need. The runtime system automatically records the name and contents of the data object in relation to its line position in the list currently being created.

As soon as the interactive event (AT LINE-SELECTION in this example) is called by placing the cursor on a specific line and then either double -clicking or choosing the Choose icon, the values for this line stored in the HIDE area are inserted into their corresponding data objects.

You create a detail list by filling the detail list buffer at the AT LINE-SELECTION event block using either WRITE, SKIP, or ULINE. In this sample program, the key fields for the airline are displayed and the flights available for this airline in the database table SFLIGHT are read using a SELECT loop. Note that the line-specific information on the airline is only available by double - clicking in the data objects if the relevant data objects have been placed in the HIDE area when the basic list was created.

LESSON 9 DIALOGS AND SCREENS

Screens are made up of more than just a monitor display with input and output fields.

Screens' integration with the ABAP-Dictionary allows the system to perform consistency checks for their input fields automatically. These checks include required input check, type checks, foreign key checks, and fixed value checks. All of these checks rely upon ABAP Dictionary information.

Checks like the ones above can be complemented by other program specific checks. There are techniques available for screens that allow you to control in what order checks are then performed.

When an error is detected, the corresponding field is called and displayed ready for input. Screen layout is also very flexible. Input fie lds, output fields, radio buttons, check boxes, and even pushbuttons can be placed on screens. They allow users to determine in which direction the program will proceed.

On the whole, such user influence on program progression allows for more program flexibility in those programs that do contain screens.

You can call screens from any ABAP processing block that you want.

You can link several screens to one another and then call them from within a program by simply calling the first screen.

Some ABAP programs are made up exclusively of screens and their correponding ABAP

processing blocks. In this case the first screen is called directly using a transaction code.

Double-click on an entry in the basic list 'timetable' to reach a screen. This screen displays data

The major steps in creating a screen:

specifying its properties (Screen Attributes)

specifying its layout (in Fullscreen Editor)

defining attributes for the elements on the screen (Field List)

programming its flow logic

You should be able to call your screen by double -clicking a line within the basic list and you should be able to return to the basic list by choosing the appropriate function key on the screen.

There are several ways to create screens:

Forward Navigation: You can create screens from within the ABAP Editor by double –clicking on the screen number. This transfers you into Screen Painter automatically

Object Navigator: You can also create a screen from the object list in the Object Navigator

When creating a screen for the first time the system will ask you to enter screen attributes. Enter a short description of the screen, select screen type Normal and enter the number of the subsequent screen in the Next Screen input field.

If you enter 0 or leave the Next Screen field blank, the system first processes your screen completely and then returns to processing the program at the point immediately following the screen call. Be aware that in the Next screen input field, the 0 is suppressed, since it is the same as the initial value of the field.

There are two ways of assigning field attributes to screen fields:

Adopt them from the Dictionary: You can adopt types and field attributes from existing

ABAP Dictionary structures. This makes all information about the object available to you,

including semantic information about its data elements and foreign key dependencies. The name of the Dictionary field is automatically adopted as a field name.

Adopt them from a program: You can adopt field attributes from data objects already defined within a program. In order to do this, however, an activated copy of the program must already exist. The name of the data object is automatically adopted as a field name.

The Graphical Screen Painter's interface allows you to define screen elements (for example, input and output fields, keyword texts, borders, and so on) with relative ease. Choose the desired screen element from the column on the left and then place it on the screen using your mouse.

You can delete screen elements simply by selecting them with your mouse and then choosing delete.

You can move screen elements by holding down your left mouse button and dragging them to a new position.

You can maintain screen field attributes by selecting a field and choosing Attributes.

You can classify certain fields as 'mandatory'.(. "Required field"). A question mark is displayed at runtime if the field is initial.

If not all required fields have been filled at runtime and a user action is performed, an error dialog is triggered and all input fields are once again displayed ready for input.

You can also edit screen field attributes by choosing Field list.

The field list is then displayed as a tab.

This same function can also be accessed in a different format from within the Graphical Screen Painter.

The statement TABLES declares an internal data object that serves as an interface for the screen.

TABLES always refers to a structure that is defined in the ABAP Dictionary.

If a TABLES statement and a screen field both refer to the same Dictionary structure, this data object's data is transported to the screen fields every time the screen is called. Any new entries or changes that the user makes on the screen are then transferred back into this data object.

Data transport takes place automatically between screens and program data objects of the same name:

Immediately before a screen is sent to the presentation server (after all PBO event modules have been processed) the system copies field contents out of the ABAP work area into their corresponding fields in the screen work area.

ABAP statements facilitate data transport between program data objects and the work area designated as the screen interface.

Data transport takes place automatically between screens and program data objects of the same name:

Immediately after a user action (before the first PAI module has been processed) the system copies field contents out of the screen work area and into their corresponding fields in the ABAP work area.

ABAP statements facilitate data transport between the work area designated as the screen interface and program data objects.

In order to ensure that the database data that is displayed on the screen is up-to-date, the record is read again from the database at the beginning of AT LINE-SELECTION.

Advantages of this method:

For the basic list, only those columns of the database table that are displayed on the list need to be read. This can improve performance with large lists.

The data that is displayed on the screen is always up-to-date, even if the data record selected has only just been changed using this program. This would not happen if all screen data was placed in the HIDE area when the basic list is created.

Changes made to the database using the screen do not lead to incorrect values in the basic list, as the modifiable fields are not contained in the list.

Looking ahead to the lock concept: The lock times can be shortened. You find more detailed information on this topic in the Database Dialogs II unit.

The program can be extended: Additional information from the data record can be displayed on the screen without having to make many changes.

To display data on the screen, the TABLES structure must be filled with current data before the screen is sent to the presentation server. The example above shows one way of doing this.

The data record is read from the database using SELECT SINGLE. This ensures that the structure contains current data, even if the user has just changed the data. The structure is assigned the same type as the database table line type, so that suitable fields are available for all data in the data record.

The system transports the structure data to the screen fields automatically.

Each screen has two corresponding event blocks:

PROCESS BEFORE OUTPUT (PBO) is processed immediately before a screen is displayed. At this time modules are called that take care of tasks such as inserting recommended values into input fields.

PROCESS AFTER INPUT (PAI) is processed immediately after a user action. All program logic that is influenced by user action must be processed at PAI. You will learn more about this in step three.

Note: The code for the events PBO and PAI is written using the Screen Painter and not the ABAP Editor. These two event blocks make up a screen's flow logic.

When programming flow logic, use the set of commands called Screen ABAP. MODULE is the most important Screen ABAP command. It calls a special ABAP processing block called a module.

Modules are ABAP processing blocks with no interface that can only be called from within a program's flow logic. Modules begin with the ABAP statement MODULE and end at ENDMODULE.

Program logic that logically belongs to a specific screen should normally be processed at the screen's PBO and PAI events.

If you enter 0 or leave the Next Screen field blank, the system first processes your screen completely and then carries on processing the program from where the screen was called.

If you set the Next screen of screen 100 to 100, the system processes the screen again, after it has finished processing the PAI module.

You can use the ABAP statement SET SCREEN within a PAI module to override dynamically the value set in the Next screen attribute.

Often the same screen number is entered in both the Screen number and Next screen fields. In this case, when you choose Enter, a field check is performed and the system returns you to the same screen. In order to leave the screen, an appropriate pushbutton must be defined that then triggers a Next screen change within the PAI module.

With the help of the OK_CODE field, different program logic can now be processed by the PAI modules depending on what the user inputs.

If an OK_CODE field is not initialized, errors can occur since not every pushbutton is required to have a function code. There are two ways of doing this:

Initialize the OK_CODE field in a PBO module. Then it is set to the initial value at PAI, unless the user has carried out a user action to which a function code is assigned. In this case, the OK_CODE field contains the function code.

Use an auxiliary field and copy the contents of the OK_CODE field to the auxiliary field in a PAI module, and then initialize the OK_CODE field. In this case, the auxiliary field must be queried in the PAI module for the function code evaluation.

You can implement calls such as MODULE within a screen's flow controls (PBO and PAI events).

The modules themselves are, however, created using ABAP.

There are two ways to create a module:

using forward navigation: Double-click on the module name from within the Screen Painter Editor to create the module.

Using the Object Navigator: If you want to create a module using the object list in the Object Navigator, first display your program, then choose 'PBO module' or 'PAI module' in the ProgramObjects display and create a new development object by selecting the create icon.

A module can be called from more than one screen. (Reusability)

Be aware that modules called at PBO events must be defined using the statement MODULE ... OUTPUT, whereas modules defined with MODULE ... INPUT, can only be called at PAI events.