Stateful BSP Applications

Use

A stateful BSP application is executed like a "normal" SAP transaction, - independent of all user interactions - in one single context (roll area). This means that data specified by the user during the application execution or data determined by the application itself is available potentially throughout the entire execution duration of the session.

Since the HTTP protocol itself operates in stateless mode and knows no implicit mechanism to assign independent requests to a common logical session, the BSP runtime uses Session Cookies to group requests into one common session. The name of the cookie is sap-contextid, the validity area is restricted to the URL of the BSP application. This means that a BSP application can be executed within a browser only once at any one time. Different BSP applications can operate in parallel in the same browser. Multiple users/browsers can execute the same BSP application in parallel as often as required.

Advantage

The main advantage of stateful BSP applications is that they are simple to program. As usual, you have access to data determined previously and reading or re-calculating data can often be omitted. For database-intensive applications, this can lead to considerably better system performance compared to a procedure where identical read operations have to be executed for every request.

Disadvantage

This significant advantage is at the same time however a disadvantage - the improved runtime is offset by a larger memory requirement. The number of possible parallel sessions in an SAP Web Application Server is restricted not least by the amount of available memory space. When this space is exhausted, no further sessions can be started and users cannot log on.

A further advantage is the fact that, unlike SAPGUI, Web browsers do not log off servers, that is, if users navigate in their Web browsers to a different Web site, the SAP Web Application Server is not be informed. Thus, an open session cannot be terminated and is retained in the application server until the context is released by the timeout mechanism. Since this can take some time, scarce resources are unnecessarily blocked in the application server.