Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Data Interfaces and Communication Interfaces 

ICF - Internet Communication Framework

Internet Communication Framework (ICF) is a programming interface (API), based on interfaces and classes, used by ABAP programs to communicate with the Internet. ICF supports the Internet protocols HTTP, HTTPS, and SMTP. All communication between ABAP and the Internet based on these protocols takes place using ICF. ICF is a simplified technical foundation that can be used by more advanced programming interfaces. This means that ABAP programs do not usually access ICF directly and wrappers are used instead, such as Business Server Pages, Web Dynpro ABAP, Web Services ABAP, or ODATA-based services. Wrappers like these ensure that the conventions required for external communication are met, such as the model view controller approach (MVC) in Web Dynpro or Simple Object Access Protocol (SOAP) in Web services.

To communicate with the Internet using REST principles (Representational State Transfer), the interfaces and classes in the ABAP REST Library in the package SREST should be used, since they adapt ICF accordingly.

Other versions: 7.31 | 7.40 | 7.54


Information about communications using the WebSocket protocol can be found under ABAP Push Channels.

ICF Overview

The following figure is a (highly simplified) schematic overview of communications between ABAP and the Internet using ICF. It uses HTTP communication as an example.


The actual communication of the SAP NetWeaver application server with the Internet takes places through its Internet Communication Manager (ICM). The manager itself communicates with an AS ABAP work process, whose task handler controls ICF.

Communication can run in either direction, meaning that AS ABAP can be a server or a client. Within ICF, this aspect is implemented using different branches with their own interfaces and classes. ABAP programs can both respond to requests from the Internet and provide a service with data for further handling and itself query data from Internet. This is done by implementing the appropriate interfaces.


  • Before each response is sent in an ICF server program or ICF client program, a database commit is executed (except for during the update process).

  • HTTP communication is not bidirectional, which means that one partner is always the client and one partner is always the server. Bidirectional communication is possible by using the WebSocket protocol and ABAP Push Channels.

ICF Services

AS ABAP services that are to be accessed from the Internet need to be created as nodes in transaction SICF. This determines the properties of the service too. An ICF service is a transportable repository object.

The initial node of the service tree stands for the AS ABAP Web address consisting of the host and the port. The position of the node in the tree determines the further URL path required to call a specific service. A URL can contain form fields after the actual address part, which are read by ICF.

Before a response can be made to a HTTP request sent to a service in the service tree in transaction SICF, at least one global class must be assigned to this service. This class must implement the interface IF_HTTP_EXTENSION and have access to the ICF infrastructure. When a request is sent to the service, ICF creates a HTTP request handler as an instance of this class. The implemented interface has only one method, HANDLE_REQUEST, whose input parameter SERVER is a reference to the service represented by IF_HTTP_SERVER. The attributes and methods of the service make it possible to query properties of the request, such as the content of the form fields in the URL and to pass data to the server in a suitable format, such as HTML or XML. The most important are the attributes REQUEST and RESPONSE, which refer to objects that implement the interfaces IF_HTTP_REQUEST or IF_HTTP_RESPONSE.


  • While a HTTP request is being handled in a HTTP request handler, the ABAP program is in a special context in which certain statements, such as MESSAGE or BREAK-POINT, are handled differently than, say, in dialog processing. External breakpoints can be set to debug programs in this context.

  • Special URL form fields, such as sap-user, sap-client, or sap-language, all start with the prefix sap- and are evaluated when ICF is used for logons to AS ABAP.

  • A special handler class can be used to access objects from the MIME repository directly using ICF services (see the example).

  • Alongside the nodes that represent HTTP services, the nodes for ABAP Push Channels addressed using the WebSocket protocol are defined in the service tree in ICF.


  • One production example of a self-programmed HTTP service is the Web version of this documentation itself.

ICF Clients

If the proxy setting for the HTTP client is configured appropriately in transaction SICF, ABAP programs can send requests to the Internet using ICF and receive responses. This is done using client objects from the class CL_HTTP_CLIENT, which implements the interface IF_HTTP_CLIENT. A client object can be created using a factory method from this class, which associates it with a Web address. Like a HTTP server, the attributes REQUEST and RESPONSE reference objects that implement the interfaces IF_HTTP_REQUEST or IF_HTTP_RESPONSE and that can be used to send requests and receive responses.

ICF Security

The API of the ICF enables virus scans to be run using the virus scan interface (VSI). The required virus scan profile for the scan can be selected.


See ABAP as HTTP Client.

More Information

  • Fo more information on ICF and ICM, read the

SAP NetWeaver documentation in SAP Help Portal.

  • This documentation also describes communication between AS ABAP and the Internet, based on class wrappers or ICF enhancements such as ABAP Web Services or the ABAP REST Library.


ICF Examples