SAP Programming

Presentation Server

The presentation server is actually a program named sapgui.exe. It is usually installed on a user's workstation. To start it, the user double-clicks on an icon on the desktop or chooses a menu path. When started, the presentation server displays the R/3 menus within a window. This window is commonly known as the SAPGUI, or the user interface (or simply, the interface). The interface accepts input from the user in the form of keystrokes, mouse-clicks, and function keys, and sends these requests to the application server to be processed. The application server sends the results back to the SAPGUI which then formats the output for display to the user.

Application Server

An application server is a set of executables that collectively interpret the ABAP/4 programs and manage the input and output for them. When an application server is started, these executables all start at the same time. When an application server is stopped, they all shut down together. The number of processes that start up when you bring up the application server is defined in a single configuration file called the application server profile. Each application server has a profile that specifies its characteristics when it starts up and while it is running. For example, an application sever profile specifies: • Number of processes and their types • Amount of memory each process may use • Length of time a user is inactive before being automatically logged off. The application server exists to interpret ABAP/4 programs, and they only run there-the programs do not run on the presentation server. An ABAP/4 program can start an executable on the presentation server, but an ABAP/4 program cannot execute there. If your ABAP/4 program requests information from the database, the application server will format the request and send it to the database server.

Discovering the Database Server

The database server is a set of executables that accept database requests from the application server. These requests are passed on to the RDBMS (Relation Database Management System). The RDBMS sends the data back to the database server, which then passes the information back to the application server. The application server in turn passes that information to your ABAP/4 program.

There is usually a separate computer dedicated to house the database server, and the RDBMS may run on that computer also, or may be installed on its own computer.

SAP R/3 functionality is structured using its own proprietary language called ABAP (Advanced Business Application Programming). ABAP, or ABAP/4 is a fourth generation language (4GL), geared towards the creation of simple, yet powerful programs. R/3 also offers a complete development environment where developers can either modify existing SAP code to modify existing functionality or develop their own functions, whether reports or complete transactional systems within the SAP framework.

ABAP's main interaction with the database system is via Open SQL statements. These statements allow a developer to query, update, or delete information from the database. Advanced topics include GUI development and advanced integration with other systems. With the introduction of ABAP Objects, ABAP provides the opportunity to develop applications with object-oriented programming.

The most difficult part of SAP R/3 is its implementation, since SAP R/3 is never used the same way in any two places. For instance, Atlas Copco can have a different implementation of SAP R/3 from Procter & Gamble. Some companies may run multiple productive clients/systems or even multiple instances of SAP R/3. This is seen, for example, when a company running R/3 acquires a new business already running R/3. They may elect to keep both systems separate, migrate one into the other, or migrate both onto a completely new instance.

The system landscape is ultimately the customer's decision. There are definite pros and cons on the continuum from single global instance / productive client (master data, impact of configuration changes on multiple business units) to separate instances per business unit (hardware costs and communication between instances/clients)

Two primary issues are the root of the complexity and of the differences:

• Customization configuration - Within R/3, there are tens of thousands of database tables that may be used to control how the application behaves. For instance, each company will have its own accounting "Chart of Accounts" which reflects how its transactions flow together to represent its activity. That will be specific to a given company. In general, the behavior (and appearance) of virtually every screen and transaction is controlled by configuration tables. This gives the implementor great power to make the application behave differently for different environments. With that power comes considerable complexity.
• Extensions, Bolt-Ons - In any company, there will be a need to develop interface programs to communicate with other corporate information systems. This generally involves developing ABAP/4 code, and considerable "systems integration" effort to either determine what data is to be drawn out of R/3 or to interface into R/3 to load data into the system.

Due to the complexity of implementation, these companies recruit highly skilled SAP consultants to do the job. The implementation must consider the company's needs and resources. Some companies implement only a few modules of SAP while others may want numerous modules.

SAP has several layers. The Basis System (BC) includes the ABAP programming language, and is the heart (i.e. the base) of operations and should not be visible to higher level or managerial users. Other customizing and implementation tools exist also. The heart of the system (from a manager's viewpoint) are the application modules.