Describing AS ABAP

The users can log on to the SAP system using the SAP GUI or a web client (browser), for example.

Users can log on through the (ABAP) message server (load balancing) or they can log on directly on the ABAP dispatcher, the work processes execute the user entries.

The screen entries of a user are accepted by a front-end software, for example, the SAP GUI (graphical user interface), converted to an internal format and forwarded to the dispatcher.

The (ABAP) dispatcher is a central process of AS ABAP. It manages the resources for the applications written in ABAP in coordination with the respective operating system. The main tasks of the ABAP dispatcher include the distribution of the requests to its work processes, the integration of the presentation layer and the organization of communication activities.

The dispatcher first saves the processing requests in request queues and then processes them according to the first in, first out principle.

The ABAP dispatcher distributes the requests one after the other to the available work processes. Data is actually processed in the work process, although the user who created the request using the SAP GUI is not always assigned the same work process. There is no fixed assignment of work processes to users. To process user requests, it is often necessary to read data from the ABAP schema of the database or to write to it. For this, every work process is connected directly to the ABAP schema of the database.

Once the process is complete, the result from the work process is sent via dispatcher back to the SAP GUI. The SAP GUI interprets this data and generates the output screen for the user.

The buffers help to speed up processing of user requests. Data that is read but seldom changed (for example, programs or customizing data such as currencies or company codes) can be kept as a copy of the database content in the shared memory of the application server. This means that the data does not have to be read from the database every time it is needed, but can be called quickly from the buffer. Each instance has its own buffers.

Work processes execute the process logic of application programs. In addition to internal memory, a work process has a task handler that coordinates the actions within a work process, software processors, and a database interface. The dynpro processor executes the screen flow logic of the application program, calls processing logic modules, and transfers field content to the processing logic. The actual processing logic of ABAP application programs is executed by the ABAP interpreter. The screen processor tells the ABAP processor which subprogram are to be executed, depending on the processing status of the screen flow logic.

The dialog work process selected by the dispatcher performs a roll-in of the user context first. That is, the data that contains the current processing status of a running program as well as data that characterizes the user is made known to the work process. The work process then processes the user request, which may involve, for example, requesting data from the database or from the buffers in the shared memory. Once the dialog work process has processed the dialog step, the work process returns the result, rolls the user context back out to the shared memory, and is now available again for a new user request from the request queue. The result is transferred to the SAP GUI and the user sees the new screen.

Relational Database Management Systems (RDBMS) are generally used to manage large sets of data. An RDBMS saves data and relationships between data in the form of two-dimensional tables. These are known for their logical simplicity. Data, tables, and table relationships are defined at database level in the database catalog (the data dictionary) of the RDBMS.

Within the SAP programming language ABAP, you can use ABAP SQL (SQL = Structured Query Language, database query language) to access the application data in the database, regardless of the RDBMS used. The database interface, which is part of every work process of AS ABAP, translates ABAP SQL statements from ABAP into the corresponding SQL statements for the specific database used (Native SQL). This allows ABAP programs to be database-independent.

ABAP SQL was called Open SQL up to AS ABAP 7.52.

The execution of dialog requests is characterized by the following:

SAP application programs differentiate between user interaction and processing logic. The user actions are technically realized using screens, also called dynpros­ (from dynamic programs), which consist of a screen image and the underlying flow logic. The Dynpro processor of the work process executes the screen flow logic of the application program, calls processing logic modules, and transfers field content to the processing logic. The screen flow logic itself is further divided into PBO (Process Before Output), which is processed before the screen image is sent, and PAI (Process After Input), which is processed after a user interaction on the screen. The PAI part of a dialog step logically belongs to the preceding screen image, while the PBO part logically belongs to the subsequent screen image. The actual processing logic of ABAP programs is executed by the ABAP interpreter. The screen processor tells the ABAP processor the subprogram that needs to be executed, depending on the processing status of the screen flow logic.

If, during a dialog step, data needs to be exchanged with the database or the buffers, then this exchange takes place through the database interface, which enables access to database tables, ABAP programs, or the ABAP Dictionary, among other things.

To ensure data consistency within an SAP system, you must ensure that data records cannot be accessed and changed by more than one user at any one time. To do this, the SAP system has its own lock management concept.

From a database perspective, every dialog step forms a physical and logical unit: The database transaction. The database lock administration can only coordinate this type of database transaction. From an SAP point of view, however, this is not sufficient, because SAP transactions, which are formed from a sequence of logically related work steps that are consistent in business terms, are generally made up of several dialog steps. SAP systems need to have their own lock management. This is implemented using the enqueue process. This also ensures that the platform-independence of lock management is maintained.

The SAP lock concept works on the principle that SAP programs make lock entries for data records to be processed in a lock table. Lock entries can only be made if none already exist for the table entries to be locked.

The lock table is located in the main memory of the application server with the enqueue process. The enqueue process manages the logical locks of the SAP transactions in the lock table.

The enqueue process can be implemented in one of the following ways:

• As a work process

• As part of the ABAP central service instance (ASCS, default installation option for all new installations and mandatory since AS ABAP 7.50/7.51)

Since AS ABAP 7.00, it has been possible to choose between these two options. The ASCS option is preferred for reasons of high availability, for example. Since AS ABAP 7.50 the ASCS setup is mandatory if the SAP system has more than one application server. Since AS ABAP 7.51 the ASCS setup is mandatory in any case. The ASCS setup is mandatory if an Enqueue Repliation Server (ERS) should be installed.

If a user wants change access to data, the executing dialog work process requests a lock (to do so, the application developer must program this request explicitly).

When the lock is requested, the system checks whether the requested lock conflicts with existing entries in the lock table. If the lock table already contains corresponding entries, the lock request is refused. The application program can then inform the user that the requested operation cannot currently be executed.

The application developer can choose between different lock modes:

• Write locks (lock mode Exclusive): the lock data can be edited only by one user. The requests for another write lock and another read lock are rejected. A write lock protects the locked objects against all types of other transactions. Only the same lock owner can set the lock again (cumulate).

• Read locks (lock mode Shared): several users can have read access to the locked data at the same time. The requests for additional read locks are accepted, even if they are from other users. A write lock is rejected.

• Enhanced write locks (lock mode exclusive noncumulative): while write locks can be successively requested and released by the same transaction, an enhanced write lock can only be requested once, even by the same transaction. All other requests for locks are rejected.

• Optimistic locks (lock mode Optimistic): optimistic locks respond like read lock at first and can be changed to write locks. An optimistic lock is set if the user displays the data in change mode. Optimistic locks on the same object do not collide. If the user wants to save the (changed) data, the optimistic lock must be changed to a write lock (mode E). (This fails if someone set a non-optimistic lock on the object before.) Other optimistic locks on the object are deleted in the process.

Locks set by an application program are either released by the application program itself or by the update program once the database has been changed. Locks that have been passed on to an update work process are also written to a file at operating system level, and can therefore be restored if the enqueue server goes down.

Transaction SM12/SMENQ displays the locks that are currently held. If a lock has already been inherited to the update process, the backup flag has also been set. Such a lock will also be included in the lock table again after restarting the enqueue server.

To access the lock table, use transaction SM12 in SAP systems with SAP_BASIS 7.52 and below – use transaction SMENQ in SAP systems with SAP_BASIS 7.53 and above. In SAP systems with SAP_BASIS 7.55 and above, SM12 is the new SMENQ.

There are two ways of deleting locks held by users:

• Ending the user session in the user overview (transaction SM04)

• Manually deleting the lock entries in SM12/SMENQ

The first method (ending the user session) also results in the original lock owner leaving the transaction and releasing all locks held. The second method (manually deleting using SM12/SMENQ) merely deletes the lock entry from the lock table. This theoretically enables several users to change the same data records simultaneously.

The updating system allows SAP transactions to off-load time-intensive database changes. These are then carried out asynchronously in special update work processes. It also circumvents the roll-back problems caused by the difference in the concept of the logical unit of work (LUW) in an SAP transaction and in the database.

If, during a dialog work process, data temporarily stored for processing is passed to an update work process for further processing, the dialog work process does not wait for the update request to be completed: The update is asynchronous (not simultaneous). The asynchronous update process is illustrated in the figure "The Principle of Asynchronous Updates".

The dialog part is completed with the ABAP command COMMIT WORK; the update part of the transaction starts. The update server transfers the update request to an update work process. Here, each dialog step corresponds to a database transaction (which is executed either completely or not at all in the database and they’re completed with a COMMIT command). The update part of the SAP transaction is executed in a database transaction. It is only then that the data is copied to the application tables.

If users want to change a data record in an SAP transaction, they call the corresponding transaction in the dialog, make the appropriate entries on the screens, and then initiate the update process by saving the data. This process triggers the following steps:

1. The program locks the data record for other users. The program does this by addressing the enqueue work process (using the message server if appropriate). The enqueue work process makes the relevant entry in the lock table or (if another user has already locked the data) informs the user that the data record cannot currently be changed.

2. If the enqueue work process succeeded in writing the lock entry to the lock table, it passes the lock key it created to the user, the program reads the record to be changed from the database and the user can change the record on the screen image of the SAP transaction.

3. In the current dialog work process, the program calls a function module using CALL FUNCTION ... IN UPDATE TASK and writes the update request to database update tables. These are also called VB* tables, because their names begin with "VB". They act as temporary memory and store the data to be changed until it can be collected and written to the application tables in the database (in a single database transaction).

4. At the end of the dialog part of the transaction (for example, when the user saves the data – possibly after completing other dialog steps), the program initiates the close of the transaction with the COMMIT WORK statement. The work process that is handling the active dialog step completes the update header and triggers an update work process.

5. Based on the information (key of the update request, lock key) transferred from the dialog work process, the update work process reads the log records that belong to this SAP transaction from the VB* tables.

6. The update work process transfers the changes marked and collected in the VB* tables to the database as an update request and evaluates the database response. If the changes were successfully written to the target tables, the update work process triggers a database commit after the last change to the database and deletes the entries from the VB* tables. If an error occurs, the update work process triggers a database rollback, leaves the log records in the VB* tables and marks them as defective.

7. The lock entries in the lock table are reset.

If an error occurs during an update, then processing of the active update component terminates. Users can be notified automatically by express mail when an update terminates.

If a dialog work process terminates while writing data to the VB* tables, the tables contain data that will not be updated. These entries can be automatically deleted the next time you start the SAP system or they can be deleted manually. The application tables remain unchanged.

An asynchronous update may terminate for various reasons. If, for example, several attempts are made to enter the same data record (using insert) in a table, this triggers the exception condition "Duplicate Key" in the coding because an entry already exists in the table under this key. Therefore, the corresponding data record cannot be written to the database table more than once.

When an update terminates, the system sends an express mail to the user who triggered the update. Any additional steps must be carried out by the SAP system administrator. Transaction SM13 (update requests) provides system administrators with analysis tools to handle the terminated updates. Once the error that caused the termination has been corrected (for example, hardware damage repaired), the end user should restart the processing.

For print processing, the best performance is achieved by sending the data to be printed to the operating system as soon as possible. You do this using the local access method. The operating system then performs all remaining tasks, such as queuing and data transfer to the selected printer.

You can display your spool and output requests by choosing transaction SP02.

You can specify personal settings for printing on the Defaults tab page in the Spool Control section, by choosing System → User Profile → User Data (transaction code SU3).

SAP background processing is a method for automating routine tasks and for optimizing the use of your organization’s SAP computing resources. In background processing, you instruct the SAP system to run programs for you. You can use background processing to execute long-running or resource-intensive programs at off peak times. As a result, you can assign the SAP system the task of executing programs. There is no strain on your dialog resources and programs running in the background are not subject to the runtime restrictions of dialog processing (termination of the program after a run time of, for example, ten minutes).

The end user can usually schedule the program to be started in the background as a job from the application transaction. The job then waits for the planned execution time in the job scheduling table. If the time has come and free background work processes are available, the job is distributed to a background work process by the background scheduler and then executed. Users can display the result in the application transaction or, in the case of list generating programs, look at the spool request belonging to the job (see the Printing section). To display your own jobs, choose System → Own Jobs (transaction code SMX).

The SAP System Administration and the work preparation have access to a tool for scheduling various background tasks with transaction SM36. The system-wide monitoring of jobs takes place with transaction SM37.

For cross-system scheduling and monitoring of background tasks, you can use SAP Central Process Scheduling and other licensed partner products.

When Remote Function Call (RFC) or Common Program Interface Communication (CPIC) is used to communicate between application servers of an SAP system or between SAP systems themselves, the gateway is always involved. If a dialog work process has to establish an RFC connection to a remote SAP system in the context of a request (for example, to retrieve customer data), it uses a gateway to communicate with the remote SAP system. The gateway forwards the request to the gateway of the remote SAP system. The remote gateway then transfers the request to the dispatcher, which, in turn, forwards the request to one of its work processes, which then communicates directly with its gateway.

Inbound RFC connections are therefore always received by the gateway while outbound connections are initiated by the work process.

The ICM forwards it to the ABAP dispatcher, which then handles it like a typical SAP GUI request (see previous section). The work process that processes the inquiry now communicates directly with the ICM. The ICM returns the response to the user who sent the request.

The work processes can directly generate Web-enabled content, which can then be transferred to the inquiring browser front ends via the ICM.

The ICM enables various UI technologies to be used, for example SAPUI5, Web Dynpro ABAP or Business Server Pages (BSP). The more recent technologies come at the top of this list.

The transactions shown in the following figure help you to deal with daily SAP system administration work. SAP system administrators should be familiar with the use and interpretation of these transactions.

Transaction SM51 lets you display the application servers that are logged on to the SAP message server. They represent the application servers of the SAP system. Their status indicates which application servers are active in the SAP system.

The following functions are available as menu items; important menu items also display as buttons on the screen. You can navigate to other transactions from here:

• Display and manage work processes (transaction SM50)

  Display and manage user sessions (transaction SM04)

• System logs (transaction SM21)

The following transactions are also available:

• The gateway monitor (transaction SMGW)

• The ICM monitor (transaction SMICM)

• The OS monitor (ST06), to name just a few

Transaction SM50 shows a snapshot of the work process status of the application server where you are logged on. You refresh the display to receive updated information. The process overview is intended primarily for information-gathering. For example, you can monitor processes to determine whether the number of work processes in your system is adequate, to assess whether the application server is working to full capacity, to gather information for troubleshooting, or for tuning.

Transaction SM04 enables you to display all the users who are logged on to this application server in the SAP system. As of AS ABAP 7.40, you can also use transaction SM04 to display all the active users system-wide.

The user maintenance transaction (SU01) enables you to maintain individual master records. The user administrator can use it to create new user master records or administer existing user master records, for example, assign new roles and authorization profiles.

For the mass maintenance of users, you can use transaction SU10.

You can use transaction SM36 to create background jobs in the SAP system.

Transaction SM37 enables you to display an overview of the background jobs in the SAP system.

You can use transaction SM21 to analyze the system log.

You can manage lock entries in the lock table of the enqueue work process using transaction SM12/SMENQ. Lock management is used to monitor the lock logic in the SAP system. It lets you determine which locks are currently set.

Update management (transaction SM13) lets you perform the following tasks:

• Display update requests

• Analyze problems relating to the update

• Test and clean up canceled update requests

• Display and reset the status of update requests

• Delete update requests

• Display statistics for the update task

This function provides you with an overview of the update requests and a tool to investigate any problems that may have occurred. It does not display requests that have been updated successfully.

In addition to the alerts, the SAP system sends express mails to each user whose updates are canceled, indicating the update error. The mail is sent in the SAP system in which the problem occurred.

If you want to send a message to all users in your SAP system, you can use transaction SM02 to send a system message. It is also possible to restrict the recipients to users of a certain client, or users that are logged on to a particular application server. A message is only displayed to the recipient once a day. The SAP system displays messages:

• When a user logs on to the SAP system

• As soon as a logged on user performs the next dialog step