Stateless/Stateful Communication
Use
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 statefulcommunication 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).
Prerequisites
· 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 statefulcommunication. 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.
Features
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.
Activities
1. There are two ways of defining stateful communication:
2. You are using 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.
3. 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.
Example
The following example describes how you can set up a statefulcommunication. 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 NOT stateful IS INITIAL. IF stateful = 0. CALL METHOD server->set_session_stateful EXPORTING stateful = if_http_server=>co_disabled path = ''. ELSEIF stateful = '1'. CALL METHOD server->set_session_stateful EXPORTING stateful = if_http_server=>co_enabled path = ''. ENDIF.
|
Additional Information
For more detailed information on using stateless/stateful communication with BSPs, see:
·
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.