Exploring ABAP Application Processing

In the previous lesson, you learned about the basic architecture of the ABAP Platform and the components that make up the application layer. In this lesson, you will explore how these components work together to support interactive processing of your SAP applications.

For this discussion, we will use two scenarios to demonstrate how the ABAP Platform processes interactive requests made by a business user.

1. First, we will look at how the ABAP Platform processes a request by a business user during the system logon.
2. Next, we will explore how the ABAP Platform processes a complete SAP transaction. In each case, we will use the SAP GUI as the presentation layer.

Watch the following video to learn more about how the ABAP Platform processes an end user's logon request.

In addition to the standard SAP GUI, SAP supports browser-based front end solutions. As we have seen, these solutions include the SAP GUI for HTML, the SAP Business Client, and SAP Fiori. Connecting to your SAP S/4HANA system using one of these methods involves some additional components.

The SAP application server supports browser-based communication requests by utilizing various technologies. These technologies include the Internet Communication Manager, or ICM, and the SAP Web Dispatcher.

Previously, you learned that the ICM is responsible for handling the communication between the SAP application server and the outside world, including managing incoming HTTP requests and forwarding them to the appropriate SAP components. The ICM is provided as a part of the ABAP Platform and can be used to route incoming connections to SAP application servers based upon specific load-balancing algorithms.

When used by itself, the ICM distributes incoming requests evenly among the available application servers based on factors such as server load, response time, and availability. In this scenario, the front-end browser connects directly with the ICM, which translates the URL and routes the request to the appropriate application server. This assists the optimization of performance, improves reliability, and ensures that no single server becomes overloaded with traffic.

In order to provide a more versatile and robust solution, the ICM can also be used in conjunction with the SAP Web Dispatcher. The SAP Web Dispatcher is SAP's reverse proxy and software load balancer. It plays an important role in managing web traffic and distributing requests to SAP systems, ensuring optimal performance and availability.

In this scenario, the front-end browser connects first to the SAP Web Dispatcher before being routed to the ICM on a particular application server. In this way, the SAP Web Dispatcher acts as gateway or single point of entry for one or more back-end systems, receiving the request from the web browser and forwarding it to the appropriate SAP system based on predefined rules and load balancing algorithms.

The SAP Web Dispatcher also provides additional capabilities, including the following:

• Automated configuration by fetching system configuration information from the back-end system.
• Reverse proxy with request filtering, caching, request header modification, redirects. By acting as a reverse proxy, the SAP Web Dispatcher provides an additional layer of security, hiding the internal structure of the SAP systems from external users.
• Scalability, SAP Web Dispatcher load balancing can scale to support larger and more complex systems with high-traffic volumes, making it suitable for enterprise-level deployments.
• Request routing to back-end systems based on host, port or path (virtual hosting).
• Single Sign-On for on-premise SAP Fiori Launchpad and integrated cloud services.
• SSL termination, caching, and compression, further optimizing the communication between the web browser and the SAP systems.

Now that you have learned how the ABAP Platform processes a logon request, let us look deeper and explore how the system processes an SAP transaction. To do this, we will divide transaction processing into the following sections:

Along the way, you will learn new terminology such as dialog step, asynchronous update, and logical unit of work, or LUW.

SAP application programs differentiate between user interaction and processing logic. Interactive requests are processed by the application server dialog work process. A typical SAP transaction may involve one or more dialog steps. A dialog step is assigned to one specific dialog work process during execution. Each dialog step refers to a unit of work that is executed on the application server when a user performs an action such as entering data, clicking a button, or making a request. The application server processes the input and triggers a series of steps known as dialog steps.

These steps are responsible for executing the business logic, retrieving and manipulating data, and responding to the user's input. Each dialog step typically represents a specific task or action within the application. The individual dialog steps for a program consisting of several screens can be executed by different dialog work processes during program run time. This is called work process multiplexing. In other words, a dialog work process sequentially processes dialog steps for various users and programs.

When a user interacts with the system, they do so using screens, which are called dynpros, and consist of a screen image and the underlying application flow logic. As you learned in the previous video, each dialog work process contains a component called the Dynpro processor, which executes the screen flow logic of the application program and provides the user input to the ABAP processor.

The screen flow logic is divided into PBO (Process Before Output) and PAI (Process After Input) steps. The PBO step is processed before the screen image is sent to the user. The PAI step is processed after a user interacts with the screen. This flow is illustrated in the figure above. The screen processor tells the ABAP processor the subprogram that needs to be executed, depending on the processing status of the screen flow logic.

During each dialog step, if data needs to be exchanged with the database, the exchange takes place through the dialog work processes database interface, which enables access to database tables, ABAP programs, or the ABAP Dictionary.

An SAP transaction is typically made up of multiple dialog steps. These dialog steps, or processing units, are grouped together to generate a specific business result. For example, the creation of a financial document or a sales order. A transaction must satisfy the ACID test and is characterized by the following four attributes:

1. Atomic: Atomic means that a transaction is either fully successful or does not have any effects at all. If a transaction-oriented system goes down, you need to ensure that inconsistent, partial results are not stored.
2. Consistent: Consistent means that the system status changes from one that is accurate and consistent in business terms to another that is also accurate and consistent in business terms.
3. Isolated: Isolated means that the changes made within a transaction can only be seen by other transactions, even those that run simultaneously, after the final confirmation (Commit).
4. Durable: The results of a transaction are durable because after the final confirmation they are stored permanently in the database.

A database transaction is, in accordance with the ACID principle, a non-divisible sequence of database operations, at the beginning and end of which the dataset on the database must be consistent. The beginning and end of a database transaction are defined by a commit command (database commit) to the database system.

During a database transaction (between two commit commands), the database system ensures that the dataset is consistent. The database system takes on the task of restoring the dataset to its previous state after a transaction has terminated with an error (rollback).

Business transactions are processing units grouped to provide a specific function; these processing units execute changes to the database that are consistent and make sense in business terms. Typical examples are credit and debit updates, which only make sense together, or creating an order and reserving the relevant materials.

An AS ABAP transaction is defined as a non-divisible business process that must either be executed completely or not at all. AS ABAP transactions are implemented as sequences of logically related dialog steps that are consistent in business terms. A user dialog step is represented by a screen image.

Remember, dialog work process multiplexing allows the individual dialog steps of an SAP transaction to be processed by different dialog work processes. This means that each work process sequentially handles dialog steps for unrelated applications, one after the other as assigned by the dispatcher based upon their order in the application server wait queue.

Finally, a work processes connection to a specific communication partner process at database level is for the duration of the application server's runtime. Work processes cannot exchange communication partners at runtime. This is why a work process can only make changes to the database within one database transaction, as shown in the figure above.

The enqueue process is an critical component of the application server architecture that plays a crucial role in managing and controlling the access to shared resources within a system. Its primary purpose is to ensure the integrity and consistency of data by regulating the access to resources such as database tables, files, and memory objects.

From a database perspective, every dialog step forms a physical and logical unit: a database transaction. The database lock administration can only coordinate this type of database transaction. However, this is not sufficient for SAP transaction processing because SAP transactions are formed from a sequence of logically related work steps that are consistent in business terms and are generally made up of several dialog steps. SAP systems require an independent lock management mechanism. This is implemented using the enqueue server process.

The function of the enqueue server process is to manage and coordinate all requests for exclusive or shared access to resources at the SAP application level. 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.

As depicted in the figure above, the lock table is located in the main memory of the application server with the enqueue process, typically the ABAP Central Services (ASCS) instance. The enqueue process manages the logical locks of the SAP transactions in the lock table. This helps to prevent conflicts and inconsistencies that may arise when multiple users or processes try to access the same resource simultaneously.

SAP developers initiate and release locks in their applications by using standard SAP function modules and can choose between different lock modes, depending upon their specific business need. When the application is executed, 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.

Finally, the enqueue process provides mechanisms for handling deadlock situations, where multiple users are waiting for resources that are locked by each other. It can detect and resolve deadlock scenarios by releasing locks and allowing the affected processes to continue their operations.

Overall, the application server enqueue process plays a critical role in ensuring data integrity, managing resource access, and preventing conflicts in a multi-user environment, thereby contributing to the smooth and efficient operation of the application server.

As we discussed, an SAP transaction can contain multiple screen changes, called dialog steps, in order to map a completed business process (for example, creating a billing document or sales order). For a particular transaction, data changes created during processing must be executed completely or not at all in the appropriate application data tables in the database.

Should the operation fail during execution, or generate errors, there should not be any database changes to the underlying application tables. To ensure data integrity of the SAP system, SAP supports both asynchronous and synchronous update processing by the update server.

As depicted in the figure above, traditional SAP transactions leverage asynchronous update processing and enforce the logical unit of work concept discussed earlier. This type of update processing frees up the dialog process at the end of each dialog step, by having it commit changes into a set of temporary tables called the VB logs. This process is further illustrated in the next figure, Asynchronous Update Process.

At the end of each dialog step, the program issues a commit statement and calls a function module FUNCTION … IN UPDATE TASK, which allows the dialog process to perform a synchronous update of the data for that dialog step into the VB log tables. These tables temporarily store the data changed during each dialog step.

When all dialog steps for the transaction have been completed and the data for each step successfully recorded in the VB log tables, the ABAP program issues a COMMIT WORK statement to call the update process. The update process then collects the updates for the transaction from the VB log tables, bundles them together and then hands them off to the database for processing as a separate database transaction.

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

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.

To see how an SAP transaction is processed these components, watch the following video.

You should now be able to describe in detail SAP ABAP application processing.