The Web Components of the SAP Web Application Server SAP BASIS

As it has been explained in Chapter, the basis layer of SAP R/3 Enterprise is SAP Web Application Server 6.20, which provides capabilities to communicate to the Internet via execution of Web applications with an additional set of processes. With SAP Web Application Server, several type of requests can be processed, such as ABAP applications, executed and managed by the ABAP runtime environment (classic client/server processing that we know), HTTP or HTTPS requests coming from the Internet handled by the Internet Communication Framework (and then communicated to the ABAP runtime environment via Business Server Pages, for example—see the description of BSPs later in this chapter), and Java applications processed by the SAP J2EE Engine.

The SAP Web Dispatcher

Load balancing capabilities are possible with the SAP Web Dispatcher program, which is similar to the Message Server in the traditional Basis architecture (Warning: the message server still exists, this is only a comparison). The SAP Web Dispatcher routes HTTP requests to the SAP systems. This component is optional and normally runs in a demilitarized zone between the users' browser and the actual SAP system and can be the central access point for all Web requests. The SAP Web Dispatcher can be configured with parameter setting in the Instance profile. You will recognize these parameter settings, because almost all of them start with the root wdisp. The load balancing strategy to be followed is set by the parameter wdisp/load_balancing_strategy. You may set a classic round-robin load balancing (value: simple_weighted_round_robin) or by server capacity (value: weighted_round_robin).

Parameter wdisp/max_server_group_name_len controls the length of the entry in the logon groups table maintained in SMLG, where the logon groups are maintained. Secure HTTP requests (HTTPS requests) are handled in a different way, depending on the parameter wdisp/ssl_encrypt. Check the SAP Online Help for documentation on specific parameter settings for the SAP Web Dispatcher. In addition, check SAP Note 552286 to find out more about troubleshooting the SAP Web Dispatcher.

When the SAP Web Dispatcher is not used for load balancing, the Message Server can also load balance HTTP requests. You would then configure server groups with transaction SICF and configure the proper parameter settings in the Instance Profile. Many of them, you will recognize, start with the root ms/http_. The SAP Web Dispatcher can be monitored using the program icmon at the operating system level and it writes to the trace file dev_webdisp. The SAP Web Dispatcher is optional and it is a separate SAP software. Load balancing can also be achieved with the Message Server handling HTTP requests directly.

Monitoring the Internet Communication Manager

The Internet Communication Framework is comprised of the interfaces to handle Internet requests, using SAP Web Application Server as a client or a server of these requests. The most important piece of this part of the SAP WAS architecture is the Internet Communication Manager (ICM). The ICM provides direct communication between the Web browser and the work processes of a SAP Instance, but it does not provide with business logic.Similarly to a work process, the ICM handles external user requests from the Internet in the form of an HTTP or HTTPS request using threads that communicate to work processes to handle those requests and determine what action is necessary to perform in the SAP system. And, similarly to the memory management concept of a SAP Instance, the ICM uses memory pipes to execute the application and manage the data to transfer between the threads and the work processes.

The ICM is also patched for bug fixes. Check SAP Note 508300 for the most up to date information on the released patches and bug fixes in the SAP ICM. Execute transaction SMICM to check the ICM and its components. From here, you can troubleshoot the ICM. The main screen of the ICM, is very similar to the work process monitor that you are used to watching all the time and it displays the threads, with attributes, such as the number, the operating system thread PID (process identifier), the number of requests handled by every thread, the status (free or running-occupied), and finally what type of request is being processed. Many different possible type of requests can be seen here, such as read or write request or response, open, accept or close the connection, waiting for data or response, and so on.

ICM Monitor screen

ICM Monitor screen

Check that the peak number of threads and the connections used do not reach the "maximum" number configured. The behavior of the ICM is controlled via parameter settings in the Instance Profile. To start the ICM the parameter rdisp/start_icman must be set to true. Almost all of these parameters start with the root icm. You can see the parameter settings and change them from the ICM Monitor by choosing Goto | Parameters | Display. Remember that the ICM communicates to the work processes and sends them requests.

Therefore, proper parameterization of the work processes is essential for optimal performance and in order to make this configuration work well. If in addition to Web requests there are also dialog requests, the parameter rdisp/min_wait_dia_wp must be configured to allow dialog work processes to handle regular dialog requests. The same parameters that control RFCs are also important in the communication between the ICM and the work processes.

The parameter icm /keep_alive_timeout allows you to keep a network connection between the user and the ICM open for a period of time. Setting this to a very low number (if you set it to 1, it would never close the connection and 0 is not an allowed value) will incur in several opening and closing of sockets and that can overload the network. Setting it too high would be a waste of threads time. Tip To check the values of all the parameter settings in your SAP system, execute program RSPARAM and browse the resulting list.

To monitor the memory usage of the ICM, browse to Goto I Memory Pipes | Display Data. The indicators to watch for here are #Mpi Buffers (number of memory pipe buffers) and Peak Buffer Usage. If Peak Buffer Usage reaches Maximum Buffer Usage, this is an indication of a bottleneck. In addition, the ICM is capable to save parts of Web pages and images in a little cache that can be monitored by Goto | HTTP Server Cache | Display Statistics. Check the quality of this cache similarly to the quality of a SAP R/3 buffer. You can display a trace file choosing Goto | Trace File | Display File. The trace level can also be set to lower or higher with Goto | Trace Level | Set. The trace file is called dev_icm, similarly to the developer traces of the work processes and the dispatcher in a SAP Instance.

The SAP J2EE Engine

The SAP Web Application Server provides you with two integrated runtime environments, the ABAP runtime environment and the SAP J2EE, which form the engine that SAP developed to execute and manage Java applications. Note J2EE is Java™ 2 Enterprise Edition standard and SAP J2EE complies to this standard. There are different possibilities of installing a SAP Web Application Server. You may install both stacks, the ABAP and the J2EE, only the ABAP stack or only the SAP J2EE stack. In addition, when you are using several SAP Web Application Servers at the same time (for example, for load balancing) in the same landscape, you can install them and configure them separately.

For example, one SAP WAS with the ABAP stack only (which could handle ABAP requests from BSPs, for example) and another one with a JAVA stack (to handle Java requests) and another one with both. Note that both stacks are completely integrated and reside in the same physical machine, offering openness to standards. This is the way an HTTP request is processed by the SAP Web Application Server with an ABAP and a Java stack:

  • The Internet Communication Manager receives HTTP/HTTPS requests from the Web and decides whether it is a BSP application to be processed by the ABAP runtime environment or a Java application to be executed by the SAP J2EE Engine. To determine this, you set the parameter icm/HTTP/j2ee_## (where ## is the entry number) with the appropriate values. The options to choose from are several and they include a prefix to redirect to the SAP J2EE Engine, a host to execute that request, the number of connections that can be open to that J2EE server, the port number of the J2EE server to which the ICM has to connect and encryption options.
  • If the request is to be processed by the SAP J2EE Engine, the ICM sends it to the J2EE server.
    Load balancing within the SAP J2EE is possible when using a cluster installation of the SAP J2EE. In this case, you will observe two different components, a dispatcher node and server nodes. The dispatcher node handles the distribution of requests among the available server nodes. In a single-node architecture, the request is handled directly by a server node in the SAP J2EE.

However, an architecture with a dispatcher node and several server nodes still represents a single point of failure, because in case of a shutdown in the dispatcher, none of the server nodes are available. Therefore, note that load balancing does not prevent from single point of failure. In order to prevent this situation, several dispatcher nodes with their corresponding set of server nodes can be configured. The Java server that is in charge of processing the request handles such processing in local memory. Threads do not share memory. Therefore, this must be taken into consideration when sizing a SAP Web Application Server.

A single thread, theoretically, could take up all the memory of a server. However, you can apply limits. When the request involves the use of ABAP objects for business logic, the SAP J2EE Engine communicates to the ABAP runtime environment via the JCo (Java Connector), which comprises a set of RFCs and BAPIs that can actually access and manage SAP objects in the ABAP repository. Note You may also use Native JDBC, which is similar to Open SQL in ABAP, databaseindependent Java code. Other interfaces may also be used.

In a cluster environment, you can use the Configuration tool (and you do not need to have a SAP J2EE Engine up and running, indeed!) to set up dispatchers and server nodes, as well as their properties for memory management, logging and tracing, locking, and so on.

Monitoring the SAP J2EE

The SAP Web Application Server offers several possibilities to manage the SAP J2EE Engine and monitor its performance. In addition, parameter settings that control the behavior of the SAP J2EE must be set appropriately. Most of these parameters start with the root rdisp/j2ee. For detailed documentation on all the parameters of the J2EE server, refer to the Online Documentation. In order to the SAP J2EE Engine to be started by the Dispatcher in the SAP Web Application Server, set the parameter rdisp/j2ee_start to 1. To monitor the SAP J2EE, use the Visual Administrator, which is written entirely in Java, and it offers a user-friendly graphical user interface.

It provides you with information about services, runtime, deployment, and logging and tracing. The most important indicators to check in the Visual Administrator are the status of a thread, the memory allocated by such thread and the number of HTTP hits.

Additionally, log files of events are written into the directory <SAP J2EE engine installation directory>/cluster/server. You can also find system and application logs in the <J2EE>/cluster/server/log. The CCMS Monitors (transaction RZ20) can also be used to monitor the SAP J2EE Engine. SAP CCMS agents running at the operating system level collect and send data to the CCMS monitors to be analyzed. CCMS agents and their patches are available in the SAP Service Marketplace. Follow the instructions in SAP Note 498179 to install and configure SAP CCMS agents.

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