Why Monitor the SAP AS ABAP System?
ABAP application servers are important software components of NetWeaver AS ABAP since all ABAP programs run on these servers. These application servers execute ABAP applications and communicate with the presentation components, the database, and also with each other, using the message server. The following diagram shows the structure of an ABAP application server:
As can be inferred from Figure 1, a typical SAP NetWeaver ABAP framework is structured as a multi-tier infrastructure, where the SAP GUI serves as the web front-end through which users login and place requests, the ABAP application server serves as the middle-ware that processes the user requests and sends out responses to the user, and a database server functions as the backend where processed data is stored for posterity.
If you zoom into the ABAP application server tier, you will notice that, in addition to several work processes, the 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: 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.
- Dispatcher: 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.
- Gateway: This is the interface for the communication protocols of NetWeaver AS ABAP (RFC, CPI/C). It can communicate with other ABAP application servers of the same NW AS, with other SAP Systems, or with external non-SAP systems.
- Shared Memory: 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
Since these components are closely inter-related to each other, the problem in any one component can adversely impact the performance of the other components, ultimately delaying the access to and the execution of ABAP applications running on the AS ABAP application server. SAP administrators are therefore faced with the challenge of not just proactively detecting such a slowdown, but also quickly and accurately diagnosing the reason for the same – is it because the dispatcher is unavailable? is it because the gateway has failed? Is it owing to the lack of free work processes? or is due to poor memory management by the ABAP system? This is where eG’s SAP AS ABAP Instance monitoring model (see Figure 1) helps!