Architecture 

This section describes the interaction between the individual software layers; this interaction enables an application to generate a response to a request. In the scenario described here, a client (such as a Web browser) sends an HTTP request to the server. The Internet Communication Framework (ICF) forwards the request to an application. The application then gathers data as a response and sends it back to the client through the ICF. The browser displays the data in the response.

 

‑{}‑

 

In the graphic, the arrows represent the control flow and data flow.

 

These steps are described in detail in the following section:

The request is sent to the Internet Communication Manager (ICM) (1). The ICF decides whether the resource identified by the URL (the application) is realized in the ABAP stack or Java stack of the Web 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 data of the request to the ICF manager (8+9+10), where it is stored in the Requestattribute 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.

 

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.

 

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 a 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). Several different logon options are available (see Logging on to the SAP Web Application Server), including: These are for example:

 

       1.      HTTP Basic Authentication: For HTTP Basic Authentication, the Web browser generates a dialog box in which a user name and password need to be entered. This data is then sent directly to the SAP system. When the client logs on to the SAP System, the default client and the default language of the application server are used.

       2.      Defining user and password in transaction SICF: The logon data required for a HTTP request handler (or, to be more precise, for the service to which this HTTP request handler is assigned) can also be set in the service table (from transaction SICF). For more details, see the section Anonymous Logon Data.

       3.      Certificate Logon: In a certificate logon, you can send the logon data during the technical logon.

If the logon fails, the system attempts to log on again before terminating communication. If the authentication is successful, the request can be processed by the HTTP request handler.

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 implementation of the method HANDLE_REQUEST() contains the special properties of a specific HTTP request handler. 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 finished, it returns control to the ICF controller (function module HTTP_DISPATCH_REQUEST) (17).

 

 The steps (13+14+15+16+17) can be performed repeatedly, to enable multiple different HTTP request handlers to be used for a 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). This 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 is displayed as an HTML page, for example.

 

In the following section, you can read about the Classes and Interfaces for the Server Role.