The System Central Interfaces SAP BASIS

In this section the main system interfaces are described in greater detail. The R/3 middleware or common kernel is made up of central interfaces. These are as follows:

  • The interface with the operating system.
  • The interface with database.
  • The interface for presentation.
  • The communication interface could be seen as a special type of interface that directly or indirectly is present in the other three types.

For compatibility and portability reasons, all these interfaces are grouped together in the central interface functions of the SAP system kernel. The interfaces in the SAP system are a group of software programs running as daemon processes in the UNIX operating system or as services on Windows NT, which is a background process.

Operating System Interface

One of the main tasks of the basis system is to guarantee the portability of the whole system. That is done using an internal SAP portability layer. This layer offers to the applications the nearest services to the system, such as message handling and memory management, independently of the platform and optimized for performance. The inherent openness of R/3 makes it run over different operating systems, which have to be Portable Operating System Interface (POSIX) standard-compliant. For a list of supported technical and platform environments for a specific SAP release, refer to (Product Availability Matrix section).

The mission of the system interfaces is to provide services such as scheduling, memory management, and similar tasks, which could be partially done by the operating system software, but SAP executes them internally for performance and portability reasons. The SAP systems runtime environment, commonly known as the kernel, is written in ANSI-C or C++, but all application programs inside R/3 are written in the interpreted programming language ABAP developed by SAP. Currently, with the SAP Web Application Server, there are other options, such as Java, which will be covered later in this chapter.

In ABAP transactions (Java or BSPs), the components in charge of controlling the user dialogs are the dynpros (dynamic programs). The technology base for the R/3 applications is made up of the interrelation of the dynpro interpreters and the ABAP language. For their tasks, both use the global image of the data environment of R/3, which is held on the ABAP dictionary. The runtime environment of the R/3 applications consists of two processors: one for the dynpros and the other for the ABAP language.

The SAP Web AS has three installation options, the SAP Web AS ABAP, Java System, and ABAP + Java System. The J2EE engine is a key component of the SAP Web Application Sever. The SAP Web Application Server implements the J2EE Standards. From the point of view of the operating system in the SAP Web AS ABAP installations, the runtime system of SAP Web AS is a platform (virtual machine) of an ABAP program that is independent of hardware, the operating system, and the database and can be seen as a group of parallel processes (work processes). Among these processes there is a special one, the dispatcher, which controls and assigns tasks to the other processes.

The Dispatcher Process

The SAP dispatcher is the control program that manages the resources of the Web AS applications. It works like a typical transaction monitor that receives screens and data from the presentation services and passes them to the corresponding work processes.

SAP dispatcher process

SAP dispatcher process

The work processes are special programs in charge of some specific tasks. Using client/server terminology, a work process is a service offered by a server and requested by a client. The dispatcher manages the information exchange between the SAP GUIs or other type of presentation interface and the work processes, enabling users to share the different work processes available. The main tasks of the dispatcher are as follows:

• Balanced assignment of the transaction load to the work processes
• Connection with the presentation level
• Organization of the communication processes

The logical flow of execution of a user request follows:

  1. Users enter data in their presentation server; the data are received by the SAP GUI, converted to a SAP format, and sent to the dispatcher using a special optimized protocol called DIAG. The DIAG protocol is also used for ITS-driven applications.
  2. Initially, the dispatcher keeps the requests in queues, where the dispatcher later processes them one by one.
  3. The dispatcher allocates the user requests using the free work processes. The real execution takes place inside the work processes themselves.
  4. At the end of execution, the result of the work process task goes back to the SAP GUI through the dispatcher. SAP GUI interprets the received data and fills up the user screen.

SAP has optimized the data flow between the presentation and the application servers. Before release 4.6 and the enjoySAP GUI interface, typically the quantity of data that went in the network from the dispatcher to the SAP GUI did not exceed 2K (for dialog processes). However, this has been largely increased with later releases, although the communication technology has also decreased the impact. This network traffic does not include the print requests that are managed by spool or print managers on users' PCs or workstations.

The communication is established via standard TCP/IP sockets. The dispatcher has a special advanced program-to-program communication (APPC) server built into it that communicates and responds to requests submitted by the work processes. On each application server there is one dispatcher but multiple work processes. Note If an application server (hardware point of view) is running more than one SAP instance (application server, from a software point of view), there is one dispatcher for every instance.

A work process is a program in charge of executing the Web AS application tasks. Each work process acts as a specialized system service. From the point of view of the operating system, a group of parallel work processes makes up the SAP Web AS ABAP runtime system. A work process consists of a task handler, a dialog or dynpro processor, an ABAP interpreter, and a database interface. The work processes execute dialog steps for the end users. These steps generally relate to the processing or display of a single screen, which means that right after one work process finishes the execution of a dialog step for a user session, it is immediately available for use by another user session.

Work process architecture

Work process architecture

For its processing, each dialog step needs code, dictionary objects, and data. These elements may come from the database server or from the memory buffers that reside on the application server. The dialog processes usually request read-only information from the database and rely on other types of work processes for read-write information. This is explained in the following sections. The activities within a work process are coordinated by the task handler. It manages the loading and unloading of the user session context at the beginning and end of each dialog step. It also communicates with the dispatcher and activates the dynpro interpreter processor or the ABAP interpreter as required to perform its tasks. The ABAP processor is in charge of executing the ABAP programs, whereas the dialog interpreter (also known as the dynpro interpreter) is in charge of interpreting and executing the logic of SAP screens. The database interface allows the work processes to establish direct links with the database.

The work processes might need the same data for more than one dialog step, in which case the data are held in shared memory areas (buffers) and are available for other work processes. It must be noted that users of the same or similar Web AS business applications, such as FI (financial accounting) and CO (controlling), logging in to the same application servers will benefit from this feature because they often access the same tables. If these tables already reside in the buffer areas, the system doesn't have to go to the database to get them, and thus performance will be improved.

Work processes make use of two special memory attributes: paging and roll. The paging area holds application program data such as internal tables or report listings for the current session. The roll area holds the user context data entered in previous dialog steps and other control and user information such as authorizations. Where there is main memory available, these areas are held in the main memory of application servers; otherwise they are paged out or rolled out to physical disk files. The size of these areas is configurable using SAP system profile parameters. The system shared memory areas also contain read-only images of other parts of the Web AS system, such as the program or table buffers. The sizing and configuration of these buffers are very important for overall performance of the system. The configuration and refresh rate of these caches are critical to the overall performance of the system. To make a more efficient use of available resources, work processes are run in parallel, which makes this architecture especially suitable for multiprocessor equipment and able to run the group of work processes distributed among different CPUs.

The number of available work processes per application server is configurable using the appropriate SAP system profile parameters. The following sections include examples of such parameters. There are several types of work processes: dialog, background, update, enqueue, and spool. Additionally, the Web AS runtime system includes three other special types of services: message service, gateway, and the system log collector. Because the work processes are in charge of executing the ABAP programs and applications, a group made of a dispatcher and a set of work processes is known as the application server.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status