This overview describes application programming in the R/3 System. All application programs, along with parts of the R/3 Basis system, are written in the ABAP Workbench using ABAP, SAP’s programming language. The individual components of application programs are stored in a special section of the database called the R/3 Repository. The following sections of this documentation cover the basics and characteristics of application programming.

R/3 application programs run within the R/3 Basis system on the work processes of application servers. This makes them independent of the hardware and operating system that you are using. However, it also means that you cannot run them outside the R/3 System.

Interaction between application programs and the user is implemented using screens. Screens are processed by the screen processor of a work process. As well as the input mask, they consist of flow logic. This is coding, written using a special set of keywords called the screen language. The input mask is displayed by the SAPgui, which also transfers the user action on the screen back to the flow logic. In the program flow, screens react to the user actions and call program modules. These program modules form the processing logic.

The components of application programs that are responsible for data processing in the R/3 System are ABAP programs. ABAP stands for ‘Advanced Business Application Programming’. ABAP programs run on the ABAP processor of a work process. They receive screen input from the screen processor and send it to the screen processor. You access the database using the database interface. ABAP contains a special set of commands called OPEN SQL. This allows you to read from and write to the database regardless of the database you are using. The database interface converts the OPEN SQL commands into commands of the relevant database. You can also use native SQL commands, which are passed to the database without first being converted. There is a range of further interfaces such as memory, sequential files and external interfaces. These provide other means of sending data to and from ABAP programs. When working together with screens, ABAP programs play a more passive role, acting as a container for a set of modules that can be called from the flow logic.

Each screen that a user sees in the R/3 System belongs to an application program. Screens send data to, receive data from, and react to the user’s interaction with the input mask. There are three ways to organize screen input and output. These differ in the way in which they are programmed, and in how the user typically interacts with them.

Screens in the R/3 System also contain a menu bar, a standard toolbar, and an application toolbar. Together, these three objects form the status of the screen. A status is a development object belonging to its corresponding application program. It is independent of the screen, and can therefore be used in conjunction with several different screens. You define statuses using the Menu Painter in the ABAP Workbench. You can define statuses yourself for screens and lists, but there is a predefined status that the system always uses for selection screens.

The following sections describe the different types of screen in more detail.

Each screen contains an input mask that you can use for data input and output. You can design the mask yourself. When the screen mask is displayed by the SAPgui, two events are triggered: Before the screen is displayed, the Process Before Output (PBO) event is processed. When the user interacts with the screen, the Process After Input (PAI) event is processed.

Each screen is linked to a single PBO processing block and a single PAI processing block. The PAI of a screen and the PBO of the subsequent screen together form a dialog step in the application program.

The screen language is a special subset of ABAP, and contains only a few keywords. The statements are syntactically similar to the other ABAP statements, but you may not use screen statements in ABAP programs or ABAP statements in the screen flow logic. The most important screen keywords are MODULE, FIELD, CHAIN, and LOOP. Their only function is to link the processing logic to the flow logic, that is, to call modules in the processing logic, and control data transfer between the screen and the ABAP program, for example, by checking fields.

The input/output mask of a screen contains all of the normal graphical user interface elements, such as input/output fields, pushbuttons, and radio buttons. The following diagram shows a typical screen mask:

All of the active elements on a screen have a field name and are linked to screen fields in shared memory. You can link screen fields to the ABAP Dictionary. This provides you with automatic field and value help, as well as consistency checks.

When a user action changes the element, the value of the screen field is changed accordingly. Values are transported between screens and the processing logic in the PAI event, where the contents of the screen fields are transported to program fields with the same name.

Each screen calls modules in its associated ABAP program which prepare the screen (PBO) and process the entries made by the user (PAI). Although there are ABAP statements for changing the attributes of screen elements (such as making them visible or invisible), but there are none for defining them.

Dialog screens enable the user and application programs to communicate with each other. They are used in dialog-oriented programs such as transactions, where the program consists mainly of processing a sequence of screens, and are particularly useful when specialized screens (selection screens and lists) are insufficient for your requirements.

Selection screens are special screens used to enter values in ABAP programs. Instead of using the Screen Painter, you create them using ABAP statements in the processing logic of your program. The screen flow logic is supplied by the system, and remains invisible to you as the application programmer.

You define selection screens in the declaration part of an ABAP program using the special declaration statements PARAMETERS, SELECT-OPTIONS and SELECTION-SCREEN). These statements declare and format the input fields of each selection screen. The following is a typical selection screen:

The most important elements on a selection screen are input fields for single values and for selection tables. Selection tables allow you to enter more complicated selection criteria. Selection tables are easy to use in ABAP because the system automatically processes them itself. As on other screens, field and possible values help is provided for input fields which refer to an ABAP Dictionary field. Users can use pre-configured sets of input values for selection screens. These are called variants.

You call a selection screen from an ABAP program using the CALL SELECTION-SCREEN statement. If the program is an executable (report) with type 1, a system program automatically calls the selection screen defined in the declaration part of the program. Selection screens trigger events, and can therefore call event blocks in ABAP programs.

Since selection screens contain principally input fields, selection screen dialogs are more input-oriented than the screens you define using the Screen Painter. Dialog screens can contain both input and output fields. Selection screens, however, are appropriate when the program requires data from the user before it can continue processing. For example, you would use a selection screen before accessing the database, to restrict the amount of data read.

Lists are output-oriented screens which display formatted, structured data. They are defined, formatted, and filled using ABAP commands. The system displays lists defined in ABAP on a special list screen. As with selection screens, the flow logic is supplied by the system and remains hidden from the application programmer.

The most important task of a list is to display data. However, users can also interact with them. Lists can react to mouse clicks and contain input fields. Despite these similarities with other types of screen, lists are displayed using a completely different technique. Input fields on lists cannot be compared with those on normal screens, since the method of transferring data between the list and the ABAP program is completely different in each case. If input fields on lists are linked to the ABAP Dictionary, the usual automatic field and possible values help is available. The following is a typical list:

You define lists using a special set of statements (the list statements WRITE, SKIP, ULINE, NEW-PAGE and so on) in the processing blocks of ABAP programs. When these statements are executed, a list is composed within the system. An internal system program called the list processor is responsible for displaying lists and for interpreting user actions in the list. Lists are important because only data in list format can be sent to the R/3 spool system for printing.

In an ABAP program, you can use the LEAVE TO LIST-PROCESSING statement to define the next screen as a list. If the ABAP program is an executable (report) with type 1, a system program automatically calls the list defined in your program. A single program can be responsible for a stack of up to 21 lists; one basic list and up to twenty detail lists. User actions on a list screen trigger events, and can thus call event blocks in the ABAP program.

Lists are output-oriented. When users carry out actions on a list screen, it is normally to use part of the list contents in the next part of the program, and not to input values directly. Using lists is appropriate when you want to work with output data, to print data or when the user’s next action depends on output data.

ABAP processing logic is responsible for processing data in R/3 application programs. ABAP was designed specifically for dialog-oriented database applications. The following sections deal with how an ABAP program is structured and executed.

ABAP programs are responsible for data processing within the individual dialog steps of an application program. This means that the program cannot be constructed as a single sequential unit, but must be divided into sections that can be assigned to the individual dialog steps. To meet this requirement, ABAP programs have a modular structure. Each module is called a processing block. A processing block consists of a set of ABAP statements. When you run a program, you effectively call a series of processing blocks. They cannot be nested.

The following diagram shows the structure of an ABAP program:

Each ABAP program consists of the following two parts:

The first part of an ABAP program is the declaration part for global data, classes, and selection screens. This consists of:

• All declaration statements for global data. Global data is visible in all internal processing blocks. You define it using declarative statements that appear before the first processing block, in dialog modules, or in event blocks. You cannot declare local data in dialog modules or event blocks.
• All selection screen definitions.
• All local class definitions (CLASS DEFINITION statement). Local classes are part of ABAP Objects, the object-oriented extension of ABAP.

Declaration statements which occur in routines (methods, subroutines, function modules) form the declaration part for local data in those processing blocks. This data is only visible within the routine in which it is declared.

The second part of an ABAP program contains all of the processing blocks for the program. The following types of processing blocks are allowed:

• Dialog modules (no local data area)
• Event blocks (no local data area)
• Routines (methods, subroutines and function modules with their own local data area).

Whereas dialog modules and routines are enclosed in the ABAP keywords which define them, event blocks are introduced with event keywords and concluded implicitly by the beginning of the next processing block.

All ABAP statements (except declarative statements in the declaration part of the program) are part of a processing block. Non-declarative ABAP statements, which occur between the declaration of global data and a processing block are automatically assigned to the START-OF-SELECTION processing block.

You can call processing blocks either from outside the ABAP program or using ABAP commands which are themselves part of a processing block. Calling event blocks is different from calling other processing blocks for the following reasons:

An event block call is triggered by an event. User actions on selection screens and lists, and system programs trigger events that can be processed in ABAP programs. You only have to define event blocks for the events to which you want the program to react (whereas a subroutine call, for example, must have a corresponding subroutine). This ensures that while an ABAP program may react to a particular event, it is not forced to do so.

In the R/3 System, there are various types of ABAP program. The program type determines the basic technical attributes of the program, and you must set it when you create it. The main difference between the different program types is the way in which the program calls its processing blocks.

When you run an application program, you must call at least the first processing block from outside the program, either using screen flow logic or an external programming interface (like RFC). This processing block can then either call further processing blocks or return control to outside the program.

There are two ways of allowing users to execute programs - either by entering the program name or by entering a transaction code. You can assign a transaction code to any program. Users can then start that program by entering the code in the command field. Transaction codes are also usually linked to a menu path within the R/3 System.

The following program types are relevant to application programming:

Type 1 programs have the important characteristic that they do not have to be controlled using screens. Instead, they are controlled by an invisible system program that calls a series of processing blocks (and selection screens and lists where necessary) in a fixed sequence. Further processing blocks can be triggered by user actions on the screen.

You can start a type 1 program and the invisible system program using the SUBMIT statement in another ABAP program. There are also various ways of starting a type 1 program by entering its program name. This is why we refer to type 1 programs as executable programs.

The invisible system program provides a predefined program flow, which starts with a selection screen (for data entry), processes the data, and then displays the results in a list without the programmer having to define any screens his- or herself. The system program also allows you to work with a logical database. A logical database is a special ABAP program which combines the contents of certain database tables. The flow of the system program is oriented towards reporting, whose main tasks are to read data from the database, process it, and display the results. This is why executable programs (type 1) in the R/3 System are often referred to as reports, and why running an executable program is often called reporting.

Since it is not compulsory to define event blocks, you can yourself determine the events to which your ABAP program should react. Furthermore, you can call your own screens or processing blocks at any time, leaving the prescribed program flow. You can use this, for example, to present data in a table on a dialog screen instead of in a list. The simplest executable program (report) contains only one processing block (START-OF-SELECTION).

Executable programs do not require any user dialog. You can fill the selection screen using a variant and output data directly to the spool system instead of to a list. This makes executable programs (reports) the means of background processing in the R/3 System.

You can also assign a transaction code to an executable program. Users can then start it using the transaction code and not the program name. The reporting-oriented invisible system program is also called when you run a report using a transaction code. This kind of transaction is called a report transaction.

It is appropriate to use executable programs (reports) when the flow of your program corresponds either wholly or in part to the pre-defined flow of the system program. If you want to use a logical database, you must use an executable program (report).

The most important technical attribute of a type M program is that it can only be controlled using screen flow logic. You must start them using a transaction code, which is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the initial screen can be a selection screen).

When you start a program using its transaction code, the initial screen is called. This calls a dialog module belonging to the associated ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:

• return control to the screen, after which, the processing passes to a subsequent screen in a fixed sequence.
• call other dialog screens, selection screens or lists, from which further processing blocks in the ABAP program are started.
• call other processing blocks itself, either internally or externally.
• call other application programs using CALL TRANSACTION (type M program) or SUBMIT (type 1 program).

ABAP programs with type M contain the dialog modules belonging to the various screens. They are therefore known as module pools. It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow.

Type F programs are containers for function modules, and cannot be started using a transaction code or by entering their name directly. Function modules are special programs that you can call from other ABAP programs.

They can only be programmed in type F programs, which are also known as function groups. The Function Builder is a tool in the ABAP Workbench that you can use to create function groups and function modules. Apart from function modules, function groups can contain global data declarations and subroutines. These are visible to all function modules in the group. They can also contain event blocks for screens in function modules.

Type I programs - called includes - are a means of dividing up program code into smaller, more manageable units. You can insert the coding of an include program at any point in another ABAP program using the INCLUDE statement. There is no technical relationship between include programs and processing blocks. Includes are more suitable for logical programming units, such as data declarations, or sets of similar processing blocks. The ABAP Workbench has a mechanism for automatically dividing up module pools and function groups into include programs.

The following sections describe the various processing blocks that you can use in ABAP programs. There are also further processing blocks that occur in ABAP Objects, the object-oriented extension of ABAP.

You call dialog modules from the screen flow logic (screen command MODULE). You can write a dialog module in an ABAP program for each state (PBO, PAI; user input) of any of the screens belonging to it. The PAI modules of a screen together with the PBO modules of the subsequent screen form a dialog step.

Dialog modules are introduced with the MODULE statement and concluded with the ENDMODULE statement.

Fields on a dialog screen have the same name as a corresponding field in the ABAP program. Data is passed between identically-named fields in the program. You do not define dialog screens in the ABAP programs.

A selection screen is a special kind of dialog screen that you create using ABAP commands. Particular events correspond to the different states of the selection screen (PAI, PBO, user input), and processing blocks can be assigned to them in the ABAP program.

You therefore do not need to create dialog modules for the PBO and PAI events of a selection screen. Data is passed between selection screen and ABAP program using the fields (parameters and selection tables) which you create in the selection screen definition in the declaration part of the ABAP program.

Lists are special screens which output formatted data. You can create them in any processing block in an ABAP program using a special set of commands (such as WRITE, NEW-PAGE and so on). An internal program called the list processor displays the list on the screen and handles user actions within lists.

You can call various event blocks while the list is being created which are used in page formatting. The above illustration contains the event block TOP-OF-PAGE, which is called from the ABAP program itself. When the list is displayed, the user can carry out actions which trigger event blocks for interactive list events (such as AT LINE-SELECTION). Data is transferred from list to ABAP program via system fields or an internal memory area called the HIDE area.

When you run an executable (type 1) program, an invisible system program calls a series of event blocks in a fixed order:

1. ? If you have defined a selection screen in the declaration part of the ABAP program, the system program generates it in an initialization part of the program.
2. ? It creates the INITIALIZATION event and calls the corresponding event block (if it has been defined in the ABAP program).
3. ? It passes control to the selection screen. The selection screen generates its own events, and calls the corresponding event blocks. At the end of the PAI of the selection screen, the list generation part of the system program takes control.
4. ? It creates the START-OF-SELECTION event and calls the corresponding event block (if it has been defined in the ABAP program).
5. ? The logical database, if you are using one, calls further event blocks at this point.
6. ? It creates the END-OF-SELECTION event and calls the corresponding event block (if it has been defined in the ABAP program).
7. ? It them passes control to an internal system program called the list processor. The list processor displays the list defined in the ABAP program. User actions in the list generate events themselves, and the corresponding event blocks are called.

Subroutines are introduced with the FORM statement and concluded with the ENDFORM statement.

You call them from ABAP programs using the PERFORM statement.

You can define subroutines in any ABAP program. You can either call a subroutine that is part of the same program or an external subroutine, that is, one that belongs to a different program. If you call an internal subroutine, you can use global data to pass values between the main program and the subroutine. When you call an external subroutine, you must pass actual parameters from the main program to formal parameters in the subroutine.

Function modules are special external functions with a fixed interface. Function modules are introduced with the FUNCTION statement and concluded with the ENDFUNCTION statement. You define them in the ABAP Workbench using the Function Builder. Each function module belongs to a function group.

You call function modules from ABAP programs using the CALL FUNCTION statement.

Unlike subroutines, function modules have a pre-defined parameter interface. You can only call function modules externally using CALL FUNCTION.

Logical databases are special ABAP programs that read data from database tables. They are used by executable (type 1) programs. At runtime, you can regard the logical database and the executable program (reports) as a single ABAP program, whose processing blocks are called by the system program in a particular, pre-defined sequence.

You edit logical databases using a tool within the ABAP Workbench, and link them to executable programs (reports) when you enter the program attributes. You can use a logical database with any number of executable programs (reports). However, they are only auxiliary programs, and can only be used in conjunction with executable programs.

The following diagram shows the structure of a logical database, which can be divided into three sections:

The structure of a logical database determines the database tables which it can access. It adopts the hierarchy of the database tables defined by their foreign key relationships. This also controls the sequence in which the tables are accessed.

The selection part of the logical database defines input fields for selecting data. The system program displays these on the selection screen when you run an executable program linked to the logical database. The corresponding fields are also available in the ABAP program, allowing you, for example, to change their values to insert default values on the selection screen.

The database program of a logical database is a container for special subroutines, in which the data is read from the database tables. The system program, which controls the flow of an executable program, calls these subroutines in the order determined by the structure of the logical database.

The following diagram shows the principal processing blocks that are called when you execute a program linked to a logical database:

The system program calls depend both on the structure of the logical database and on the definition of the executable program. The structure of the logical database determines the sequence in which the processing blocks of the logical database are called. These in turn call GET event blocks in the executable program. These GET event blocks determine the read depth in the structure of the logical database. The TABLES statement in the declaration part of the executable program determines which of the input fields defined in the logical database will be displayed on the screen.

The actual access to the R/3 System database is made using OPEN SQL statements in the PUT_<TABLE> subroutines. The data that is read is passed to the executable program using global structures (defined using the TABLES statement). Once the data has been read in the logical database program, the executable program (report) can process the data in the GET event blocks. This technique separates data reading and data processing.

The main use of logical databases is to make the code that accesses data in database tables reusable. SAP supplies logical databases for all applications. These have been configured for optimal performance, and contain further functions such as authorization checks and search helps. It is appropriate to use logical databases whenever the database tables you want to read correspond largely to the structure of the logical database and where the flow of the system program (select - read - process - display) meets the requirements of the application.

The source code of an ABAP program consists of comments and ABAP statements.

Comments are distinguished by the preceding signs * (at the beginning of a line) and " (at any position in a line).

ABAP statements always begin with an ABAP keyword and are always concluded with a period (.). Statements can be several lines long; conversely, a line may contain more than one statement.

ABAP statements use ABAP data types and objects.

The first element of an ABAP statement is the ABAP keyword. This determines the statement category, which is one of the following:

These statements define data types or declare data objects which are used by the other statements in a program or routine. The collected declarative statements in a program or routine make up its declaration part.

Examples of declarative keywords:

These statements define the processing blocks in an ABAP program.

The modularization keywords can be further divided into:

• Event Keywords

You use these statements to control the flow of an ABAP program within a processing block according to certain conditions.

Examples of control keywords:

You use these statements to call processing blocks that you have already defined using modularization statements. The blocks you call can either be in the same ABAP program or in a different program.

Examples of call keywords:

These keywords process the data that you have defined using declarative statements.

Examples of operational keywords:

These statements use the database interface to access the tables in the central database system. There are two kinds of database statement in ABAP: Open SQL and Native SQL.

Open SQL is a subset of the standard SQL92 language. It contains only Data Manipulation Language (DML) statements, such as SELECT, INSERT, and DELETE. It does not contain any Data Definition Language (DDL) statements (such as CREATE TABLE or CREATE INDEX). Functions of this type are contained in the ABAP Dictionary. Open SQL contains all of the DML functions from SQL92 that are common to all of the database systems supported by SAP. It also contains a few SAP-specific functions. ABAP programs that use only Open SQL statements to access the database are fully portable. The database interface converts the OPEN SQL commands into commands of the relevant database.

Native SQL statements are passed directly from the database interface to the database without first being converted. It allows you to take advantage of all of your database’s characteristics in your programs. In particular, it allows you to use DDL operations. The ABAP Dictionary uses Native SQL for tasks such as creating database tables. In ordinary ABAP programs, it is not worth using DDL statements, since you cannot then take advantage of the central administration functions of the ABAP Dictionary. ABAP programs that use Native SQL statements are database-specific, because there is no standardized programming interface for SQL92.

The physical units with which ABAP statements work at runtime are called internal program data objects. The contents of a data object occupy memory space in the program. ABAP statements access these contents by addressing the name of the data object. For example, statements can write the contents of data objects in lists or in the database, they can pass them to and receive them from routines, they can change them by assigning new values, and they can compare them in logical expressions.

Each ABAP data object has a set of technical attributes, which are fully defined at all times when an ABAP program is running. The technical attributes of a data object are: Data type, field length, and number of decimal places.

The data type determines how the contents of a data object are interpreted by ABAP statements. As well as occurring as attributes of a data object, data types can also be defined independently. You can then use them later on in conjunction with a data object. You can define data types independently either in the declaration part of an ABAP program (using the TYPES statement), or in the ABAP Dictionary.

The data types you will use in a program depend on how you will use your data objects. The task of an ABAP program can range from passing simple input data to the database to processing and outputting a large quantity of structured data from the database. ABAP contains the following data types:

There are five predefined non-numeric data types:

and three predefined numeric types:

The field length for data types D, F, I, and T is fixed. The field length determines the number of bytes that the data object occupies in memory. In types C, N,X and P, the length is not part of the type definition. Instead, you define it when you declare the data object in your program.

Data type P is particularly useful for exact calculations in a business context. When you define an object with type P, you also specify a number of decimal places.

You can also define your own elementary data types in ABAP using the TYPES statement. You base these on the predefined data types. For example, you could define a data type P_2 with two decimal places, based on the predefined data type P. You could then use this new type in your data declarations.

You use elementary data types to define individual elementary data objects. You use these object to transfer input and output values, as auxiliary fields in calculations, to store intermediate results, and so on. As well as their function as individual objects, data types are also the smallest components of structured data types.

A structured data type can be a structure or an internal table.

A structure is a user-defined sequence of data types. It fully defines the data object. You can either access the entire data object, or its individual components. ABAP has no predefined structures. You therefore need to define your own structures, either in the ABAP program in which you want to use it, or in the ABAP Dictionary.

You use structures in ABAP programs to group work areas that logically belong together. Since the individual elements within a structure can be of any type, and can also themselves be structures or internal tables, the possible uses of structures are very wide-ranging. For example, you can use a structure with elementary data types to display lines from a database table within a program. You can also use structures containing structured elements to include all of the attributes of a screen or control in a single data object.

Internal tables consists of a series of lines that all have the same data type.

Internal tables are characterized by:

• Their line type.

• A key

• The access type

You should use internal tables whenever you need to use structured data within a program. One imprint use is to store data from the database within a program.

Apart from the interface parameters of routines, you declare all of the data objects in an ABAP program or routine in its declaration part. The declarative statements establish the data type of the object, along with any missing technical attributes, such as its length or the number of decimal places. This all takes place before the program is actually executed (with the exception of internal tables).

When you declare an internal table, you specify the above details. However, you do not need to specify the overall size of the data object. Only the length of a row in an internal table is fixed. The number of rows (the actual length of the data object in memory) is adapted dynamically at runtime. In short, internal tables can be extended dynamically while retaining a fixed structure.

The interface parameters of routines are generated as local data objects, but not until the routine is called. You can define the technical attributes of the interface parameters in the routine itself. If you do not, they adopt the attributes of the parameters from which they receive their values.

In application programming, you often use a relatively small set of basic data to derive further data. This basic data might, for example, be the data that the user enters on the screen. The relational links in the database are often used to read further data on the basis of this basic data, or further values are calculated from it using ABAP statements.

It is often the case that certain relationships between data are always used in the same form to get further data, either within a single program or in a whole range of programs. This means that a particular set of database accesses or calculations is repeatedly executed, despite the fact that the result already exists in the system. This causes unnecessary system load, which can be alleviated by using contexts.

You define contexts in the Context Builder, which is part of the ABAP Workbench. They consist of key input fields, the relationships between the fields, and the other fields and values that you can derive from them. Contexts can link these derived fields by foreign key relationships between tables, by function modules, or by other contexts.

In application programs, you work with instances of a context. You can use more than one instance of the same context. The application program supplies input values for the key fields in the context using the SUPPLY statement, and can query the derived fields from the instance using the DEMAND statement.

Each context has a cross-transaction buffer on the application server. When you query an instance for values, the context program searches first of all for a data record containing the corresponding key fields in the appropriate buffer. If one exists, the data is copied to the instance. If one does not exist, the context program derives the data from the key field values supplied and writes the resulting data record to the buffer.