Soft State Support for OData Services

Soft State Support for Odata Services

• Index

1. Sample Service Details
2. Steps to Configure soft state
3. Steps for Technical implementations
4. Testing soft state in browser
5. Comparisons of response time
6. Implementation considerations

1. Sample Service Details

Service Name: ZCOE_SV_SOFT_STATE
Test URI:  https://***/opu/odata/sap/ZCOE_SV_SOFT_STATE_SRV/ProductSe

2. Steps to Configure Soft State

1. After successful registration of Service on Hub System, Go to Maintenance of Service and activate the Soft state status by pressing the ‘SoftState’ button and follow subsequent steps.

2.  Configure the Session Timeout.

On the lower left part on the screen click on ICF Node –> Configure (SICF)

3. 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.

If the time configured as a session timeout is exceeded, system will fetch data from database.

Save your changes (2) and navigate back to the Service Maintenance Screen.

Once this session time out occurs system will fetch fresh data from database else data available on application server is used.

3. Steps for Technical Implementations

Service Name: ZCOE_SV_SOFT_STATE

Class Name: ZCL_ZCOE_SV_SOFT_STATE_DPC_EXT

   

a. Create attribute ‘MV_IS_SOFTSTATE’ as flag indicator for current soft state session in DPC Extension class.

Also create global static attributes to contain data during soft state session e.g. in this example  GI_HEADER will contain all product data throughout soft state session.

b. Redefine below methods,

◈ ./IWBEP/IF_MGW_SOST_SRV_RUNTIME~OPERATION_START

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.

Code:

 mv_is_softstate = abap_true.

Here we set the soft state variable, which we can use in DPC Ext methods later.

◈ /IWBEP/IF_MGW_SOST_SRV_RUNTIME~OPERATION_END

Method OPERATION_END is supposed to ensure/clear all resources which might get Lost if the current session gets closed.

No code required here, just redefine this method and activate.

Note: If we do not redefine the above methods we will get dump as below.

“Soft State Processing mode is not supported by Data Provider.”

c. GET_ENTITYSET

I have used product get entity set (TABLE: SNWD_PD).

Here we have used variable mv_is_softstate (When soft state is active this variable is always set as abap true).

◈ If this variable is abap_true and our Entity Set table is initial, it means its first hit.

So here we will hit database and fetch the data.

◈ If the mv_is_softstate is set and Entity Set table is not initial, it means we have data available at application server.

We can use the same data.

So here we can save database hits which results in good performance for subsequent requests.

◈ If configured session timeout exceeds (i.e. 10 which we set in configuration Explained above in point 3 of how to configure soft state) system will fetch fresh data from database.

Code :

METHOD productset_get_entityset.

  DATA lv_count_requested TYPE abap_bool.

  DATA : li_pd_header TYPE STANDARD TABLE OF bapi_epm_product_header,

         ls_entityset LIKE LINE OF et_entityset,

         li_category  TYPE STANDARD TABLE OF bapi_epm_product_categ_range.

  IF mv_is_softstate = abap_false OR gi_header IS INITIAL.

    CALL FUNCTION 'BAPI_EPM_PRODUCT_GET_LIST'

      TABLES

        headerdata = li_pd_header.

    "Get Product Type

    zcoe_sv_cl_gw_app_utilities=>get_domain_val(

    EXPORTING    im_domain = CONV #( 'D_PR_TYPE' )

    IMPORTING    ex_domval = DATA(li_type)

          ).

    "TaxCode

    zcoe_sv_cl_gw_app_utilities=>get_domain_val(

    EXPORTING    im_domain = CONV #( 'D_PR_TAX' )

    IMPORTING    ex_domval = DATA(li_tax)

          ).

    SORT li_tax BY domvalue_l.

    SORT li_type BY domvalue_l.

    LOOP AT li_pd_header INTO DATA(li_pd_header_line).

      ls_entityset-product_id            = li_pd_header_line-product_id.

      READ TABLE li_type INTO DATA(li_type_line)

            WITH KEY domvalue_l = li_pd_header_line-type_code

            BINARY SEARCH.

      IF sy-subrc = 0.

        ls_entityset-type-key            = li_pd_header_line-type_code.

        ls_entityset-type-value          = li_type_line-ddtext.

      ENDIF.

      ls_entityset-category              = li_pd_header_line-category.

      ls_entityset-name                  = li_pd_header_line-name.

      ls_entityset-description           = li_pd_header_line-description.

      ls_entityset-supplier_id           = li_pd_header_line-supplier_id.

      READ TABLE li_tax INTO DATA(li_tax_line) WITH KEY domvalue_l = li_pd_header_line-tax_tarif_code BINARY SEARCH.

      IF sy-subrc EQ 0.

        ls_entityset-tax_code-key        = li_pd_header_line-tax_tarif_code.

        ls_entityset-tax_code-value      = li_tax_line-ddtext.

      ENDIF.

      ls_entityset-tax_code-key          = li_pd_header_line-tax_tarif_code.

*Unit Values

      ls_entityset-measure_unit-value    = zcoe_sv_cl_sales_order=>get_uom_value( im_key = li_pd_header_line-measure_unit ).

      ls_entityset-weight_unit-value     = zcoe_sv_cl_sales_order=>get_uom_value( im_key = li_pd_header_line-weight_unit ).

      ls_entityset-dim_unit-value        = zcoe_sv_cl_sales_order=>get_uom_value( im_key = li_pd_header_line-dim_unit ).

      ls_entityset-weight_measure        = li_pd_header_line-weight_measure.

      ls_entityset-price                 = li_pd_header_line-price.

      ls_entityset-currency_code         = li_pd_header_line-currency_code.

      ls_entityset-width                 = li_pd_header_line-width.

      ls_entityset-depth                 = li_pd_header_line-depth.

      ls_entityset-height                = li_pd_header_line-height.

      ls_entityset-product_pic_url       = li_pd_header_line-product_pic_url.

      APPEND ls_entityset TO et_entityset.

      gi_header = et_entityset.

    ENDLOOP.

  ELSEIF gi_header IS NOT INITIAL.

    et_entityset = gi_header.

  ENDIF.

ENDMETHOD. 

4. Testing Soft State in Browser

a. Call the Service in browser,

https://******/sap/opu/odata/sap/ZCOE_SV_SOFT_STATE_SRV/ProductSet

AS its first call, system will fetch data from database.

We can see in below image that mv_is_softstate is ‘X’ and

Entity Set Tables (GI_HEADER and ET_ENTITYSET) are empty

And data is populated as below,

b. When we press refresh (before 10 sec) or session breaks somehow or browser is closed, Data from application server is used.

In below image you can see, internal table gi_header is holding the data.

So we don’t hit the data base here and will use data available at application server.

If we keep pressing refresh, until the time configured as a session timeout is not exceeded, the system will keep using data available at application layer.

If the time configured as a session timeout is exceeded, system will fetch fresh data from database.

c. Now we will wait for some time so configured session timeout exceeded.

Here we can see table gi_header is empty i.e. no data at application layer.

Here system will fetch fresh data form data base.

Please note:

When you wait for a period longer than the one configured as a session timeout in SICF the system will fetch fresh data from database.

Also along with the configured session timeout, there will be additional latency, so we might have to wait for longer else we can click on refresh to end the session.

5. Comparison of Response Times

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

a. Soft State Active.

We can see 2 entries in above image,

First request takes more time as it’s fetching data from database, but if we check second  request there is much performance improvement.

For every subsequent request the Application Data Provider Response time is zero and the GW  framework overhead is reduced by 732 mill seconds.

We can see Processing time for 1st request is 900ms and Application Time is 672ms and For 2nd request its 168 and 0.

        

So Soft State will improve the performance for subsequent requests.

b .Soft State Inactive.

Here first 3 entries are when soft state is inactive.

If we compare the time of both cases we can see significance performance improvement.

Time comparison:

Processing Time:

Soft State Status	1st Request	2nd Request	3rd Request
Active	900	168	NA
Inactive	880	866	830

Application Time:

Soft State Status	1st Request	2nd Request	3rd Request
Active	672	0	0
Inactive	662	674	632

Note:

Here we have Soft State enabled only for specific service.

In addition to activating soft state for individual services, we 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 => SAP Net Weaver > SAP Gateway > OData Channel > Administration > General Settings > Enable or Disable Soft State.

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.

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 (Not for first request but for subsequent requests).

5. 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:

a.The soft state timeout should be short.

b.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.