How to use Soft-State support for OData services

[Andre_Fischer]

Updates

• 17.03.2015 added information that security session management has to be activated


• 11.10.2019 changed layout after the automatic conversion so that screen shots are again visible

Introduction

 

The so-called “soft state” mode enables the SAP NetWeaver 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 session that is held by the ICF framework results in session held in the backend system via RFC where the data provider class can cache data in member variables. The Data Provider Cache is highlighted in green in the following figure.



 

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. A typical example would be a price calculation.

 

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.

 

 

Prerequisites

 

You have created a sample OData service using the Service Builder as described in my SCN document How to Develop a Gateway Service using Code based Implementation .

 

Important:

In order to use soft state it is mandatory that HTTP Security Session Management on AS ABAP has been activated. Security session management can be managed using transaction SICF_SESSIONS as described in the SAP Online Help:

 

Activating HTTP Security Session Management on AS ABAP - User Authentication and Single Sign-On - SA...

 

Even if secúrity session management is not being activated a service currently is shown as active for soft state but does not work as supposed.

 

 

Overview - Implementation steps to activate Softstate for your service

 

1. Redefine the DEFINE method of the model provider extension call


2. Create an instance attribute MV_IS_SOFTSTATE for the DPC_EXT class that stores  the status whether soft state is activated


3. Redefine the method /IWBEP/IF_MGW_SOST_SRV_RUNTIME~OPERATION_START to set this variable

 

 

Implementation steps in the model provider class

Steps	Result
1. Start maintaining the model provider extension class ZCL_ZGW_PRODUCT_MPC_EXT
2. Redefine the DEFINE method of the MPC_EXT class	method DEFINE.   super->define( ).   model->set_soft_state_enabled( abap_true ). endmethod.

 

Implementation steps in the data provider class

Steps
Start maintaining the data provider class ZCL_ZGW_PRODUCT_DPC_EXT
Click on the Attributes tab and insert a new attribute with the following Settings Attribute MV_IS_SOFTSTATE Level Instance Attribute Visibility Private Typing Type Associated Type ABAP_BOOL Description TRUE if we are running in softstate mode
Click on the Methods tab and redefine the method /IWBEP/IF_MGW_SOST_SRV_RUNTIME~OPERATION_START and enter the following line of code   mv_is_softstate = abap_true.
method /IWBEP/IF_MGW_SOST_SRV_RUNTIME~OPERATION_START. mv_is_softstate = abap_true. endmethod.
Now click on the Methods tab and redefine the method /IWBEP/IF_MGW_SOST_SRV_RUNTIME~OPERATION_END without entering any code.   Please note: Without activating both methods you would get an exception
Now define a second (static) attribute GV_COUNT of type I to demo the use of soft state   Click on the Attributes tab and insert a new attribute with the following settings: Attribute GV_COUNT Level Static Attribute Visibility Protected Typing Type Associated Type I Description Store counter
Activate your changes
Navigate back to the Service Builder and expand the folder Service Maintenance. Expand the folder Maintain. Right click on the entry of your Gateway Hub system  to start the transaction /IWFND/MAINT_SERVICE with filtered for your service name
Confirm the warning of being redirected to the Hub system
You will notice that the service ZGW_PRODUCT_SRV is shown as not supporting Soft-State. If you click on the Soft-State button (1) you will get an error message
Confirm the error message.
Click on Load Metadata and confirm the sucess message
The service is now shown such  that it supports soft state but soft state is not yet activated. Hint: If the service is not shown as inactive try to clear the metadata cache in the Gateway Hub as well as in the Gatebay backend system. To do so: Start transaction /IWBEP/CACHE_CLEANUP in the backend and activate the check box Cleanup Cache for all Models. Start transcation /iwfnd/cache_cleanup on the hub and run it with the check box Cleanup Cache for all Models.
Change the session time out
On the lower left part on the screen click on ICF Node --> Configure (SICF)
Double Click on the entry of your service in the SICF tree
From the menu choose Service --> Change (1) and enter a Session Timeout greater than zero, for example 10 seconds. Save your changes (2) and navigate back to the Service Maintenance Screen
Since the service should now shows up with the Softstate-Status Inactive you can now activate the softstate status by pressing the softstate button.
Confirm the warning before activating soft state for your service and confirm the information that softstate has now been activated.
Use of softstate in the data provider extension class
Open ZCL_ZGW_PRODUCT_DPC_EXT in SE24
Change the implementation of the method  PRODUCTSET_GET_ENTITYSET to enable a custom counter when $count is called for the entity set ProductSet with the coding shown on the right. The coding first checks whether /$count is requested and has implemented a custom implementation to retrieve $count. If soft state is not enabled the number of products will be retrieved by counting the table entries in SNWD_PD. If soft state is enabled the code checks whether the member variable GV_COUNT is inital. If it is initial that means if the /$count is called for the first time in this session we have to retrieve the number of entries from the database. Only if /$count is called a second time when soft state is enabled no data will be read from the database and /$count will rather be filled with the value stored in the variable GV_COUNT which is then incremented by 1 to show you that soft state is actually working. If the time configured as a session timeout is exceeded counting starts again from the number of products which is equal to the number of table entries in table SNWD_PD.
Activate your changes.

 

 

Test the service in the browser

 

 

Steps
Call your service via the browser.
http://<server>:<port>/sap/opu/odata/sap/ZGW_PRODUCT_SRV/ProductSet/$count
When refreshing the URL you will notice that the counter will start to count the number of calls.
Wait for 20 seconds …
When you wait for a period longer than the one configured as a session timeout in SICF the counter starts with 1 again. Please note: If you have configured a small time window (for example 10 seconds) you will probably have to wait longer since there is an additional latency. If you are too impatient and click on refresh to fast the wait time starts again from zero.

Comparison of response times

The behaviour when using soft state or not can nicely be checked using the performance trace. This can be started using transaction /IWFND/TRACES.

 

Steps
Start a performance trace using /IWFND/TRACES. Perform several requests with $count having soft state enabled
We can see that the initial request takes 16 milliseconds in the backend (GW framework overhead + Application Data Provider response time). For every subsequent request  the Application Data Provider Response time is zero and the GW framework overhead is reduced to 5 mill seconds.
Deactivate soft state and perform again several requests with $count
The result now is that subsequent requests have the same response time. The response time is the same that we got for the first initial request when soft state was enabled.