Introduction

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 backend framework and SAP hub framework components reside on one box.

Figure 1: Embedded Deployment

To enjoy the full benefits in a Central Hub Deployment architecture (see figure below) there are certain improvements which need to be customized explicitly and your backend has to be based on SAP NetWeaver 750 SP04 or higher.

Figure 2: Central Hub Deployment with OData Backend Enablement

You can find a more detailed information about the different deployment options in my blog  SAP Gateway deployment options in a nutshell

What you achieve

After completing the configurations described in this blog your hub system is acting in a special operating mode and will route most service requests to Gateway on the appropriate backend 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 backend since both frameworks reside in the same software component SAP_GWFND.

In this operating mode the backend system for instance is capable to serialize 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.

There you also find a troubleshooting section. ;-).

Prerequisites

• Both Hub and Backend systems need an SAP_GWFND NW750 SP04 version or later.

• Before continuing with those steps please read SAP Note 2349910 to be aware of the prerequisites and constraints of this operating mode. 
• Please also refer to the note 2302549 – Performance optimizations for the SAP Fiori Stack for installation prerequisites and further optimizations options which is also mentioned in SAP Note 2349910

• Please note that the services need to be declared as active in the backend system.

• The optimization will not work for service requests, where the routing will involve different or multiple backends, as is the case for Multi Origin Composition.

Please note:
The term “Micro Hub” does not indicate a new or different Gateway hub. It is merely the normal hub, only now it is configured to forward valid OData service requests immediately to the backend for further processing.

Demo scenario

To compare the behaviour of the different deployment options

• Co-deployment in the backend
• Central Hub Deployment
• Central Hub Deployment with OData Enablement on the backend

we will create a service ZSALESORDER_HUB_SRV in the backend system using SEGW based on my blog OData service development with SAP Gateway – code-based service development – Part I

The service ZSALESORDER_HUB_SRV will be published on both the hub and the backend.

Configuration steps

Step 1 ­­– SAP system alias customizing in the hub system

1. Open Transaction “SPRO” on the hub system
2. Click on “SAP Reference IMG”
3. Follow the path “SAP NetWeaver” -> “SAP Gateway” -> “Configuration” ->
   ”Connection Settings” -> “SAP Gateway to SAP System” ->                                                “Manage SAP System Aliases”
4. Enable OData processing on the backend for SAP system alias (See screenshot).
   a) Either create a new SAP system alias and choose the “Use Micro Hub” check box
   or
   b) Adjust an already existing SAP system alias by choosing the “Use Micro Hub” check box.

For our demo scenario we create a two system alias entries called  “ODATA_ON_BACKEND” with the “Use Micro Hub” flag checked and “ODATA_ON_HUB” with the “Use Micro Hub” flag not checked that both point to the same backend. To achieve this we are using the same RFC destination that points to our backend system in both system alias entries.
By calling the service in the backend using two different system alias entries we are able to compare the response times more easily than by changing the configuration of just one system alias entries.
In a real world scenario you will probably use just one setting that does best fit your needs.

Step 2 ­­– Create and publish test service on the backend

1. Create a projects ZSALESORDER_HUB using the service builder using my blog mentioned above.
2. Register and publish the service locally on the backend system as described in the the blog mentioned above.
3. Change the registration such that the co-deployment is used. For this you have to remove the system alias assignements in the backend using transaction /n/IWFND/MAINT_SERVICES and you have to switch the processing mode to co-deployed as shown in the following screen shot.

If you press the button “Processing Mode” you can change the processing mode from “Routing-based” to “Co-deployed only”.

Step 3 ­­– Publish test service on the hub

Since we have registered the service on the backend system we can also publish it on the hub using /n/WFND/MAINT_SERVICE on the hub.
As shown in the following screen shot we are registering the service for both system alias entries ODATA_ON_HUB and ODATA_ON_BACKEND.

Step 4 – Verify the usage of simple transformation (ST) in the backend

Open transaction /n/IWBEP/GLOBAL_CONFIG in the backend system
Check that “Use Transformation for Data Response Serialization” checkbox is selected

Result

If you have set up an OData service as described above most requests containing a READ operation on entity sets are going to benefit from the performance improvements.

The following requests, based on our demo service will illustrate the performance improvements.

/sap/opu/odata/SAP/ZSALESORDER_HUB_SRV;o=ODATA_ON_HUB/SalesOrderSet?$format=json&sap-statistics=true

/sap/opu/odata/SAP/ZSALESORDER_HUB_SRV;o=ODATA_ON_BACKEND/SalesOrderSet?$format=json&sap-statistics=true

As you can see in the URL there are two parameters appended. Firstly the specific content type “json” as this is a prerequisite for using the ST to work and secondly the access to the SAP Performance Statistics from the SAP Gateway framework (further information about sap-statistics and the different characteristics replied from the system can be found here: SAP Performance Statistics).

In addition we use (only for demo purposes (!) the segment parameters ;o=ODATA_ON_HUB and ;o=ODATA_ON_BACKEND to force the SAP Gateway hub framework on the hub either to process the OData request itself or to route the processing using the OData hub framework on the backend using the system alias with the Micro Hub flag checkbox chosen.

You can use the sap-processing-info header which is available in the HTTP response header to validate that the change you made are effecting your service.

The HTTP response header sap-processing-info is available to indicate the processing mode of a request. It includes the following flags:

Table: Flags in the HTTP response header sap-processing-info (Source SAP Online Documentation)

So in the end an actual result including some statistic values and processing info confirm which optimizations are active and which portions of the service request were accelerated.

HINT: The actual numbers of the request will obviously vary for different hardware and services.

The numbers mentioned above can be retrieved using the SAP Gateway Client using transaction /n/IWFND/GW_CLIENT

Figure: Testing using the SAP Gateway Client

Response with Hub-Deployment (on the hub)

When I ran the following request in the SAP Gateway Client in the hub
/sap/opu/odata/SAP/ZSALESORDER_HUB_SRV;o=ODATA_ON_HUB/SalesOrderSet?$format=json&sap-statistics=true

I observed the following response:

sap-statistics                gwtotal=1600,gwfw=1470,gwrfcoh=60,gwnongw=0,gwapp=70,gwhub=1160,gwbe=310,gwbewait=0,gwappsum=69

sap-processing-info       microhub=,crp=,st=,MedCacheHub=SHM,MedCacheBEP=SHM,codeployed=,softstate=

Response with OData enablement on the backend (on the hub)

When I ran the folloiwing request in the SAP Gateway Client in the hub

/sap/opu/odata/SAP/ZSALESORDER_HUB_SRV;o=ODATA_ON_BACKEND/SalesOrderSet?$format=json&sap-statistics=true

l observed the following response:

sap-statistics
gwtotal=155,gwfw=69,gwrfcoh=13,gwnongw=0,gwapp=73,gwhub=19,gwbe=50

sap-processing-info       microhub=X,crp=,st=X,MedCacheHub=SHM,MedCacheBEP=SHM,codeployed=X,softstate=

The response time is significantly faster. From the http header sap-processing-info it can be concluded that the OData processing was handeld on the backend (microhub=X) and that simple transformations could be leveraged on the backend as well (st=X). The codeployed flag is set as well since the processing in the backend is leveraging the co-deployed setup.

Response with co-deployment (on the backend)

After having proved that the handling of the OData request on the backend was much faster due to leveraging the co-deployment on the backend I checked the response time of the OData service on the backend itself.

When I ran the folloiwing request in the SAP Gateway Client on the backend

/sap/opu/odata/SAP/ZSALESORDER_HUB_SRV/SalesOrderSet?$format=json&sap-statistics=true

I observed the following response:

sap-statistics 
gwtotal=138,gwfw=64,gwrfcoh=0,gwnongw=0,gwapp=74,gwhub=0,gwbe=64

sap-processing-info 
microhub=,crp=,st=X,MedCacheHub=SHM,MedCacheBEP=SHM,codeployed=X,softstate=

which is slightly faster than Hub deplyoment with OData backend enablement.

It shows that simple transformation are used as well as co-deployment.

Troubleshooting

Response time using the “use micro hub” flag is not faster

One error that I stumbled on when I configured this setup was that I forgot to patch the kernel in my sandbox system. As a result I wasn’t able to observe a significant improvement in the processing times of my requests.

It turned out that no ST could be generated. This could be retrieved from the http header sap-processing-info (st=,) of the http response and from appropriate error messages in the SAP Gateway error log /n/iwbep/error_log in the backend system:

Insufficient kernel version to generate transformation (see note 2296165)
Message no. /IWBEP/CM_ST164

So it is mandatory to read the SAP Notes mentioned in the prerequisites section carefully since it is mentioned there to update the kernel ;-).

Service not published on the backend

If you have not published the service also on the backend the following error will be raised if you run the request using the system alias “ODATA_ON_BACKEND” that has the flag “use micro hub” flagged.

{
“error” : {
“code” : “/IWFND/MED/170”,
“message” : {
“lang” : “en”,
“value” : “No service found for namespace , name ZSALESORDER_HUB_SRV, version 0001”
},
“innererror” : {
“application” : {
“component_id” : “”,
“service_namespace” : “/SAP/”,
“service_id” : “ZSALESORDER_HUB_SRV”,
“service_version” : “0001”
},
“transactionid” : “6DE86BB8805200E0E0057FC00CD472BD”,
“timestamp” : “20161012135534.9410000”,
“Error_Resolution” : {
“SAP_Transaction” : “Run transaction /IWFND/ERROR_LOG on SAP Gateway backend system (System Alias ODATA_ON_BACKEND) and search for entries with the timestamp above for more details”,
“SAP_Note” : “See SAP Note 1797736 for error analysis (https://service.sap.com/sap/support/notes/1797736)”
},
“errordetails” : [

]
}
}
}