The following sections describe three different views of the R/3 System, which show the role of the Basis system.

The following illustration represents a logical view of the R/3 System.

The difference between the logical view and a hardware- or software-based view is that not all of the above components can be assigned to a particular hardware or software unit. The above diagram shows how the R/3 Basis system forms a central platform within the R/3 System. Below are listed the tasks of the three logical components of the R/3 Basis system.

The kernel and basis services component is a runtime environment for all R/3 applications that is hardware-, operating system- and database-specific. The runtime environment is written principally in C and C++. However, some parts are also written in ABAP. The tasks of the kernel and basis services component are as follows:

• Running applications
  All R/3 applications run on software processors (virtual machines) within this component.
• User and process administration
  An R/3 System is a multi-user environment, and each user can run several independent applications. In short, this component is responsible for the tasks that usually belong to an operating system. Users log onto the R/3 System and run applications within it. In this way, they do not come into contact with the actual operating system of the host. The R/3 System is the only user of the host operating system.
• Database access
  Each R/3 System is linked to a database system, consisting of a database management system (DBMS) and the database itself. The applications do not communicate directly with the database. Instead, they use Basis services.
• Communication
  R/3 applications can communicate with other R/3 Systems and with non-SAP systems. It is also possible to access R/3 applications from external systems using a BAPI interface. The services required for communication are all part of the kernel and basis services component.
• System Monitoring and Administration
  The component contains programs that allow you to monitor and control the R/3 System while it is running, and to change its runtime parameters.

The ABAP Workbench component is a fully-fledged development environment for applications in the ABAP language. With it, you can create, edit, test, and organize application developments. It is fully integrated in the R/3 Basis system and, like other R/3 applications, is itself written in ABAP.

The presentation components are responsible for the interaction between the R/3 System and the user, and for desktop component integration (such as word processing and spreadsheets).

The database layer consists of a central database system containing all of the data in the R/3 System. The database system has two components - the database management system (DBMS), and the databse itself. SAP does not manufacture its own database. Instead, the R/3 System supports the following database systems from other suppliers: ADABAS D, DB2/400 (on AS/400), DB2/Common Server, DB2/MVS,INFORMIX, Microsoft SQL Server, ORACLE, and ORACLE Parallel Server.

The database does not only contain the master data and transaction data from your business applications, all data for the entire R/3 System is stored there. For example, the database contains the control and Customizing data that determine how your R/3 System runs. It also contains the program code for your applications. Applications consist of program code, screen definitions, menus, function modules, and various other components. These are stored in a special section of the database called the R/3 Repository, and are accordingly called Repository objects. You work with them in the ABAP Workbench.

The application layer consists of one or more application servers and a message server. Each application server contains a set of services used to run the R/3 System. Theoretically, you only need one application server to run an R/3 System. In practice, the services are distributed across more than one application server. This means that not all application servers will provide the full range of services. The message server is responsible for communication between the application servers. It passes requests from one application server to another within the system. It also contains information about application server groups and the current load balancing within them. It uses this information to choose an appropriate server when a user logs onto the system.

The presentation layer contains the software components that make up the SAPgui (graphical user interface). This layer is the interface between the R/3 System and its users. The R/3 System uses the SAPgui to provide an intuitive graphical user interface for entering and displaying data. The presentation layer sends the user’s input to the application server, and receives data for display from it. While a SAPgui component is running, it remains linked to a user’s terminal session in the R/3 System.

This software-oriented view can be expanded to include further layers, such as an Intenet Transaction Server (ITS).

The distribution of the R/3 software over three layers means that the system load is also distributed. This leads to better system performance.

Since the database system contains all of the data for the entire R/3 System, it is subject to a very heavy load when the sytsem is running. It is therefore a good idea not to run application programs on the same host. The architecture of the R/3 System, in which the application layer and database layer are separate, allows you to install them on separate hosts and let them communicate using the network.

It also makes sense to separate program execution from the tasks of processing user input and formatting data output. This is made possible by separating the presentation layer and the application layer. SAPgui and the application servers are designed so that the minimum amount of data has to be transported between the two layers. This means that the presentation layer components can even be used on hosts that have slow connections to application servers a long way away.

The system is highly scalable, due to the fact that the software components of an R/3 System can be distributed in almost any configuration across various hosts. This is particularly valuable in the application layer, where you can easily adapt your R/3 System to meet increasing demand by installing further application servers.

The fact that the application and presentation layers are separate carries an important consequence for application programmers. When you run an application program that requires user interaction, control of the program is continually passed backwards and forwards between the layers. When a screen is ready for user input, the presentation layer is active, and the application server is inactive with regard to that particular program, but free for other tasks. Once the user has entered data on the screen, program control passes back to the application layer. Now, the presentation layer is inactive. The SAPgui is still visible to the user during this time, and it is still displaying the screen, but it cannot accept user input The SAPgui does not become active again until the application program has called a new screen and sent it to the presentation server.

As a consequence, the program logic in an application program that occurs between two screens is known as a dialog step.

The following illustration represents a user-oriented view of the R/3 System:

For the user, the visible components of the R/3 System are those that appear as a window on the screen. The windows are generated by the presentation layer of the R/3 System, and form a part of the R/3 Basis system.

Before the user logs onto the R/3 System, he or she must start a utility called SAP Logon, which is installed at the front end. In SAP Logon, the user chooses one of the available R/3 Systems. The program then connects to the message server of that system and obtains the address of a suitable (most lightly-used) application server. It then starts a SAPgui, connected to that application server. The SAP Logon program is then no longer required for this connection.

SAPgui starts the logon screen. Once the user has successfully logged on, it displays the initial screen of the R/3 System in an R/3 window on the screen. Within SAPgui, the R/3 window is represented as a session. After logging on, the user can open up to five further sessions (R/3 windows) within the single SAPgui. These behave almost like independent SAPguis. The different sessions allow you to run different applications in parallel, independently of one another.

Within a session, the user can run applications that themselves call further windows (such as dialog boxes and graphic windows). These windows are not independent - they belong to the session from which they were called. These windows can be either modal (the original window is not ready for input) or amodal (both windows are ready for input).

The user can open other SAPguis, using SAP Logon, to log onto the same system or another R/3 System. The individual SAPguis and corresponding R/3 terminal sessions are totally independent. This means that you can have SAPguis representing the presentation layers of several R/3 Systems open on your desktop computer.

R/3 programs run on application servers. They are an important component of the R/3 System. The following sections describe application servers in more detail.

The application layer of an R/3 System is made up of the application servers and the message server. Application programs in an R/3 System are run on application servers. The application servers communicate with the presentation components, the database, and also with each other, using the message server.

The following diagram shows the structure of an application server:

The individual components are:

An application server contains work processes, which are components that can run an application. Each work process is linked to a memory area containing the context of the application being run. The context contains the current data for the application program. This needs to be available in each dialog step. Further information about the different types of work process is contained later on in this documentation.

Each application server contains a dispatcher. The dispatcher is the link between the work processes and the users logged onto the application server. Its task is to receive requests for dialog steps from the SAPgui and direct them to a free work process. In the same way, it directs screen output resulting from the dialog step back to the appropriate user.

Each application server contains a gateway. This is the interface for the R/3 communication protocols (RFC, CPI/C). It can communicate with other application servers in the same R/3 System, with other R/3 Systems, with R/2 Systems, or with non-SAP systems.

The application server structure as described here aids the performance and scalability of the entire R/3 System. The fixed number of work processes and dispatching of dialog steps leads to optimal memory use, since it means that certain components and the memory areas of a work process are application-independent and reusable. The fact that the individual work processes work independently makes them suitable for a multi-procecssor architecuture. The methods used in the dispatcher to distribute tasks to work processes are discussed more closely in the section Dispatching Dialog Steps.

When you start up an R/3 System, each application server registers its work proceses with the database layer, and receives a single dedicated channel for each. While the system is running, each work process is a user (client) of the database system (server). You cannot change the work process registration while the system is running. Neither can you reassign a database channel from one work process to another. For this reason, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. This has important consequences for the programming model explained below.

The number of users logged onto an application server is often many times greater than the number of available work processes. Furthermore, it is not restricted by the R/3 system architecture. Furthermore, each user can run several applications at once. The dispatcher has the important task of distributing all dialog steps among the work processes on the application server.

The following diagram is an example of how this might happen:

1. The dispatcher receives the request to execute a dialog step from user 1 and directs it to work process 1, which happens to be free. The work process addresses the context of the application program (in shared memory) and executes the dialog step. It then becomes free again.
2. The dispatcher receives the request to execute a dialog step from user 2 and directs it to work process 1, which is now free again. The work process executes the dialog step as in step 1.
3. While work process 1 is still working, the dispatcher receives a further request from user 1 and directs it to work process 2, which is free.
4. After work processes 1 and 2 have finished processing their dialog steps, the dispatcher receives another request from user 1 and directs it to work process 1, which is free again.
5. While work process 1 is still working, the dispatcher receives a further request from user 2 and directs it to work process 2, which is free.

From this example, we can see that:

• A dialog step from a program is assigned to a single work process for execution.
• The individual dialog steps of a program can be executed on different work processes, and the program context must be addressed for each new work process.
• A work process can execute dialog steps of different programs from different users.

The example does not show that the dispatcher tries to distribute the requests to the work processes such that the same work process is used as often as possible for the successive dialog steps in an application. This is useful, since it saves the program context having to be addressed each time a dialog step is executed.

The separation of application and presentation layer made it necessary to split up application programs into dialog steps. This, and the fact that dialog steps are dispatched to individual work processes, has had important consequences for the programming model.

As mentioned above, a work process can only make database changes within a single database logical unit of work (LUW). A database LUW is an inseparable sequence of database operations. The contents of the database must be consistent at its beginning and end. The beginning and end of a database LUW are defined by a commit command to the database system (database commit). During a database LUW, that is, between two database commits, the database system itself ensures consistency within the database. In other words, it takes over tasks such as locking database entries while they are being edited, or restoring the old data (rollback) if a step terminates in an error.

A typical SAP application program extends over several screens and the corresponding dialog steps. The user requests database changes on the individual screens that should lead to the database being consistent once the screens have all been processed. However, the individual dialog steps run on different work processes, and a single work process can process dialog steps from other applications. It is clear that two or more independent applications whose dialog steps happen to be processed on the same work process cannot be allowed to work with the same database LUW.

Consequently, a work process must open a separate datables LUW for each dialog step. The work process sends a commit command (database commit) to the database at the end of each dialog step in which it makes database changes. These commit commands are called implicit database commits, since they are not explicitly written into the application program.

These implicit database commits mean that a database LUW can be kept open for a maximum of one dialog step. This leads to a considerable reduction in database load, serialization, and deadlocks, and enables a large number of users to use the same system.

However, the question now arises of how this method (1 dialog step = 1 database LUW) can be reconciled with the demand to make commits and rollbacks dependent on the logical flow of the application program instead of the technical distribution of dialog steps. Database update requests that depend on one another form logical units in the program that extend over more than one dialog step. The database changes associated with these logical units must be executed together and must also be able to be undone together.

The SAP programming model contains a seies of bundling techniques that allow you to group database updates together in logical units. The section of an R/3 application program that bundles a set of logically-associated database operations is called an SAP LUW. Unlike a database LUW, a SAP LUW includes all of the dialog steps in a logical unit, including the database update.

Work processes execute the individual dialog steps in R/3 applications. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in the R/3 System.

Work processes execute the dialog steps of application programs. They are components of an application server. The following diagram shows the components of a work process:

Each work process contains two software processors and a database interface.

In R/3 application programming, there is a difference between user interaction and processing logic. From a programming point of view, user interaction is controlled by screens. As well as the actual input mask, a screen also consists of flow logic. The screen flow logic controls a large part of the user interaction. The R/3 Basis system contains a special language for programming screen flow logic. The screen processor executes the screen flow logic. Via the dispatcher, it takes over the responsibility for communication between the work process and the SAPgui, calls modules in the flow logic, and ensures that the field contents are transferred from the screen to the flow logic.

The actual processing logic of an application program is written in ABAP - SAP’s own programing language. The ABAP processor executes the processing logic of the application program, and communicates with the database interface. The screen processor tells the ABAP processor which module of the screen flow logic should be processed next. The following screen illustrates the interaction between the screen and the ABAP processors when an application program is running.

Although all work processes contain the components described above, they can still be divided into different types. The type of a work process determines the kind of task for which it is responsible in the application server. It does not specify a particular set of technical attributes. The individual tasks are distributed to the work processes by the dispatcher.

Before you start your R/3 System, you determine how many work processes it will have, and what their types will be. The dispatcher starts the work processes and only assigns them tasks that correspond to their type. This means that you can distribute work process types to optimize the use of the resources on your application servers.

The following diagram shows again the structure of an application server, but this time, includes the various possible work process types:

The various work processes are described briefly below. Other parts of this documentation describe the individual components of the application server and the R/3 System in more detail.

Dialog work processes deal with requests from an active user to execute dialog steps.

Update work processes execute database update requests. Update requests are part of an SAP LUW that bundle the database operations resulting from the dialog in a database LUW for processing in the background.

Background work processes process programs that can be executed without user interaction (background jobs).

The enqueue work process administers a lock table in the shared memory area. The lock table contains the logical database locks for the R/3 System and is an important part of the SAP LUW concept. In an R/3 System, you may only have one lock table. You may therefore also only have one application server with enqueue work processes.

The spool work process passes sequential datasets to a printer or to optical archiving. Each application server may contain only one spool work process.

The services offered by an application server are determined by the types of its work processes. One application server may, of course, have more than one function. For example, it may be both a dialog server and the enqueue server, if it has several dialog work processes and an enqueue work process.

You can use the system administration functions to switch a work process between dialog and background modes while the system is still running. This allows you, for example, to switch an R/3 System between day and night operation, where you have more dialog than background work processes during the day, and the other way around during the night.

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.

As described in the Overview of the R/3 Basis System, a work process contains a screen processor for processing user input, an ABAP processor for processing the program logic, and a database interface for communicating with the database. These components of a work process determine the following structure of an applciation program:

An application program consists of two components, each of which has a different task:

Flow Logic

Processing 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.

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 selection screen is then generated according to these statements. 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, the ABAP runtime environment 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.

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 procedures (methods, subroutines, function modules) form the declaration part for local data in those processing blocks. This data is only visible within the procedure 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)
• Procedures (methods, subroutines and function modules with their own local data area).

Whereas dialog modules and procedures 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.

When you run an ABAP program, you call its processing blocks. ABAP programs are controlled from outside the program itself by the processors in the current work process. For the purposes of program flow, we can summarize the screen processor and ABAP processor into the ABAP runtime environment. The runtime environment controls screens and ABAP processing blocks. It contains a range of special control patterns that call screens and processing blocks in certain orders. These sections are also called processors. When you run an ABAP program, the control passes between various processors.

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 runtime environment calls its processing blocks.

When you run an application program, you must call at least the first processing block from outside the program, that is, from the runtime environment. This processing block can then either call further processing blocks or return control to the runtime environment. When you start an ABAP program, the runtime environment starts a processor (dependent on the program type), which calls the first ABAP processing block. An ABAP program can be started either by the user or by the system (for example, in background processing), or through an external interface (for example, Remote Function Call).

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:

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, whcih 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 intial screen can be a selection screen).

When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding 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. Each screen has a following screen, set either statically or dynamically.
• call other sequences of 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 procedures that you can call from other ABAP programs.

Type F programs are known as function groups. Function modules may only be programmed in 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.

You cannot start type K programs using a transaction code or by entering the program name. They are containers for global classes in ABAP Objects . Type K programs are known as class definitions. The Class Builder is a tool in the ABAP Workbench that you can use to create class definitions.

You cannot start type J programs using a transaction code or by entering the program name. They are containers for global interface in ABAP Objects . Type J programs are known as interface definitions. Like class definitions, you create interface definitions in the Class Builder.

You cannot start a type S program using a transaction code or by entering the program name. Instead, they are containers for subroutines, which you can call externally from other ABAP programs. Type S programs are known as subroutine pools. They cannot contain screens.

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 explain the different processing blocks in ABAP programs and how they are called.

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. The interaction between the flow logic and the screen is controlled by a dialog processor.

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 notdefine dialog screens in the ABAP programs.

A selection screen is a special kind of dialog screen that you create using ABAP commands in the declaration part of the program. The different events in a selection screen (PAI, PBO, user input), are controlled by a selection screen processor. You can program processing logic for these events in your program. The selection screen processor controls the flow logic of the selection screen.

You do not have to create the screen flow logic yourself, neither can you create your own dialog modules for the PBO or PAI events . 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). The list processor displays the list on the screen and handles user actions within lists. The list processor controls the flow logic of the list. You do not have to create the screen flow logic yourself, neither can you create your own dialog modules for the PBO or PAI events .

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). You can program processing logic for the interactive list events in your program. Data is transferred from list to ABAP program via system fields or an internal memory area called the HIDE area.

You call subroutines from ABAP programs using the PERFORM statement.

Subroutines are introduced with the FORM statement and concluded with the ENDFORM 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 external functions with a defined interface. You call function modules from ABAP programs using the CALL FUNCTION statement.

Function modules are introduced with the FUNCTION statement and concluded with the ENDFUNCTION statement.

You can only create function groups within special ABAP programs called function groups using the Function Builder. This means that you can only call them externally from other ABAP programs. Unlike subroutines, you always pass data to function modules using an explicit parameter interface.

Methods describe the functions of classes in ABAP Objects. Like function modules, they have a defined interface. You call methods from ABAP programs using the CALL METHOD statement.

Methods are introduced with the METHOD statement and concluded with the ENDMETHOD statement.

Methods can only be defined in the implementation parts of classes. You can either do this globally in the Class Builder, or locally within ABAP programs. Methods can work with the attributes of their class and with data that you pass to them using their explicit parameter interface.

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 category of the statements. The different statement categories are as follows:

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:

TYPES, DATA, TABLES

These statements define the processing blocks in an ABAP program.

The modularization keywords can be further divided into:

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

Examples of control keywords:

IF, WHILE, CASE

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:

PERFORM, CALL, SET USER-COMMAND, SUBMIT, LEAVE TO

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

Examples of operational keywords:

WRITE, MOVE, ADD

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

Open SQL is a subset of the standard SQL92 language. It contains only Data Manipulation Language (DML) statements, such as SELECT, IINSERT, 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

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 thie 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:

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 aggregated 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:

You use references to refer to objects in ABAP Objects. References are stored in reference variables. The data type of the reference determines how it is handled in the program. There are different types for class and interface variables.

Reference variables in ABAP are treated like other elementary data objects. This means that a reference variable can occur as a component of a structure or internal table as well as on its own.

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. The exception to this are 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.

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 runtime environment 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). From Release 4.5A, it is also possible to call logical databases on their own.

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 runtime environment 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. These subrotuines are called by the reporting processor in the runtime environment in a predefined sequence.

Uses of Logical Databases

Contexts

The name of an ABAP program can be between 1 and 30 characters long. It cannot contain any of the following characters: Period (.), comma (,), space (), parentheses (), apostrophe (‘), inverted commas ("), equals sign (=), asterisk (*), accented characters or German umlauts (à, é, ø, ä, ß, and so on), percentage signs (%), or underscores (_).

Enter the name of an existing development class in the object list and choose Display. The system displays a hierarchical overview of all R/3 Repository objects belonging to the specified development class.

You now have several possibilities:

• If the Programs node does not exist on the screen, you can create a program by positioning the cursor on the Object Types Development Class node and choosing Create.

• If the Programs node already exists on the screen, you can position the cursor on it and choose Create to create a new program.
• In this case, you can also expand the node to display all of the programs belonging to the development class.

The Repository Browser displays the program as a tree structure with the program as its root node and the individual program components as subnodes. Note that selecting other components of the program does not open the ABAP Editor to display the source code of the program, but always the appripriate tool for the selected component. In special cases, such as for include programs, this can also be the ABAP Editor. However, you then edit only the component and not the source code of the entire program.

If the program does not exist, choose Create. The ABAP: Program Attributes screen appears, on which you must enter the program attributes.

If you create a program in this way, the system does not offer to create a Top include. This way of creating programs is therefore best suited for reports and short test programs. Once you have entered and saved the program attributes, the new program exists in the R/3 Repository.

The following section provides information about program attributes. Note that some of these attributes only apply to executable programs (reports), and not to other ABAP program types. The field help and possible values help for the fields on the ABAP: Program Attributes screen provide further information.

These fields are used for version administration. The system fills them.

In the required entry field Title enter a program description that describes the function of the program. The system automatically includes the title into the text elements of the program. Thus, you can edit the title when maintaining the text elements.

The maintenance language is the logon language of the user who creates the program. The system fills this field automatically. You can change the maintenance language, if you maintain the program or its components in another logon language.

In the Type field, you must specify the execution mode of your program.

Use Type 1 (report) to declare your program as executable.. This means that the program can run on its own, and that you can start it in the R/3 system without a transaction code. You can also run executable programs (reports) in the background.

Use Type M to declare your program as a module pool. This means that your program cannot run on its own, but serves as a frame for program modules used for dialog programming. These program modules contain the application logic of a transaction and are called by a separately programmed screen flow logic (programming screens using the Screen Painter tool). The screen flow logic itself can be called via a transaction code only.

Apart form type 1 (for executable programs (reports)) and type M (for module pools), you should also know Type I for include programs. An inlcude program is an independent program with two main functions: On one hand, it contains program code that can be used by different programs. On the other hand, it modularizes source code, which consists of several different, logically related parts. Each of these parts is stored in a different include program. Include programs make your source code easier to read and maintain.

This entry describes the status of the program development; for example, T for test program.

If you do not want the ABAP Editor to change the case of your code when you display the program, leave this field empty. If you select it, the program code (apart from literals and comments) is converted to uppercase. The screen display depends on the Editor mode.

If you set this attribute, other users cannot change, rename, or delete your program. Only you will be able to change the program, its attributes, text elements, and documentation, or release the lock.

If the attribute Fixed point arithmetic is set for a program, the system rounds type P fields according to the number of decimal places or pads them with zeros. The decimal sign in this case is always the period (.), regardless of the user’s personal settings. We recommend that you always set the fixed point arithmetic attribute.

The following gives a short overview on how to structure a program. Apart from the first statement, the sequence of statements is not obligatory, but you should keep to it for reasons of clarity and readability.

1. The first program statement

The first statement of an ABAP program must always be the statement REPORT or PROGRAM, respectively (only exception: FUNCTION-POOL for function modules). Both statements have exactly the same function.

The name specified in the statements REPORT and PROGRAM must not necessarily be the program name, but for documentation reasons, you should use the correct name.

The statements REPORT or PROGRAM can have several options, such as LINE-SIZE, LINE-COUNT, or NO STANDARD PAGE HEADING. You use these options mainly in programs that which evaluate data and display the results in a list. For other options, such as the definition of a message class, see the key word documentation.

Whenever you create a new program, the system automatically inserts the first ABAP statement, for example:

REPORT . for executable programs (reports) or

PROGRAM . for dialog programs

As report or program name, the system enters the name you used to create the program.

2. Data declaration

Next, insert all of your delclarations. This includes the global data definitions, selection screen definitions, and the definitions of classes and interfaces in ABAP Objects.

3. Processing logic

After the declarations, write the processing logic. This consists of a series of processing blocks.

4. Subroutines

Using includes to split up a program into a series of source code modules does not change this basic structure. If, for example, you follow the forward navigation of the ABAP Workbench when creating a dialog program, the system automatically creates a number of include programs, which contain the program parts described above in the correct sequence. The top include program usually contains the PROGRAM statement and the global data declaration. The subsequent include programs contain the individual dialog modules, ordered by PBO and PAI. There may also be further includes, for example, for subroutines. These include programs do not influence the program function, they only serve to make the program order easier to understand.

A high-quality ABAP program observes the following layout standards:

You should combine statements that belong together into a single block. Indent each block by at least two columns:

Make your programs easier to understand by using modules. For example, writing a large processing block as a subroutine makes the logical structure of your program easier to recognize. Subroutines may increase the overall length of programs, but you will soon find that this method greatly increases clarity, especially in the case of complex programs.

In the ABAP Editor, you can use statement patterns to help you write your program. They provide the exact syntax of a statement and follow the ABAP layout guidelines. You can insert two kinds of predefined structures into your program code when using the ABAP Editor: Keyword structures and comment lines. In the ABAP Editor, choose Edit ® Insert statement. To display a list of all predefined keyword structures, place the cursor in the Other pattern. field and click the possible entries button to the right of the input field.

When you have finished editing, or reach an intermediate stage of the program, choose Check to check the syntax. The system checks the program coding for syntax errors and compatibility problems. If it finds an error, it displays a message describing it and, if possible, offers a solution or correction. The system positions the cursor on the error in the coding. Once you decide that your program is finished, run the extended program check on it by choosing Program ® Check ® Ext. program check from the Editor screen. Ensure that you correct all of the errors and warnings displayed. Although they do not prevent the program from working, they are not examples of good programming. Furthermore, some warnings might be escalated to syntax errors in future releases.

Choose Save to save the source code.

The system stores the source code in the program library. Before you can execute the program from outside the ABAP Editor, you must generate an active version using the Activate function.

ABAP has no format restrictions. You can enter statements in any format, so a statement can be indented, you can write several statements on one line, or spread a single statement over several lines.

You must separate words within a statement with at least one space. The system also interprets the end of line marker as a space.

Use this free formatting to make your programs easier to understand.

The ABAP programming language allows you to concatenate consecutive statements with an identical first part into a chain statement.

To concatenate a sequence of separate statements, write the identical part only once and place a colon (:) after it. After the colon, write the remaining parts of the individual statements, separating them with commas. Ensure that you place a period (.) after the last part to inform the system where the chain ends.

In a chain statement, the first part (before the colon) is not limited to the keyword of the statements.

Comments are texts that you can write between the statements of your ABAP program to explain their purpose to a reader. Comments are distinguished by the preceding signs * (at the beginning of a line) and " (at any position in a line). If you want the entire line to be a comment, enter an asterisk (*) at the beginning of the line. The system then ignores the entire line when it generates the program. If you want part of a line to be a comment, enter a double quotation mark (") before the comment. The system interprets comments indicated by double quotation marks as spaces.