The figure above shows an example of a system landscape in which Web browsers from the internet and intranet are connected with an AS ABAP (in this case, distributed across a number of servers). Important features are:
Support for standard Web protocols such as HTTP, HTTPS, WebDAV, SOAP, and SMTP
Display of standard Web formats such as HTML, XML, OData and XSLT
Complete integration into the SAP environment (development environment, user administration, authorization concept, system monitoring, and communication protocols)
The AS ABAP can act both as a Web server (server role) and as a Web client (client role). The server role, in which the AS ABAP can accept and process HTTP(S) requests from any Web client (such as a Web browser) and send back an HTTP(S) response, is what we will discuss in this lesson.
Within a work process, the Internet Communication Framework (ICF) provides the environment for handling HTTP(S) requests. The ICF is the bridge between the C kernel of the SAP system and the application program created in ABAP.
Internet Communication Manager is a component of the SAP architecture that allows the ABAP based SAP system to communicate directly with the internet. Technically, the Internet Communication Management is a standalone multi-threaded process that is started and monitored by the ABAP dispatcher.
Work processes can directly generate Web-compatible content in a way that can be forwarded to a Web browser using the ICM. One way of creating content of this type is to use Web Dynpro applications that are developed in the SAP system using the ABAP Workbench (for example transaction SE80).
From a technical point of view, the ICM is a separate process (icman at operating system level) that is started and monitored by the ABAP dispatcher. Its task is to ensure that the SAP system can communicate with the outside world (using HTTP, HTTPS, and SMTP). In the server role, it can process requests from the internet that arrive with URLs with the server/port combination for which the ICM is listening. The ICM then calls the appropriate local handler, depending on the URL. The ICM process uses threads to process the created workload in parallel.
The components of the ICM are:
Thread Control: This thread accepts the incoming TCP/IP requests and creates (or raises) a worker thread from the thread pool to process the request.
Worker Thread: This thread handles requests and responses for a connection. A worker thread contains an I/O handler for the network input and output, and various plug-ins for the different supported protocols.
Watchdog: A worker thread usually waits for a response (whether it is client or server); if a timeout occurs, the watchdog takes over the task of waiting for the response. The worker thread can then be used for other requests.
Signal Handler: This thread processes signals that are sent from the operating system or another process (such as the ABAP dispatcher).
Connection Information: Table with information for each existing network connection.
Memory Pipes: These memory-based communication objects allow data transfer between the ICM and the ABAP work processes.
The requests from the ICM must also wait in the dialog queue of the ABAP dispatcher. When a free dialog work process is found, ICM threads and dialog work processes communicate directly with each other.
The ICM uses plug-ins to implement the different communication protocols. Once the AS ABAP has been installed, the following protocols can be used:
HTTP
HTTPS
SMTP
LDAP
Cache for response pages of the ICM. This stores pages before they are sent to the client. The next time that the relevant URL is called, as long as the expiry time has not elapsed, the page is sent back to the client directly from the ICM; in this case, it does not need to be branched to the task handler and the ICF.
A part of the ICM that is important for performance is the Internet Server Cache (ISC), which stores HTTP(S) objects before they are sent to the Web browser. The next request can then be made directly from the ISC, provided that the expiry time has not elapsed. This avoids branching to the ABAP work process, which can accelerate the access considerably.
Some features of the ISC are:
Two-level hierarchy: When objects are stored, the advantages of both the high speed of main memory (memory cache) and the storage capacity of hard disks (disk cache) are used.
Dynamic Caching: Traditional products are based on HTTP proxies and usually offer caching only of static content, such as images. The ISC can also cache dynamic content such as JSPs or BSPs.
Active Caching: The application has full control over ensuring that the objects in the cache are up to date.
UFO Caching: Invalid requests ("UnFound Objects") that lead to error situations in the application server or the database are directly rejected, so that the system is protected against invalid or malignant requests.
Browser-dependent Caching: The developer of a BSP can define whether his or her application is dependent on the browser type. If this indicator is set, the ISC uses the data in the cache only for requests from the same browser type.
The ISC is configured using the profile parameter icm/HTTP/server_cache* and can be monitored and invalidated from the SAP system.
