Show TOC

Stateless/Stateful CommunicationLocate this document in the navigation structure


The Internet Communication Framework supports both Stateful and Stateless communication in the server role. In the case of Stateful communication, all user activities in a session are performed in a single context (role area) -as in a 'normal'transaction.

It is always advisable to use stateful communication if a user's data and activities need to be kept for the whole duration of a session.

For the ICF, this means that the lifetime of a special HTTP request handler extends beyond an individual request.

Stateless mode is the default setting. The attribute STATEFUL in the server control block therefore has the value CO_DISABLED (see IF_HTTP_SERVER).

  • You must carefully consider whether Stateful mode is required, since this mode places more strain on the server, which can result in poorer performance.

  • You also need to ensure that the context is changed to Stateless after completion of a Stateful communication. Otherwise, after the connection has been terminated, the Stateful session would remain active until the session times out automatically. This would lead to performance problems in the application server.


If you work with Stateful communication, you need to consider the following points:

  • In a single session (restricted by the lifetime of the corresponding user context), more than one HTTP request handler can be involved in a series of requests .

  • There is never more than one instance of a special HTTP request handler in existence at any one time within the one session. In other words, a corresponding HTTP request handler instance is either re-used for sequential requests (default) or is reinstantiated for each individual request (if required, by the HTTP request handler itself).

  • It is only possible to re-use the HTTP request handler instance if the same URL is used as in the last request. If the same request handler is being used by a different URL, the object is reinstantiated.

  • Since HTTP requests differ from each other in their design, and do not provide any inherent support for session contexts, this kind of context must be artificially constructed.


There are two ways of defining Stateful communication:

  1. You use the set_session_stateful method. In this case, you need cookies to be able to maintain a session context.


    The method set_session_stateful sets a cookie if one is required and none have yet been set. To identify the session context, the client must send this cookie back to the server with the next request.

  2. You are using the set_session_stateful_via_url method. In this case, you do not need cookies, as the context information is included in the URL of a request.


The following example describes how you can set up a stateful communication. Here, the request sends the reserved form field Stateful to the HTTP request handler. If the setting = 1, then a Stateful communication is started, otherwise the communication remains Stateless.


* Stateful/Stateless
DATA: stateful TYPE string.

stateful = server->request->get_form_field( 'stateful' ).

IF stateful = 0.
CALL METHOD server->set_session_stateful
stateful = if_http_server=>co_disabled
path = ''.
ELSEIF stateful = '1'.
CALL METHOD server->set_session_stateful
stateful = if_http_server=>co_enabled
path = ''.


More Information

For more detailed information on using stateless/stateful communication with BSPs, see:

  • Stateful BSP Applications

  • Stateless BSP Applications

  • Stateful or Stateless Programming?


    The ICF service Example_1 (default_host/sap/bc/icf/demo/example_1) illustrates the behavior of stateless and stateful communication. For this purpose, this example contains a counter.

    When you execute a request in a Stateless communication, the counter stays at 1; whereas in a Stateful communication, the counter is raised according to the number of calls.