Soft State

Any OData consumer from the outside world can connect to SAP Gateway by using either HTTP or HTTPS. When this happens, the HTTP request first entered in the internet communication framework (ICF) on the hub is then handled by the Gateway hub framework.

 

From the Gateway framework on the hub, an RFC call takes place to the Gateway framework in the Business Suite back end. Finally the appropriate method in the data provider class in the SAP back end is called.

 

By default the whole communication is stateless. There are however certain business scenarios that do require the caching of data to improve the performance.

 

 

HTTP Stack — Soft State

The session that is held by the ICF framework results in a session held in the back-end system via RFC where the data provider class can cache data in member variables. The data provider cache is highlighted in green in the figure, HTTP Stack — Soft State.

 

The soft state mode should be used for applications built on legacy functionality in the back end, especially when the functionality includes initial loading or caching of big amounts of data for a single request. A typical example would be a price calculation. By using soft state, the resources and functionality, which have been loaded during the initial load, can be reused for the subsequent requests of the service. Therefore, the main benefit of soft state is a considerable performance optimization of an OData service.

 

HTTP Stack — Soft State

The session that is held by the ICF framework results in a session held in the back-end system via RFC where the data provider class can cache data in member variables. The data provider cache is highlighted in green in the figure, HTTP Stack — Soft State.

 

The soft state mode should be used for applications built on legacy functionality in the back end, especially when the functionality includes initial loading or caching of big amounts of data for a single request. A typical example would be a price calculation. By using soft state, the resources and functionality, which have been loaded during the initial load, can be reused for the subsequent requests of the service. Therefore, the main benefit of soft state is a considerable performance optimization of an OData service.

 

 

The soft state mode enables the SAP Gateway runtime to process several requests in one ABAP application server session, in a similar way 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 only thing that the consumer will observe is that the response time will be higher because data that was cached has to be read or calculated again.

 

Steps to Enable Soft State Coding

To enable soft-state, perform the following steps:

1. Redefine the DEFINE method in the MPC_EXT and enable soft state for the data model by calling, as highlighted here.
2. Create an instance attribute MV_IS_SOFTSTATE for the DPC_EXT class that stores the status of whether soft state is activated or not.
3. Redefine the method, as highlighted here, to set this variable.
4. Redefine the method as highlighted.

 

Soft State Configuration

The soft state has to be activated using the transaction /IWFND/MAINT_SERVICE. As a prerequisite, the session time out for the ICF node has to be set to a value larger than 00:00. This can also be done from within the transaction /IWFND/MAINT_SERVICE using the ICF Node button.

 

 

Soft State Based Query Result Cache

The soft state based query result cache resides in the Gateway hub.

 

If activated, it can serve as a cache, avoiding unnecessary calls to the back end if the client only wants to navigate through a result set.

 

 

Soft State Enabled Query Result Caching