Setting as Stateless or Stateful Web Request (SAP Library

Setting as Stateless or Stateful Web Request

Use

You must weigh up the pros and cons of executing these as stateful or stateless BSP applications for the conception of your Web requests. Technically, both are supported for Web requests, including mixed forms.

It is generally recommended to create BSP applications intended for a large number of users at the same time as stateless. The main point here being that high volumes of parallel users could overload the working memory of the SAP Web Application Server (Web AS). Stateful BSP applications are therefore only suitable for more complex applications that are used by a limited number of users at a time. Ideally, processor views are best suited to stateful BSPs.

For more information on this, see the SAP Library, under Structure link Session Handling.

Features

In earlier releases all Web requests were generated as stateful BSP applications. As of Release CRM 40 Add-On for Service Industries the stateless edition is also provided for Web requests and Web requests are generated by default as stateless BSP applications. A conversion to stateful is possible without any problems.

Stateless BSPs and Server-Page Cookies

Stateless BSP applications remain on the Web AS only as long as working memory and an individual request are available. Once the request has been processed, the working memory is released again. To prevent data being lost for further processing, the data is stored temporarily as Structure link server-side Cookies. This supports method calls OnManipulation (save data) and OnRequest (reading data). The validity period of the server-side cookies is preset for Web requests to five hours. A session is terminated once this time has elapsed.

Note

Note that the data contained in the cookies is not automatically deleted from the database when a session is terminated and therefore blocks space unnecessarily. These expired cookies can be deleted using program BSP_CLEAN_UP_SERVER_COOKIES. It is advisable to schedule this program regularly as a background job.

Blocking Stateless BSPs

It is not possible to block a request with stateless BSP applications. You should therefore make sure that a request cannot be changed simultaneously (for example, by setting a different status in the service order).

If the exception case applies, that of two users being able to access the same request data to make changes at the same time, the data changes made by the person to save first are saved. An error message is issued when the second person tries to save the same version, thereby preventing the same version being saved again. The changes to the request data are normally saved as versions (see Versioning Web Requests).

Stateless Programming

The Roll area is reduced with each round trip with stateless BSP applications. This means that all data in the puffer gets lost. For this reason, you cannot for example program on the global variables of function modules.

For more information on storing data temporarily, see Structure link Stateless BSP Applications.

If you use a BAdI implementation in a stateless BSP application, you can read parameter ID_STATELESS and program it accordingly.

Stateful BSPs

It may be useful for certain scenarios to use these as stateful BSP applications. You can define this in the Web Application Builder for a BSP application as follows:

a. If the whole BSP application should be stateful, define this for a BSP application on the Characteristics tab page. All pages of the BSP application can then be executed as stateful sessions automatically.

b. If only certain pages, for example the view of the processor, should be stateful, you must define this for the individual BSP pages on the Properties tab page in the screen section State by setting the option Stateful from here and the lifetime Session.

Note

Make sure that it is not possible to switch from a stateful page to a stateless page within a request category view. If this is possible, the current request data gets lost.

For more information, see Structure link Stateful BSP Applications.

Service Order Instances

As of Release CRM 4.0 SP02 it is possible to access service order processing already at runtime using a Service Order Instance. As an example, this is used to calculate the price in sample request SAP_DEMO05. A rethink is necessary for stateless BSPs:

· For price calculations or similar tasks, the data from the whole service order must be accessed. A new service order instance must be created for each round trip for this using CRM_ORDER_MAINTAIN.

· The modules from function group CRM_WEBREQ_ONLINE_PRICING are constructed in such a way that first the global data is set and then posted using module CRM_WR_ORDER_MAINTAIN. This update is required at the end of each BAdI method in stateless sessions (for example FORM_ON_EVENT).

· If you want to support that field entries can be made in the request form with real time, you can do this with event SUBMIT in the BAdI method FORM_ON_EVENT.

· If you want to save data temporarily (for example, attachments), request fields or hidden fields can be used in the layout for smaller data amounts. For larger amounts of data, you should use Structure link Server-Side Cookies.