Компьютерный язык ABAP/4. ABAP Development Tools for SAP NetWeaver

The following sections explain what SAP NetWeaver Application Server ABAP (SAP NetWeaver AS ABAP or SAP NetWeaver Application Server ABAP, for short) is. You can also find information on work processes, which are components of ABAP application servers.

Overview of SAP NetWeaver AS ABAP

The difference between the logical view and a hardware- or software-oriented view of SAP NetWeaver AS ABAP is that not all of the components shown can be assigned to a particular hardware or software unit. The following illustration represents this logical view in form of a block diagram.

The following is a list of the tasks of the three logical components in SAP NetWeaver AS ABAP.

The kernel and administration services component is a runtime environment for all ABAP applications that is hardware-, operating system- and database-independent. The ABAP runtime environment is written principally in C and C++. However, some low-level parts are also written in ABAP itself. The tasks of the kernel and administration services component are as follows:

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 these application programs. It is fully integrated in SAP NetWeaver AS ABAP and, like other ABAP applications, is itself written in ABAP.

The presentation components are responsible for the interaction between the ABAP applications and the user (input and output) and for desktop component integration (such as word processing and spreadsheets) into the SAP NetWeaver Application Server.

The following illustration represents the software-oriented view of an SAP System. In an ABAP-based SAP System, SAP NetWeaver AS ABAP comprises all SAP GUI components and the ABAP application servers.

An SAP System is a multi-tier client/server system. The individual software components are arranged in tiers and function, depending on their position, as a client for the components below them or a server for the components above them. The classic configuration of an SAP System contains the following software layers:

The database layer, which is accessed by SAP NetWeaver AS, consists of a central database system which in turn is made up of the database management system (DBMS) and the database itself.

The database does not only contain the master data and transaction data from your ABAP application programs; all data for SAP NetWeaver AS ABAP is stored there. For example, the database contains the control and Customizing data that determines how SAP NetWeaver AS runs and the ABAP application programs themselves. The components (program texts, screen definitions, menus, function modules, and so on) are stored in a special part of the database known as the Repository, and are therefore also referred to as Repository objects. You work with them in the ABAP Workbench.

The software components of the application layer of SAP NetWeaver AS ABAP consist of one or more ABAP application servers and a message server. Each application server contains a set of services used to run the SAP NetWeaver Application Server. Theoretically, you only need one application server to run a SAP NetWeaver Application Server. 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 a SAP NetWeaver Application Server. 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.

This layer is the interface between the SAP System and its users. Using its software components referred to as SAP GUI (Graphical User Interface) this layer provides an intuitive graphical 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 SAP GUI component is running, it remains linked to a user's terminal session in SAP NetWeaver AS ABAP.

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

The software-oriented view has nothing to do with the hardware configuration of the system. There are many different hardware configuration possibilities for both layers and components. When distributing the layers, for example, you can have all layers on a single host, or, at the other extreme, you could have at least one host for each layer. When dealing with components, the distribution of the database components depends on the database system you are using. The application layer and presentation layer components can be distributed across any number of hosts. It is also possible to install more than one ABAP application server on a single host. A common configuration is to run the database system and a single ABAP application server (containing special database services) on one host, and to run each further application server on its own host. The presentation layer components usually run on the desktop computers of the users.

The distribution of the SAP System over three layers means that the system load is also distributed. This leads to better system performance. Another benefit is the high scalability achieved due to the fact that you can distribute the software components of an SAP System among different hardware units virtually without any restrictions. This is particularly valuable in the application layer, where you can easily adapt SAP NetWeaver AS ABAP to meet increasing demand by installing further ABAP application servers.

The architecture of the SAP System allows you to install the application layer and the database layer on separate hosts and let them communicate using the network. This considerably reduces the load placed on the database system which contains the central data storage for SAP NetWeaver AS ABAP and therefore needs to fulfill high demands while the system is running.

Likewise, the separation of the presentation and the application layer reduces the load placed on the ABAP application servers by isolating user entry processing and data output formatting from actual program execution. It is important to note that the SAP GUI and the ABAP application server are set up in a way that reduces the movement of data between the two layers to the smallest possible degree. As a result, the components of the presentation layer can even be used on hosts that have slow connections to application servers a long way away.

For the user, the visible components of the SAP System are those that appear as a window on the screen. These windows are created by the presentation layer of SAP NetWeaver AS ABAP.

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

SAP GUI starts the logon screen. Once the user has successfully logged on, it displays the initial screen of the SAP System in a window on the screen. Within SAP GUI, each window is represented as a session. After logging on, the user can open up to five further sessions within the single SAP GUI. These behave almost like independent SAP applications. 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 and interact with each other).

The user can open other SAP GUIs, using SAP Logon, to log onto the same system or another SAP System. The individual SAP GUIs and corresponding terminal sessions of a user are totally independent. This means that you can have SAP GUIs representing the presentation layers of several SAP Syste

ABAP Application Server

ABAP application servers are important software components of SAP NetWeaver AS ABAP since all ABAP progrums run on these servers. The following sections describe the structure and functions of these application servers in more detail.

All ABAP application servers including the message server represent the application layer of the multi-tier architecture of an ABAP-based SAP System. These application servers execute ABAP applications and communicate with the presentation components, the database, and also with each other, using the message server.

In addition to several work processes whose number and type are determined at the startup of SAP NetWeaver AS ABAP, each ABAP application server contains a dispatcher, a gateway and the shared memory. The tasks of these components are briefly described in the following:

Work processes are components that are able to execute an application (that is, one dialog step each). 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.

The dispatcher is the link between the work processes and the users logged onto the ABAP application server (that is, the SAP GUIs of theseusers). Its task is to receive requests for dialog steps from the SAP GUI 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.

This is the interface for the communication protocols of SAP NetWeaver AS ABAP (RFC, CPI/C). It can communicate with other ABAP application servers of the same SAP NetWeaver Application Server, with other SAP Systems, or with external non-SAP systems.

All of the work processes on an ABAP application server use a common main memory area called shared memory to save contexts or to buffer constant data locally.

The resources that all work processes use (such as programs and table contents) are contained in shared memory. Memory management in the SAP NetWeaver AS ABAP ensures that the work processes always address the correct context, that is the data relevant to the current state of the program that is running. A mapping process projects the required context for a dialog step from shared memory into the address of the relevant work process. This reduces the actual copying to a minimum.

The structure of the ABAP application servers described here supports the performance and scalability of SAP NetWeaver AS ABAP. 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-processor architecture.

Local buffering of data in the shared memory of the ABAP application server reduces the number of database reads required. This reduces access times for ABAP application programs considerably. For optimal use of the buffer, you can concentrate individual applications (financial accounting, logistics, human resources) into separate ABAP application server groups.

When you start up a SAP NetWeaver AS ABAP, each ABAP application server registers its work processes with the database layer, and receives a single dedicated channel for each. While the SAP NetWeaver Application Server 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), that is an inseparable sequence of database operations.

Work Processes

Work processes execute the individual dialog steps of ABAP application programs. They are components of ABAP application servers. The next two sections describe firstly the structure of a work process, and secondly the different types of work process in SAP NetWeaver AS ABAP.

In ABAP 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, which controls a large part of the user interaction. SAP NetWeaver AS ABAP 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 programming 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.

The following diagram shows the individual components of the database interface:

The diagram shows that there are two different ways of accessing databases: Open SQL and Native SQL.

Open SQL statements are a subset of Standard SQL that is fully integrated in ABAP. They allow you to access data irrespective of the database system that your installation is using. Open SQL consists of the Data Manipulation Language (DML) part of Standard SQL; in other words, it allows you to read (SELECT) and change (INSERT, UPDATE, DELETE) data. The tasks of the Data Definition Language (DDL) and Data Control Language (DCL) parts of Standard SQL are performed in SAP NetWeaver AS ABAP by the ABAP Dictionary and the authorization system. These provide a unified range of functions, irrespective of database, and also contain functions beyond those offered by the various database systems.

Open SQL also goes beyond Standard SQL to provide statements that, in conjunction with other ABAP constructions, can simplify or speed up database access. It also allows you to buffer certain tables on the ABAP application server, saving excessive database access. In this case, the database interface is responsible for comparing the buffer with the database. Buffers are partly stored in the working memory of the current work process, and partly in the shared memory for all work processes on an ABAP application server. Where SAP NetWeaver AS ABAP is distributed across more than one ABAP application server, the data in the various buffers is synchronized at set intervals by the buffer management. When buffering the database, you must remember that data in the buffer is not always up to date. For this reason, you should only use the buffer for data which does not often change.

Native SQL is only loosely integrated into ABAP, and allows access to all of the functions contained in the programming interface of the respective database system. In Native SQL, you can primarily use database-specific SQL statements. The Native SQL interface sends them as is to the database system where they are executed. You can use the full SQL language scope of the respective database which makes all programs using Native SQL specific for the database system installed. In addition, there is a small set of SAP-specific Native SQL statements which are handled in a special way by the Native SQL interface. ABAP applications contain as little Native SQL as possible. In fact, it is only used in a few components (for example, to create or change table definitions in the ABAP Dictionary).

The database-dependent layer in the diagram serves to hide the differences between database systems from the rest of the database interface. You choose the appropriate layer when you install SAP NetWeaver AS ABAP. Thanks to the standardization of SQL, the differences in the syntax of statements are very slight. However, the semantics and behavior of the statements have not been fully standardized, and the differences in these areas can be greater. When you use Native SQL, the function of the database-dependent layer is minimal.

Before you start SAP NetWeaver AS ABAP, you determine how many work processes each ABAP application server will have, and what their types will be. Since all work processes have the same structure (see preceding section), the type of work process does not determine the technical attrributes of the ABAP application server but the type of tasks to be performed on it. 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 ABAP application servers.

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

Dialog work processes deal with requests from an active user to execute dialog steps (see also Dialog Programming ).

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 SAP NetWeaver AS ABAP and is an important part of the SAP LUW concept. In SAP NetWeaver Application Server, you may only have one lock table. You may therefore also only have one ABAP application server with enqueue work processes. Normally, a single enqueue work process is sufficient to perform the required tasks.

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

The types of its work processes determine the services that an ABAP application server offers. The 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 SAP 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.

Creating and Changing ABAP Programs

ABAP programs are objects of the Repository. You maintain them, as is the case with all other Repository objects (such as ABAP Dictionary tables or screen UIs), using an ABAP Workbench tool - in this case, the ABAP Editor.

This section provides a brief description of the ABAP Workbench and an overview of how to create and edit ABAP programs. It describes the different ways of starting the ABAP Editor. In the text below, 'open a program' always means 'start the ABAP Editor and use it to open a program'.

To start the ABAP Editor to create or change ABAP programs, SAP NetWeaver AS ABAP offers three possibilities:

The Object Navigator of the ABAP Workbench (Transaction SE80) offers a hierarchical overview of all Repository objects, ordered by package, user name of the programmer, object types, and so on. By selecting a program, the Object Navigator supplies direct access to all components of a program, such as main program, includes, classes, or global data. By selecting a program object in the Object Navigator and calling a maintenance transaction, you directly open the appropriate tool for this object, as, for example, the ABAP Editor for the program source code or the Class Builder for classes.

This way is appropriate for all ABAP programs, as the Object Navigator gives you a constant overview of all components of a program. In particular, screens and user interfaces are displayed.

To open ABAP programs directly from the ABAP Editor tool, select the ABAP Editor node under ABAP Workbench → Development from the SAP standard menu of the user interface SAP Easy Access (or start Transaction SE38). If you want to change a program using this method, you must already know its name and environment.

This procedure is only suited for maintaining or creating relatively simple or short programs, which have few or no additional components.

In any of the tools in the ABAP Workbench, you can open a different Repository object by positioning the cursor on it and double-clicking. The system automatically opens the object using the correct tool. This also applies to editing ABAP programs.

Forward navigation by double-click can be used at any point where the names of ABAP programs appear in the ABAP Workbench.

The name of an ABAP program can be between 1 and 30 characters long. It cannot contain any of the following characters: period (.), comma (,), blank ( ), parentheses '( )', apostrophe ('), quotation marks ("), equals sign (=), asterisk (*), umlaut dots (Ä, ä, Ö, ö, Ü, ü) or ß, percentage symbol (%), and hyphen (-).

Like many other Repository objects, ABAP programs have attributes, which are important in determining the function of the program within SAP NetWeaver AS ABAP. For an overview of program attributes, refer to Maintaining Program Attributes.

ABAP source code defines the processing logic of ABAP application programs. Editing Programs provides you with an introduction to writing ABAP source code.

Executing ABAP Program Units

ABAP programs can be executed only on a SAP NetWeaver Application Server ABAP. The SAP NetWeaver Application Server ABAP contains a component Kernel & Management Services, which serves as the platform-independent runtime environment for ABAP programs (see SAP NetWeaver AS ABAP: Overview ).

Each ABAP program consists of self-contained processing blocks, which may occur in any order in the source code. Processing blocks are sections of programs, made up of structure blocks. They are processed sequentially. A processing block can be called either from outside the ABAP program, or from a processing block within the same ABAP program (see also Structure of the Processing Logic ). When a processing block is called from outside the program, it can be called either by the ABAP runtime environment or another ABAP program.

To start an ABAP program, at least one of its processing blocks must be started from outside the program itself. Each ABAP program has a program type, which determines whether and how a program can be run.

These programs can be run by a user by entering the program name or a transaction code. They are the actual application programs, and are explained in more depth later on.

Executable programscan be started by entering the program name. When you start an executable program, processors are started in the runtime environment that call a series of processing blocks (event blocks) in a predefined sequence. The sequence is oriented towards reporting tasks. This is why executable programs were also known as reports. For more information, see Direct Execution .

A special property of executable programs is the fact that they can be linked to logical databases. A logical database contains subroutines that are called by an invisible system program in a prescribed sequence for executable programs. The subroutines make certain reporting functions reusable. For further information, refer to Logical Databases .

You can only start module pools using a transaction code. A transaction code starts a screen, which consists of the screen itself and its flow logic. Screen flow logic can call special processing blocks (dialog modules) in the corresponding ABAP program. They are named module pools after these dialog modules. For more information on executing modules pools, see Transactions.

As of release 6.10, the public methods of global and local classes can be attached to transaction codes, which makes their framework programs "executable" via transaction codes.

These programs cannot be started directly by a user. Instead, they contain processing blocks or other source code that can only be used by an application program that is already running. They are described in more detail in a later section.

They serve as a container for function modules. When you call a function module from an ABAP program, the entire main program is loaded into the internal session of the current program. Function modules are a type of procedure. They are described in more detail in the Procedures section.

Class pools serve as containers for global classes. Classes belong to ABAP Objects and are described in more detail in that section.

Interface pools serve as containers for global interfaces. Interfaces belong to ABAP Objects and are described in more detail in that section.

Subroutine pools are container programs for subroutines that should only be called externally. When you call a subroutine from an ABAP program, the entire main program is loaded into the internal session of the current program. Subroutines are a type of procedure. They are described in more detail in the Procedures section.

Include programs do not contain any callable processing blocks. They are used exclusively for modularizing ABAP source code, and are included in other programs. Include programs are described in more detail in the Source Code Modules section.

As of release 6.10, function groups, class pools and subroutine pools can be started via transaction codes, which are attached to the public methods of local or global classes of these programs.

For all programs that can be started directly, there are ABAP statements that you can use to call a program from another application program that is already running. For further information, refer to Calling Programs .

Знаете ли Вы, что дескриптивные модели - это модели, целью которых является формализованное представление знания о структуре моделируемого объекта.