Stateless BSP Applications
Stateless BSP applications only block resources on the SAP Web Application Server during the time one single request is being processed When the request has been processed, all resources in particular the application context are returned to the system for use in other requests.
Stateless applications allow - at least from the viewpoint of the memory resource - optimal scaling regardless of the number of users. On the other hand, releasing the application context after every request may mean that identical data is read from the database and formatted multiple times. In this respect, the runtime may offset the memory saving. This should be evaluated and analyzed on a case by case basis.
Rule of Thumb: Stateful or Stateless?
As a rule of thumb, it is recommended that Internet scenarios used at the same time by a large number of users operate in stateless mode. Stateful programming is recommended for more complex applications that are used by a limited number of users in parallel and that operate with data that is expensive to determine.
Retaining Information in Stateless Mode Through Multiple Requests
The question arises of how to save information in stateless applications, such as user entries, across multiple requests despite the loss of the application context after each request. For this purpose, you must program the following functions for the application. Possible technical solutions include the following options:
-
Temporary (Invisible) Storage of Data on the Web Site Itself:
This can be done by means of what are called HTML hidden fields, for example: <input type=hidden name="customerID" value="4711">
You can include hidden fields by implementing a page fragment, which is embedded in each page of the application. You can easily define the attributes you want to save in the application class itself. The page fragment is then embedded in each Web site. The application attributes from the request (we are working in stateless mode) are restored in the OnRequest event handler of the page (or preferably in the ONREQUEST method of the Interface IF_BSP_APPLICATION . You should pay particular attention to hyperlinks and to including the parameters you want to save, for example, in the query string part of the URL from the application.
-
Storing Data in Client-Side Cookies:
You must ensure that the size and number of cookies that can be saved in a Web client/browser is strictly limited.
-
Server-Side Cookies:
The BSP runtime provides a generic mechanism - known as server-side cookies - that can be used to efficiently store data types of any kind and number. For more information see Class CL_BSP_SERVER_SIDE_COOKIE as well as Data Persistency With Server-Side Cookies .
-
Application-Specific DB Table for Temporary Data Storage
The application provides a database table specially designed to meet the specific requirements of the data to be saved. Unlike server-side cookies appropriate typed tables can be used here. These tables can provide for better performance than the generic solution. However, this solution involves considerable application programming (in particular, release of the database entry). The session ID can be used to identify an entry and can be accessed through the programming Interface IF_BSP_RUNTIME .