Since version 7.40, Gateway has become an integral part of SAP NetWeaver. With the release of SAP NetWeaver 7.50 SP04, we have taken the opportunity to use the latest capabilities of the stack to provide some fundamental performance optimizations to Gateway, such as using Simple Transformations for the rendering of the OData service response or the shared use of memory between different Gateway components. The majority of changes made within the Gateway framework are implicitly used. This increases the speed of your application without the need for any additional configuration, independent from the SAP Gateway deployment scenario you are using. If you are using Gateway in Embedded Deployment scenario in SAP NetWeaver on a central instance the performance optimizations are already active by default since the SAP Gateway back-end framework and SAP hub framework components reside on one box.

 

After completing certain configurations on your hub system is acting in a special operating mode called “OData on Backend” and will route most service requests to Gateway on the appropriate back-end server and execute them there locally. This is possible because the functionality of both the Gateway hub and the Gateway backend can now run “co-deployed” in the back end since both frameworks reside in the same software component SAP_GWFND. In this operating mode, the back-end system for instance is capable of serializing the data response with a simple transformation, which will be performed much faster in the SAP NetWeaver kernel instead of ABAP. Those Simple Transformations are automatically created by SAP Gateway for most READ operations.

 

Service Configuration on the Back-End System

Services that should leverage this setup have to be published on the back end.

 

Their settings in /IWFND/MAINT_SERVICE have to be changed such that the co-deployment is used. For this, you have to remove the system alias assignments in the back end using transaction /n/IWFND/MAINT_SERVICES and you have to switch the processing mode to co-deployed.

 

 

HTTP Response Headers

Response with co-deployment (on the back end)

 

When running the following request in the SAP Gateway Client in the back end:

 

/sap/opu/odata/sap/ZPRODUCTS_SRV/SEPM_I_Product_E?$format=json&sap-statistics=true&$top=2

 

You might see the following response:

 

gwtotal=206,gwfw=108,gwrfcoh=0,gwnongw=2,gwapp=96,gwappfw=5,

 

gwappdb=89,gwappext=0,gwappbusi=2,gwhub=0,gwbe=108,icftotal=228

 

Response with hub deployment (on the hub)

 

When running the following request in the SAP Gateway Client in the hub:

 

/sap/opu/odata/sap/ZPRODUCTS_SRV;o=S4HANA/SEPM_I_Product_E?$format=json&sap-statistics=true

 

You might see the following response:

 

gwtotal=147,gwfw=103,gwrfcoh=25,gwnongw=0,gwapp=19,gwappfw=5,

 

gwappdb=11,gwappext=0,gwappbusi=3,gwhub=58,gwbe=45,icftotal=153

 

Response with OData enablement on the back end (on the hub)

 

When running the following request in the SAP Gateway Client in the hub:

 

/sap/opu/odata/sap/ZPRODUCTS_SRV;o=ODATA_ON_BACKEND/SEPM_I_Product_E?$format=json&sap-statistics=true

 

You might see the following response:

 

ssap-statistics

 

gwtotal=53,gwfw=20,gwrfcoh=14,gwnongw=0,gwapp=19,gwappfw=5,

 

gwappdb=11,gwappext=0,gwappbusi=3,gwhub=11,gwbe=9,icftotal=59

 

The response time can be significantly faster. From the http header sap-processing-info, it can be concluded that the OData processing was handled on the back end (ODataBEP=X) and that simple transformation could be leveraged on the back end as well (st=X). The co-deployed flag is set as well since the processing in the back end is leveraging the co-deployed setup.