Show TOC

Soft State Support for OData ServicesLocate this document in the navigation structure

The so-called “soft state” mode enables the SAP Gateway runtime to process several requests in one ABAP application server session, similar to stateful behavior. The only difference is the behavior of the application server after the session times out: Instead of breaking the request processing with a time-out exception the server creates a new session and processes the request as usual. For the consumer the change of the application server sessions is transparent and no data is lost on the client session.

The soft state mode should be used for applications built on legacy functionality in the backend, especially when the functionality includes initial loading/caching of big amounts of data for a single request. By using soft state, the resources/functionality which has been loaded during the initial load can be reused for the subsequent requests of the service.

Thus, the main benefit of soft state is a considerable performance optimization of an OData service.


Data Provider Class (DPC)

In the data provider implementation class of your service make sure that the methods OPERATION_START and OPERATION_END of the interface /IWBEP/IF_MGW_SOST_SRV_RUNTIME are implemented. In case either of them is not redefined and the soft state mode is activated for the service the request processing will be stopped with an exception by the SAP Gateway framework.

  • Method OPERATION_START checks for data which might still be available in the application buffers, alternatively to load the corresponding resources, that is, fill the cache with data needed for processing.
  • Method OPERATION_END is supposed to ensure/clear all resources which might get lost if the current session gets closed.

To prepare OData services for working in soft state mode already in SAP Gateway 2.0 SP08 SAP Note 1986535 Information published on SAP site provides interface /IWBEP/IF_MGW_SOST_SRV_RUNTIME which is required by the SAP Gateway framework.

However, this SAP Note does not contain a pre-delivery of the soft state processing mode for SAP Gateway 2.0 SP08.

Metadata Provider Class (MPC)

In the metadata provider implementation class of your service make sure that the model has been enabled for soft state mode by using the API /IWBEP/IF_MGW_ODATA_MODEL~SET_SOFT_STATE_ENABLED.

Implementation Considerations

When working in soft state processing mode, bear in mind that transactional behavior must not be implemented by using the soft state processing mode and is not provided by the SAP Gateway framework.

  • Regardless of soft state mode, SAP Gateway is stateless and also behaves like in a stateless manner. It means that data is not buffered or made available across application server sessions on SAP Gateway. Buffering of data and access to this data is subject to application coding located in the application backend.
  • SAP Gateway applications (data provider classes) have to make sure that request processing is not broken due to errors happening in the context of buffering or accessing buffered data in the backend. Example: the data provider class is trying to access data which has been buffered by a previous request in the backend application. In case the buffered data is no longer available as the previous session has expired, the data provider must not throw an exception in this case but retrieve the data again in the same way it would be done in a stateless mode.
  • Resources on the server stay occupied as long as the application server session lives. It means that the more services run in soft state mode the more server resources are constantly unavailable. The price you pay for better performance is a higher memory consumption, hence:
    • The soft state timeout should be short.
    • Soft state should only be used in special situations, that is, only for certain entity sets.
  • The application server session which is used to run the service in soft state mode is always user-specific.
  • Soft state mode can only be activated for a single service, not for a group of services, that is, an application server session can only be used by one OData service.
  • The data cached by the data provider of the OData service in the backend during an application server session might get lost or might get outdated.

Currently, URLs containing segment parameters such as ;mo, ;o, or ;v=.. cannot be processed in the soft state processing mode, as the path attribute of the context-id sent to the client must not contain a ;. These kind of URLs are always processed in the stateless mode by the SAP Gateway framework.

The SAP NetWeaver 7.0 component SAP_BASIS does not offer security sessions which are prerequisites for soft sate. Hence, soft state is not available on SAP NetWeaver 7.0 and/or 7.01. Security sessions are available from SAP NetWeaver 7.0 EHP2 onwards (see SAP Note 1322944 Information published on SAP site). There was also a downport to SAP NetWeaver 7.0 EHP1 (see SAP Note 1477428 Information published on SAP site). However, on SAP NetWeaver 7.0 EHP1 only SAP Gateway 2.0 codeline for SAP NetWeaver 7.0 can be used.

The Internet Communication Manager (ICM) handles soft state requests as if they were stateful requests. The SAP Gateway framewok only overwrites the behavior in case of a timeout. See also Stateless/Stateful Communication in the SAP NetWeaver documentation. The framework uses an RFC call to communicate with the backend. Nothing special is being done for soft state. Whether work processes of database connections can be maintained or not is therefore not controlled by the framework.

Note that the default setting for session timeout for a stateful connection is set as 00:00:00 in transaction SICF in section Service Data for an ICF node. This means the session timeout is inactive. The session is terminated after profile parameter rdisp/plugin_auto_logout has run. The default setting for rdisp/plugin_auto_logout is 30 minutes. If you want to change the time when the session context is terminated, set this profile parameter to another value via transaction RZ11. For more information about parameter rdisp/plugin_auto_logout, see the parameter documentation in transaction RZ11.

Activating Soft State Processing Mode on the Hub System
  1. In transaction SICF set the session timeout of your service to a value greater than 00:00:00 on the corresponding ICF node.
  2. Activate the service for soft state mode in transaction /IWFND/MAINT_SERVICE by using the option Soft State. The service is active for soft state if the status is set to Active.
    Possible status:
    • Empty: in this case the metadata for the service has not been updated on the hub system.
    • Not supported: in this case the DPC and the MPC do not have the implementations as described in section Prerequisites.
    • Inactive: in this case the DPC and the MPC do have the implementations as described in section Prerequisites, but soft state mode has not been activated for this service in transaction /IWFND/MAINT_SERVICE. In this case the soft state based query result cache (SQRC) is also not active.
  3. Save your settings.

In addition to activating soft state for individual services, you can also use a central switch which is available in the implementation guide (IMG): In transaction SPRO open the SAP Reference IMG and navigate to Start of the navigation path SAP NetWeaver Next navigation step SAP Gateway Next navigation step OData Channel Next navigation step Administration Next navigation step General Settings Next navigation step Enable or Disable Soft State End of the navigation path. The default setting is an enabled soft state for all services. If you disable this centrally with the IMG activity, then those services which are active remain enabled. The switch is only relevant for the runtime. See also 1986626 Information published on SAP site.

Request Header Based Soft State Session

Instead of a cookie a request header is sent from the client to identify a session as one of the context id transfer alternatives supported by the Web Dispatcher and Internet Communication Manager.

Previously only one session per browser was possible, because the browser manages the cookie handling and the same cookie is used for the same URL in different tabs/browser windows. Now the client can decide when a new session shall be used.

The following new request header fields have been introduced:
  • field: sap-contextid-accept with value: header

  • field: sap-contextid with value: system ID