The following graphic shows an overview of the instance attributes and the interface methods.
The interfaces for HTTP request and response are the same as in the server case for IF_HTTP_SERVER. These are described in IF_HTTP_RESPONSE and IF_HTTP_REQUEST.
For successful HTTP communication, you require an HTTP request handler in the server. The HTTP request handler (class CL_HTTP_REQUEST_HANDLER in the UML diagram) implements the interface IF_HTTP_EXTENSION.
Using the classes and interfaces described here, you can develop your own HTTP request handler.
Remember, though, that SAP provides you with a range of HTTP request handlers that meet the most common requirements. You can also adapt these standard handlers for your own specific needs.
Before programming an HTTP request handler of your own, check if a ready-made SAP solution already exists.
The HTTP request handler (CL_HTTP_REQUEST_HANDLER) uses the interface of the interface IF_HTTP_UTILITY. You can use any of the methods specified here. The HTTP request handler then implements the interface IF_HTTP_EXTENSION, which uses the interface of the interface IF_HTTP_SERVER. The interface IF_HTTP_SERVER is the aggregation of the interfaces IF_HTTP_REQUEST (access to the request attribute) and IF_HTTP_RESPONSE (access to the response attribute). The interfaces IF_HTTP_REQUEST and IF_HTTP_RESPONSE are derived from the interface IF_HTTP_ENTITY.
The UML diagram below shows the design of the various interfaces and their relationships to one another.
This section describes the structure of the software layers in the server architecture of the ICF (Internet Communication Framework).. In the server function, the ICF creates a response to request with the help of the corresponding application.
In the scenario described here, a client (such as a Web browser) sends an HTTP request to the server. The ICF forwards the request to an application. The application then gathers the requested data and sends it back to the client through the ICF as a response. The response data can then be displayed and/or further processed in the browser.
The arrows in the graphic represent the control flow and data flow.
● The request is sent to the Internet Communication Manager (ICM) (1). The ICM decides whether the resource identified by the URL (the desired application) is realized in the ABAP stack or Java stack of the NW Application Server.
● If the application is an ABAP application, the request is forwarded to the task handler (2).
● The task handler then starts the ICF controller, which is realized by the function module HTTP_DISPATCH_REQUEST (3).
● The ICF controller sends the request to the ICF manager, which is implemented by the ABAP class CL_HTTP_SERVER (4). Here, a server control block is created. Gradually, this block stores all data for the request, including the response.
● Once the server control block has been created, the request data is requested by the ICM (5+6+7).
● The ICM then sends the request data to the ICF manager (8+9+10), where it is stored in the Request attribute of the server control block.
● The special HTTP request handler that then handles the request is determined by the URL in the ICF controller (11). The URL is split into its path components.
Example
In the URL http://<hostname>:<port>/bc/ping, the path component <hostname>:<port> is the virtual host, and the path component /bc/ping is the server path or name.
The assignment of a virtual host and service to an HTTP request handler is maintained in transaction SICF. All path components are processed from left to right to identify the correct ICF services. Multiple HTTP request handlers can be assigned to one service. The attribute IF_HTTP_EXTENSION~FLOW_RC controls the order in which the individual HTTP request handlers are called.
● Once the HTTP request handlers have been determined, the client is authenticated (12).
There are a number of logon procedures. If the logon fails, the system attempts to log on again before terminating communication.
● After successful authentication, the request is processed by one or more HTTP request handlers. To do this, the ICF controller (the function module HTTP_DISPATCH_REQUEST) passes control to the HTTP request handler (13). Each of these handlers implements the interface IF_HTTP_EXTENSION. The special properties of a specific HTTP request handler are defined in the implementation of the method HANDLE_REQUEST().
● The HTTP request handler first gets the content of the request object from the server control block (attribute request). This block is managed by the ICF manager (14). To do this, the handler uses the method HANDLE_REQUEST().
● The request handler can interact flexibly with applications (15); for example, an existing ABAP program can be called or the database accessed.
● During processing, the HTTP request handler can fill the response object with data by setting the Response attribute with the data (16).
● Once the HTTP request handler has performed all tasks, it returns control to the ICF controller (function module HTTP_DISPATCH_REQUEST) (17).
The steps (13+14+15+16+17) can be performed repeatedly so that multiple HTTP request handlers can be used for a single request. This setting is made in transaction SICF.
● The ICF controller (function module HTTP_DISPATCH_REQUEST) now has control again. The controller requests the server control block data from the ICF manager (18).
● The data is serialized from the internal memory representation to HTTP format, and sent to the ICF controller in the HTTP response (19).
● The ICF controller passes the data to the task handler (20), the task handler passes the data to the ICM (21), and the ICM passes the data to the client (22). Here, the data can be displayed as an HTML page, for example.
● The ABAP application program creates an object of the class CL_HTTP_CLIENT (1).
This is done by calling one of the following methods:CL_HTTP_CLIENT=>CREATE, CL_HTTP_CLIENT=>CREATE_BY_DESTINATION or CL_HTTP_CLIENT=>CREATE_BY_URL.
This object is referred to here as the client control block (similarly to the server control block). The ABAP application program that sends the request calls the method.
The structure of class CL_HTTP_CLIENT is described under Interface IF_HTTP_CLIENT.
Note that the activities in points 2, 3, 5, 6, 7, 11, 12 and 13 must also be triggered by the ABAP application program, that is, by calling the appropriate methods. The ABAP application program therefore uses the components of the class CL_HTTP_CLIENT so that it can generate the request data and process the response data.
○ If you want the method CL_HTTP_CLIENT=>CREATE to be called, the following information must be provided for this method: HOST (host name),SERVICE (port), PROXY_HOST (host name of the proxy host), PROXY_SERVICE (port of the proxy host) and SCHEME (specifies whether HTTP or HTTPS should be used; has the default value “SCHEMETYPE_HTTP”). If you communicate using the SSL protocol (“SCHEMETYPE_HTTPS”), you can use the parameter SSL_ID to specify appropriate SSL certificates. If you want to use these certificates to log on to an ABAP Application Server, you can use SAP_USERNAME and SAP_CLIENT to specify the additional information that is required.
If you want the method CL_HTTP_CLIENT=>CREATE_BY_DESTINATION to be called, you have to make the corresponding entries in transaction SM59 for the HTTP destination (node HTTP Connections to ABAP System or HTTP Connections to Ext.. Server). For details on the settings, see Connection Establishment Using Destination (SM59).
There is a central configuration environment for making proxy settings in the system. To access it, call transaction SICF and choose Client -> Proxy Settings.
● The generated client control block is filled by filling the attribute Request with the required request data (2).
● The request is then sent using the method SEND (3). To do this, the connection is opened and the request is converted to a HTTP data stream (serialized).
● Task handlers and the Internet Communication Manager are used to send the request to the required HTTP server (4).
● If the HTTP server requires authentication (for example, if the server is also an SAP System), the client must now log on (5,6,7,8. If the server is also an SAP System, the client logs on via an SAP logon popup. Otherwise, the client logs on via the HTTP standard popup. The query whether the SAP logon popup or the HTTP standard popup should be used is executed within the method RECEIVE (see 6). If you do not want a logon dialog box for the application, you can disable it by specifying the value CO_DISABLED for the attribute IF_HTTP_CLIENT~PROPERTYTYPE_ LOGON_POPUP.
This authentication is carried out in dialog processes, not in batch processes.
If the service is not accessible with this URL, and the response includes a redirect, the ICF manager will redirect the request to the new URL. If you do not want the application to respond this way, you can disable it by specifying the value CO_DISABLED for the attribute IF_HTTP_CLIENT~PROPERTYTYPE_REDIRECT.
If no proxy information has been specified, the ICF manager also evaluates the central proxy settings for the request. If you do not want the application to respond this way, you can disable it by specifying the value CO_DISABLED for the attribute IF_HTTP_CLIENT~ PROPERTYTYPE_APPLY_SPROXY.
● The HTTP server generates a response and sends it back (9,10). When the method RECEIVE is called, the response data is imported and the attribute RESPONSE for the control block is filled (10).
● The data is then processed or displayed by accessing the response attribute (11, 12).
It is also possible to transfer the output to the HTML control. In this case, the response is displayed as it would be in a browser.
● Once the data has been displayed, the connection is closed using the method CLOSE (13).
Once the method CLOSE has been executed, you can no longer access the Request and Response objects.
Once the application has processed your requests and responses, the connection should be closed using the method CLOSE in order to avoid increased resource consumption.
If the AS ABAP is used as a Web client, the running ABAP program creates HTTP requests, sends them to a Web server, and waits for the response from the Web server.
The graphic below illustrates the process.
The Internet Communication Manager ensures that communication between the SAP System (SAP NW Application Server) and the outside world via HTTP, HTTPS and SMTP protocols works properly. In its role as a server the ICM can process requests from the Internet that arrive as URLs with the server/port combination that the ICM can listen to. The ICM then calls the relevant local handler for the URL in question.
You need the ICM if you want your SAP NetWeaver Application Server to communicate with the Internet via HTTP, HTTPS or SMTP, like Web applications do with Web Dynpro ABAP. In AS Java the ICM distributes the incoming requests directly to the Java server processes. For communicating with the client, P4, IIOP and Telnet protocols are used in addition to HTTP(S).
The ICM is a component of the SAP NetWeaver Application Server. It is implemented as a separate process, which is started and monitored by the ABAP dispatcher. With AS Java the startup framework does this task. You can configure the ICM using profile parameters.
More information:
The ICM and the SAP Web Dispatcher use the same code basis. The main difference between them is that the Web dispatcher performs load balancing, and passes requests to ICMs on the connected application servers rather than to work processes. This relationship makes it possible to share profile parameters and administration options. The structure of the documentation makes it clear what applies to the ICM only and what applies also to the Web dispatcher.
More information:
The ICM process uses threads to parallelize the workload.
The following illustration shows a detailed overview of the ICM.
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, places them in the request queue, and creates (or wakes) a worker thread from the thread pool to process the requests. From this point on, thread control initializes the connection info data.
● Worker Threads
These threads handle connection requests and responses. A worker thread contains an I/O handler for the network input and output, diverse plug-ins for the various supported protocols (HTTP, SMTP,…), which are required to be able to decide when the sent packet is finished (depends on the protocol).
More information: Processing HTTP Requests
● Watchdog
Usually, a worker thread waits for the response, regardless of whether the worker thread is a server or a client. If a timeout occurs, the watchdog takes on the task of waiting for the response. This makes the worker thread available for other requests. If the watchdog then gets a response, it places the request in the queue again where it is processed by 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
These memory-based communication objects are used to transfer data between the ICM and work processes (AS ABAP), or between the ICM and Java server processes (AS Java). There are four pipes for every connection: one data pipe per request and response and one out-of-band (OOP) pipe. The OOB pipe is used for control data.
More information: Memory Pipes and MPI Buffers
● Internet Server Cache
The ICM contains another cache to enable repeated requests to be quickly responded to. This cache is not shown in the graphic.
ICM Server Cache
