Show TOC

Background documentationServer Architecture Locate this document in the navigation structure

 

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.

This graphic is explained in the accompanying text.

Note Note

The arrows in the graphic represent the control flow and data flow.

End of the note.

Explanation:

  • 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 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.

    End of the example.

    Note Note

    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.

    End of the note.

  • Once the HTTP request handlers have been determined, the client is authenticated (12).

    Note Note

    There are a number of logon procedures. If the logon fails, the system attempts to log on again before terminating communication.

    End of the note.

  • 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 rRequest). 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).

    Note Note

    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.

    End of the note.

  • 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.

More Information

For more detailed information concerning HTTP request handlers, services and logon procedures, see: