Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert


  • 26.11.2014

    • added SAP Note 2038379 as a prerequisite

    • added link to constraints

  • 23.02.2015

    • added information that as of SP7 SEGW should be used

    • added information that for SAP Fiori like scenarios that consume SAP HANA XS OData services a SAP Web Dispatcher or SAP API Management should be used

  • 13.12.2019

    • added new recommendation to use SAP Web Dispatcher as a proxy instead of SAP Gateway

Recommendation: Use SAP Web Dispatcher

In the scenario described in this article SAP Gateway is used as an OData proxy for an external OData Service.

The main reason why customers asked for such a scenario was that they wanted to use the SAP Gateway Hub as the single point of entry for the consumption of OData services, so that a SAP Fiori App that is deployed on a SAP Fiori Frontend Server can consume OData Services from just one location.

The same result but with a much cleaner technical approach can be achieved by using the SAP Web Dispatcher as described in the following Wiki page (sectionConfiguring WDP for Fiori s4HANA Applications )

As you can see from the numerous questions and comments to this post you can see that this does not work well. In addition to the technical constraints (see below) also performance should be considered. So Web Dispatcher is your best friend.



Please be aware of the constraings listed in SAP Help.

OData Services Consumption and Integration - SAP NetWeaver Gateway Foundation (SAP_GWFND) - SAP Libr...


In this How-To Guide we want to describe how to consume the Odata sample service from that supports read write access.

Since SAP NetWeaver Gateway does not support V3 of OData we will use the V2 version of this service. The service document of the V2 version is accessible via this link

Though in this scenario the SAP Gateway Server acts like an OData proxy it is not the recommended way to use SAP Gateway to circumvent same origin policy issues that come up with scenarios where SAP Fiori like applications should consume data from OData service that are published via SAP Gateway and the SAP HANA XS engine. Instead the SAP Web Dispatcher or SAP API Management should be used.


  • This scenario has to be implemented on a Gateway Server where also the AddOn IW_BEP is deployed or on a Gateway Server running on SAP NetWeaver 7.40.
    The reason is that the Odata Lib that is part of the hub components is needed for consumption of the 3rd party OData service. This prerequisite is automatically fulfilled by a SAP Netweaver 7.40 SP2 and higher system since the software component SAP_GWFND contains the functionalities of IW_FND, GW_CORE and IW_BEP.

  • This scenario needs to run on SAP NetWeaver Gateway 2.0 SP6 or higher or SAP NetWeaver 7.40 SP2 or higher

  • You have to apply SAP Note 2038379

Let's start with the configuration on SAP NetWeaver Gateway:

Step 1: Create an RFC destination

We first have to create a RFC destination of type G with the following technical settings:

Target Host:

In our example this RFC destination is called ODATAORG.

Please note that you might have to configure a proxy server.

Step 2: Create a System Alias

Now we have to create a System Alias that will be using the above created RFC destination. We call this System Alias OCI_NORTH and configure it such that the flags "Local GW" and "For Local App" are activated.

Step 3: Generate OData Service in SAP NetWeaver Gateway

Only on a SP6 system you have to run transaction /IWBEP/OCI_SRV_GEN.

On systems running on SP7 or later the integration into the SEGW has to be used instead.

Service Namespace = V2/(S(xuh52ptttgitgrkbtjzk1o31))/OData/

Service Name = OData.svc

and acitvate the check box "Configure Gateway Model and Service".

Choose appropriate names for MPC, DPC, Model and Service and a package (here $TMP)

This registers the service in the backend (which is identical with the hub system).

Step 5: Activate Service using /IWFND/MAINT_SERVICE

We register the service in the hub and choose the Technical Service Name ZOSCI_RW_TEST_SRV and register it for the System Alias OCI_NORTH.

Step 6: Test the service

We can now test the service using the Gateway Client /IWFND/GW_CLIENT. You can simply press the push button GATEWAY CLIENT in the Activate and Maintain Service transcation.

We enter the following URI in the Gateway Client


and then press the push button "Use as request".

Now change the URI to


and the HTTP method to


and change the values for

ID from "0" to "1000"

Name from "Bread" to "Toast"

and press Execute.

The HTTP status code 201 indicates that a new entry has been created in the collection "Products" and the created entry is shown in the HTTP response window.

You can now verify it also in a new browser window: