The Architecture of the SAP Web Application Server SAP BASIS

SAP Web provides the greatest flexibility by separating technology infrastructure into solutions. SAP Web Application server is a natural progression of SAP Basis and supports all existing and future components of mySAP Business Suite and SAP R/3 Enterprise in addition to all J2EE-based applications. These applications can be customized or provided by a third party. SAP Web Application Server also has the underlying technology for SAP Enterprise Portal, SAP Business Information Warehouse, and SAP Exchange Infrastructure.

The Internet Communication Manager

The Internet Communication Manager ensures communication between the SAP system (SAP Web Application Server) with the outside world using the HTTP, HTTPS, and SMTP protocols. In the server role, it can process requests from the Internet that have URLs with the server/port combination that the ICM responds to. Independently of the URL, the ICM then calls the corresponding local handlers. You need the ICM if you want your SAP Web AS to communicate with the Internet using HTTP(S), SMTP, or NNTP.

The ICM is part of the SAP Web AS. The ICM is implemented as an independent process and is started and monitored by the dispatcher. You can use profile parameters to set whether the ICM should be started and how it should be configured The ICM process uses a pool of worker threads to parallel process the load. Besides the pool of worker threads, which process incoming requests, the following ICM components are also implemented as threads:

  • Thread control. This thread accepts incoming TCP/IP requests and creates (or calls) a worker thread from the thread pool to process the request. From this point on, thread control initializes the connection info data.
  • Worker threads. These threads handle requests and responses for a connection. A worker thread contains an I/O handler for network input and output and various plug-ins for the different protocols supported by the system (HTTP, SMTP, and so on). The plug-ins decide when a sent packet is complete (this process is protocol dependent).
  • Watchdog. Usually, a worker thread waits for the response, regardless of whether the worker thread is a server or a client. If a time-out occurs, the watchdog takes on the task of waiting for the response. This makes the worker thread available for other requests. When the watchdog receives the response, it informs the thread control components, which then call a worker thread.
  • Signal handler. This thread processes signals sent from the operating system or from another process (for example, the dispatcher).
  • Connection info. This table contains information about the state of the connection, the memory pipes, and the plug-in data for every existing network connection.
  • Memory pipes. Memory pipes are memory-based communication objects that handle data transfer between the ICM and the work processes. There are four pipes for every connection: one data pipe per request and response and one outof- band (OOP) pipe. The OOP pipe is used for control information.

ICM Plug-Ins

The ICM contains plug-ins for the protocol-dependent tasks. The Internet protocols HTTP and SMTP each have a plug-in. The plug-ins perform the following tasks:

• All protocol-specific tasks
• Input and output data handling, data manipulation
• Local handling in the ICM or forwarding to the work process

A Closer Look at the HTTP Plug-In

HTTP is the protocol used to make HTTP requests and HTTP responses over an IP network. The HTTP plug-in has all the built-in features to handle both an HTTP request and an HTTP response. A key element in the HTTP plug-in is that the URL and the port are used to access the local ICM handler. This eliminates the need to create a user context in the work process each time that an HTTP request is made from an application. The HTTP plug-in uses a chain-forwarding approach to processing an HTTP request. Each handler is capable of processing a request; however, if the handler is unavailable, the HTTP request is forwarded to the next available handler for processing. This increases performance.

Local handlers are referred to as subhandlers and are called in series depending on the handler's profile parameter. A profile parameter associates a handler with a URL prefix. Therefore, a request for a particular URL prefix is sent to the next available handler in the series that corresponds to the URL prefix. ICM has six handlers:

  • Logging handler. The logging handler records each HTTP request.
  • Server cache handler. The server cache handler is responsible for reading and writing information to and from the cache. First, the request is read. The requested object may or may not be already stored in the cache. If it is, then the server cache handler responds to the request by reading the requested object from the cache. If the object is not in the cache, then the server cache handler forwards the request to the next handler for processing.
  • File access handler. The file access handler responds to requests for a file from the file system such as pictures or static HTML pages. The ICM knows which URL prefix to use by reading the icm/HTTP/file_access_<xx> parameter.
  • Redirect handler. The redirect handler has the job of redirecting an HTTP request to another HTTP server. The target URL prefixes are identified in the km/HTTP/redirect_<xx> parameter.
  • SAP R/3 handler. The SAP R/3 handler responds to a request to access the SAP system. This is the default handler and therefore handles requests that none of the other handlers processes. This is the only handler where a user context is created in the workplace.
  • J2EE handler. The J2EE handler responds to request for J2EE objects that are handled by the integrated J2EE server.

A Look at the Internet Server

The Internet server has a cache where HTTP objects are stored before those objects are forwarded to the client who requests the object. This is more efficient than retrieving the object from the disk each time a client requests it.

The Internet server requires one millisecond to process a request for an object that is already in cache. This means that 3000 requests can be processed every second if a 4 CPU computer is used as the server. The first time a client requests an object, the object is retrieved from the disk (or from its original source) and is stored in the ICM server cache. Once in the cache, the object is then sent to the client. Each object stored in the ICM server cache has an expiration time that is identified by the icm/HTTP/server_cache_<xx>/expiration parameter. The object remains in cache until it expires. A subsequent request for the object requires that the object be again retrieved from disk and placed into cache before it is sent to the client.

An Inside Look at the Web Dispatcher

The web dispatcher is a key component of integrating the Internet with SAP because the web dispatcher is the software switch between SAP and the Internet. As HTTP requests are received, the web dispatcher directs the request to one or multiple SAP Web application servers based on the capacity of the server. In this way, clients receive the fastest possible response. The web dispatcher is a software switch that runs on the proxy server or whatever server is directly connected to the Internet. The icm/server_port_<xx> parameter tells the web dispatcher the port that will receive client requests. The rdisp/mshost parameter identifies the SAP message server and the ms/http_port identifies the port that the SAP message server uses to receive requests. Both of these are used by the web dispatcher to process incoming HTTP(S) requests.

The number of requests the dispatcher sends to a SAP Web AS will depend on the capacity of the server, and capacity is linked to the number of configured dialog work processes. If the request is the second or subsequent request from an existing session (a session cookie for HTTP requests, and the client IP address for HTTPS requests), then the web dispatcher makes sure that the request is sent to the application that is processing the client's requests for that session.

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