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: 
As announced in the blog post "SAP BTP, Serverless Runtime to be discontinued and replaced by SAP BTP, Kyma Runtime and SAP Integr... (October 2021) by my colleague Karsten, SAP will discontinue the SAP Serverless Runtime in the Cloud Foundry environment. This decision also affects OData Provisioning (ODP).

ODP helps you to expose Gateway services from SAP ABAP backends to the internet. Many customers asked us about an alternative for ODP in the Cloud Foundry environment. In this blog post, I’ll show you how to expose your services going forward using SAP Integration Suite.

My colleague André Fischer has already written a blog called “SAP Gateway deployment options in a nutshell “. It’s about the different deployment options for Gateway. I’ve modified his overview picture to show you how SAP Integration Suite fits into this story. On the left side, you can see the existing approach using ODP. The three options on the right side show the deployment options when you use SAP Integration Suite.

fig 1: deployment options

You might have realized that for all SAP Integration Suite deployment options, you need to expose the backend service on your backend using the Gateway Hub Framework before you can expose it to the internet through SAP Integration Suite.
The good news is that the component (add-on) for this (SAP_GWFND) is already included in your SAP Netweaver system with release 7.40 and higher. If you are on a lower release and you only have installed the component IW_BEP, you need to install the components (add-ons) IW_FND and GW_CORE. See our help page for details.

If you are using SAP OData Provisioning in the Neo environment and you plan to migrate your processes towards Cloud Foundry, be assured that you can run both approaches side-by-side. The exposure of the backend service using the Gateway hub framework will not block the usage of the service implementation through ODP.


To demonstrate the whole process, I have created a simple SEGW project called Z_MY_ODATA_SERVICE. I will first expose the service internally in my backend system and afterwards through SAP Integration Suite to the public internet. You can apply the same approach for your existing Gateway services, no matter if you work with a standalone service on a business system or if a Hub scenario in a plain SAP Netweaver system.

The Service in the Backend

Let’s have a look into the gateway system in which your services are located. In transaction SEGW, you can build your own services or see your existing services. The data model in my SEGW-project Z_MY_ODATA_SERVICE has just one Entity Set called ProductSet containing Products with an ID, a name, and a description. Important for further processing is the service artifact Z_MY_ODATA_SERVICE_SRV

fig 2: SEGW project Z_MY_ODATA_SERVICE with service Z_MY_ODATA_SERVICE_SRV

Expose the Backend Service as OData Service

When using transaction /IWFND/MAINT_SERVICE, you can register the SEGW services, both the SAP-shipped services and your custom created ones, as OData services. The latter ones can be consumed by an OData consumer using the ICF nodes /sap/opu/odata/<service name> (in this example /sap/opu/odata/Z_MY_ODATA_SERVICE_SRV).

To expose a service, click on Add Service.

fig 3: Register Service


Depending on your deployment model, the service is located in this system or in a remote system. In my case, it’s located in the same system. Therefore, I use the system alias LOCAL. Enter the technical service name and hit return. Your service is now displayed in the list of backend services. Select it and click on Add Selected Services.

fig 4: Add Selected Services

Check and confirm the new screen.

fig 5: Service Summary


You should get a success message like the following:

fig 6: Success Message

Once done, your service is displayed in the Service Catalog. By clicking on Call Browser, your browser opens and provides you the internal URL of your OData API.

fig 7: Service added to the Catalog


The  internal URL of your OData service is displayed in the browser window.

fig 8: Gateway Service opened n Browser


When replacing the ?$format=xml with $metadata you get the metadata (EDMX) of your OData service.

fig 9: OData Metadata in Browser


Keep this URL in a notepad, as you will the host name and the URL path later.


Mass Exposure

You might think that exposing hundreds of services is quite some effort. The good news is that there is a mass exposing function for your services.

First, you need a list of all service names you want to expose. As you have all services that you want to consume already registered in your OData Provisioning instance, you can take it from there.

To do this, go to the ODP UI in Neo and use the Export button to get a list as JSON or XML.

fig 10: Export of Service List from ODP Neo


I have selected JSON as export format, therefore, my document looks as follows:

fig 11: List of exported ODP Services


From this document, you can extract the service names into a plain list.

fig 12: Shortlist of ODP Service Names


Now, you can refer to the help portal to get a description on how to expose multiple Gateway services using transaction STC01 and the task list SAP_GATEWAY_ACTIVATE_ODATA_SERV.

By the way: If you have to activate the Gateway Foundation components, transaction STC01 and task list SAP_GATEWAY_BASIC_CONFIG might help you.

With these steps the Gateway service is exposed within your local network.

Exposing the Backend System through Cloud Connector

To use the internal OData service in SAP Integration Suite, you need to expose the internal host of your ABAP system to the BTP using Cloud Connector.

If you have not installed the Cloud Connector yet, you find the installation files and documentation under Once they are installed, you can reach it via https://locahost:8443.

First, you must establish a new connection to your SAP BTP account on which the SAP Integration Suite is running.

To do this, you need to check out information using SAP BTP cockpit. You can open SAP BTP cockpit using the following address: https://cockpit.[your datacenter]  In the SAP BTP cockpit, navigate to the subaccount, where you have provisioned the SAP Integration Suite and open the overview page. Here you will find the region and the Subaccount ID.

fig 13: Details of BTP Account


Keep Subaccount ID and region in a notepad. Using these information and an SAP BTP cockpit user with authorization Cloud Connector Admin in this subaccount, you can go back to the Cloud Connector and click the button Add Subaccount.

fig 14: Button to add Subaccount in Cloud Connector

Provide the region of your SAP BTP account and the subaccount ID that you had copied into a notepad previously. You can choose the display name yourself. Make sure that the e-mail is assigned to a user with the Cloud Connector Admin role. If you want to connect multiple Cloud Connectors to your BTP account, use a location ID to differentiate the different connectors. To finish click Save.

fig 15: Subaccount Details


If the connection was successful, the following popup appears.

fig 16: Confirmation of Successful Connection

After the connection to the SAP BTP account has been established, you see an new table entry . As you don’t have the internal systems exposed yet, the status icon is orange.

fig 17: Cloud Connector Subaccount Dashboard


In the next step, you expose your system with your gateway services. To do so, go to the menu item Cloud To On-Premise of the created subaccount connection.

fig 18: Select Coud To On-Premise


Select the + icon to create a new system mapping between the internal, protected system and a virtual, exposed system. Select SAP Gateway as backend type, enter the internal host and the port of your backend system that you got from the browser in the steps above, and choose a virtual host and a port that will be used in the SAP Integration Suite services later. I have used my.virtual.system as my virtual system and 443 as my virtual port.

fig 19: Table of Virtual Systems in Cloud Connector

A virtual system doesn’t expose any endpoints yet. Therefore, select your virtual system in the table and click below under Resources Of <your virtual system> on the + button to add resources.

For the consumption of the gateway services, you need to allow the URL path /sap/opu/odata. Ensure to also allow all sub-paths in the settings.

fig 20: Virtual System with allowed Resources

Notice that the Status of the virtual system turns to green once you have listed resources.

To verify that your BTP subaccount is connected to your Cloud Connector, go to SAP BTP cockpit and navigate to section Cloud Connector under Connectivity. There you see a connected Cloud Connector instance with your location ID (if you have used one). Make sure that your exposed virtual system appears in the list of Exposed Back-End Systems and that it has some resources available.

fig 21: Cloud Connector View in SAP BTP Cockpit


Exposing the OData Service to the Internet Using API Management

To expose the services to the internet, use API Management . This SAP Integration Suite capability provides you with a powerful tool to govern all your backend APIs like your Gateway services but also any other backend API. On top of the exposed services, you can apply policies to protect your services. Our SAP API Business Hub contains multiple policy templates that will help you in your governance process.

After this, you create an API Proxy as a public wrapper for the internal OData service from your backend system.

Open the SAP Integration Suite landing page and select Design, Develop and Manage APIs to open the API Portal.

fig 22: SAP Integration Suite Landing Page

As a next step, create an API Provider. The API Provider represents a pre-configured system connection, containing all the details like host name, Cloud Connector details, etc. Once you’ve created such a provider, you will be able to consume the services without re-entering the technical details for every exposed service again.

To create the API Provider, navigate to the Configure section and click on Create in the tab API Providers.

fig 23: API Portal - Configure Space

Provide a name for the API Provider, e.g., myGatewaySystem. Add the virtual system details that you have configured in your Cloud Connector. If your gateway client is different than 000, provide the information using the additional properties.

fig 24: Create an API Provider

To get an overview of the existing OData Services of your backend (similar to what ODP is offering), add the Service catalog settings under the corresponding tab.

Path prefix must be hard coded “/sap/opu/odata“; the service collection URL needs to be “/IWFND/CATALOGSERVICE;v=2/ServiceCollection”. Provide a backend user for retrieving the service list.

If your service catalogue does not work, skip this part.

fig 25: API Provider Catalog Service Settings

Once you are done, click Save in the upper right corner. You should see a confirmation message that the API Provider has been added successfully. You can even test the connection to your backend system to see if the setup was done correctly.

fig 26: Successful API Provider Connection Test

Create the API Proxy

Navigate to the Develop section and create a new API by clicking on Create.

fig 27: API Portal - Develop Space

Select the newly created API Provider from the drop down list. If you have added a Service catalog, you can click on Discover to get all services listed.

fig 28: Create an API by Using the Discover Function

You should see a list of your OData services. Search for and select your service that you want to expose and confirm with OK.

fig 29: List of Discovered Services

The fields on the Create API screen are now prefilled by the system. You can change the fields if you want, but you can also leave URL as it is.

If you have skipped the service catalog setup, only select the API Provider and fill in the other fields manually.

  • URL: In one of the previous steps, you were opening the local Gateway endpoint in a browser. Take the URL suffix behind the host and port (without /$metadata).

  • Name/Title: the identifier of the endpoint in API Management;

  • API Base Path: Your consumers will call your exposed gateway service using the API Management host and the API Base Path. Therefore, select a self-explanatory name.

fig 30 - API Details

Once you click on Create, a summary is displayed. You can adjust all settings if required. After saving, you can also add API policies to strengthen, for example, the security of your service. Otherwise, just deploy your saved API.

fig 31: Save and Deploy the API

After a successful deployment, you see the Deployed status and the API Proxy URL.

fig 32: Details of Deployed API

Your clients can now use this URL to call your Gateway service.

I hope that this guide enables you to expose your backend systems so that your apps and other OData consumers can consume the services you previously had exposed using SAP ODP in the Cloud-Foundry environment.

If your use case is not covered yet, please use the comment function of this blog to describe what you want to do and I’ll see whether and how we can implement this by using SAP Integration Suite.
0 Kudos
Thanks for sharing. If the API exposed by this way, is this A public API? I means this API can be found by all customers in API Business Hub? Is this the standard way to public S/4 HANA remote API? By the way, does this approach support RAP V4 Odata service? Thank you.
0 Kudos
Dear Frank,

The API that you have exposed via API Management is public in the sense, that everyone who has the URL and the right credentials can call this API.

It is not listed on the API Business Hub. The API Business Hub on is owned by SAP and SAP governs what is published there. Customers can setup their own API Business Hub Enterprise and configure themselves, what APIs to offer there for consumption.

This blog does not talk about S/4 HANA APIs, but only about Gateway services that were previously exposed using OData Provisioning.

I'm not sure what you mean with RAP V4 OData services.

kind regards,
Dear Axel,

Nice document covering all aspects of oData Provisioning through Gateway.
Active Participant
0 Kudos
Thanks Axel,

I have two questions to clarify.

  1. I think if the existing odp exposed odata services (the odp approach in your fig1) are consumed by btp neo deployed fiori apps and moving towards the "embedded deployment options in your fig1, then APIM steps are not quite necessary in this case. Is that the correct understanding?

  2. Is there an official end of life or end of support date for ODP on Neo? does it impact existing odp subscribers?

0 Kudos
Dear Kevin,

There is no end of life for ODP on Neo!

And yes, if a client like a Fiori app can access the exposed backend OData service through Cloud Connector, then no API Management is required. But APIM allows you to add more control to those exposed OData services like Quota management etc.
Hi Axel,

if I try to establish a connection to the Backend via "Test Connection" I get an 401 unauthorized Error. I double checked the User Credentials, even tested the system url maintained in the cloud connector. (opened the full url in browser, logged in with the same credentials as provided in the API Provider Settings and got the resulting services as result)

I even tried to consume the service via Cloud Connector inside Business Application Studio which worked fine.

So it seems that the 401-issue only appears when im using the API Provider inside the API Management...


A next thing I tried was using Principal Propagation instead of Auth-Type None.. Even that works inside the Business Application Studio, but not when using the API Provider.


Do you have any clue how to fix this, or what I could check again?

Best regards!
0 Kudos
Dear Sascha,

just to confirm: In the Connection tab of your API Provider you have entered

Type: On-premise
Host: your virtual host from Cloud Connector
Port: your port from Cloud Connector
Location ID: if used, the location ID from Cloud Connector
Authentication: None

And then you clicked "test connection" and you got 401. Does your backend allow http HEAD requests? Do you see the ping in the Cloud Connector?

If you ignore the "test connection" and just create an API Proxy, does it work? Have you configured a service catalog lookup so that "Discover" might work?

kind regards,
0 Kudos

Correct, I entered the values as described from you.

I'm able to see the call inside the Cloud Connector and also inside the ICM-Logs of the Backend. But there is auth context or any credentials available.

It seems that they get lost anywhere. But that just happens in case the call is executed from the API Portal. All other Cloud Applications (like Business Application Studio or Workflow Management) are working fine on the same cloud connector. Even with principal progagation.

When I try to discover the Catalogservice in the API Proxycreation I get the same 401 issue. But the Catalogservice is running fine, when I open the url from our internal network via browser and provide the same credentials im able to see all published services.

This drives me crazy here. 🙂




Tried to reach the system directly via internet. (made it available for test) - This works fine.

Just when I switch to On-Premise and the Cloud Connector is in the middle it seems that there is something getting lost regarding Authorization. But inside the cloud connector I did the same thing as you mentioned in your blog above...


Found out that it has something to do as soon as I try to reach the backend via HTTPS. When I use HTTP from Cloud Connector to the Backend it works fine.

0 Kudos

thanks for the updates. If you are inside the same network like your backend, how does the backend behave if you call via postman once with HTTP and then HTTPS?

Is the server certificate trusted by the Cloud Connector? I assume you might have to add the root certificate into the trust store of Cloud Connector

0 Kudos
Did some further research. As the other connections to the cloud connector are working fine its nothing related to the certificate.

I figured out that the Problem was the Profil Parameter "icm/HTTPS/verify_client" which has the value of "1". Therefore the SAP Backend asks for an X.509 Certificate when someone tries to login.

Postman and browsers seem to be clever enough that when no X.509 Certificate is available they fallback to other auth methods. The cloud connector on the other hand seems to issue an empty X.509 Certificate which then causes the issue.

I tried switching the Auth Method from "None" to "Principal Propagation" in the API Provider, but unfortunately there is no User provided when I try to check the connection. Is there any way to get Principal Propagation working in the API Portal Environment?

Thanks a lot for your help already!
Thanks for the update Sascha.

Yes, when the Cloud Connector is asked, he would use his system certificate to logon. Maybe you can use this one to authenticate against the backend. Of course this means that every call through the Cloud Connector would use this certificate (if no other authentication option is used in the call).

Principal Propagation is a bit more complex on CF compared to Neo.
We plan to come up with a blog soon which I would link in that blog here.
0 Kudos
Perfect. Then I will simply wait for this blog, right now we are just evaluating the API Management so its okay for me to wait.

Thanks a lot for your help, keep up the good work!

Best regards,


0 Kudos
This is the document I have been searching for. Thank you for time Axel!
0 Kudos
Hello Axel


Thanks for this awsome article .

However I'm searching for documentation in the case my odata provider is my ABAP instance .


I mean I have created a managed scenario  in ABAP ( in BTP ) tenant and I would like to consume this service in API management .


Any hint ?


Kind Regards

0 Kudos
Dear Lamia,

so you have developed an OData service in the ABAP environment on BTP or did you develop a Gateway service in the ABAP environment on BTP?

Do you have a URL that you can call from the outside world?

0 Kudos

Dear Axel

I'm so grateful for your quick reply .


I have created my odata service in SAP BTP ABAP environement in a tenant . and yes I have an URL that I call from postman and that I called also form cloud integration flow everything is fine .

However now I want to provide this odata as REST API for external use , so I though about API management ..

I have tried to use your same way but for the odata service created in the ABAP environement it does not work at all . 

I got this message

No authorization to access Service '/IWFND/SG_MED_CATALOG_0002 

But I'm pretty sure that it's not the same way to do . 


Kind Regards 


0 Kudos
Dear Lamia,

this looks like the discovery from APIM does not work as your user is not authorized to access the catalog service. Can you please check the authorizations of the user, if this service can be called?

0 Kudos
In fact yes the discovery does not work .

I have provided the communication user in basic authentication ( with this user I can access the odata service in postman ) . Now in SAP Cloud I cannot find any documentation about how to assign authorisation to communication user ? the discovery service is /IWFND/SG_MED_CATALOG_0002 and I have no clue how to make the assignement in the cloud .

Again , Thank you ..

Kind Regrads

0 Kudos
hmm I cannot really comment on how to assign the right authorizations. Maybe you can open a ticket on the BTP ABAP component.

For API Management, you don't necessarily need the discovery. You can also just use the OData API as "URL" for your API Proxy instead of using an API Provider (see fig 28 above).

0 Kudos
Hi axel.albrecht ,

any Update on this topic? 🙂


I'm still struggling to get Principal Propagation working when it comes to the API Management.


Best regards,

Active Contributor
0 Kudos
Hi Axel,

first thanks for this awesome blog. Easily one of the best composed / tought though efforts on SAP community 🤩

That being said: Could you say (to a degree) how SAPs stance on licensing is when using your approach? I know that Fiori is "free" as long as the user is routed through and has a valid user in the backend where the service gets its data.

However, in an (public) API world, that would not be the case most of the times. Will there be licensing based on Gateway Metering and Integration Suite API Management or will there be other metrics, especially regarding the backend system (assume it will be an ERP ECC)

Many thanks and kind regards

0 Kudos
Dear Jens,

thank you for the feedback.

Exposing OData endpoints from an ECC, for which you have used OData Provisioning in the past, is now possible directly on the ECC Gateway, and it's free of charge. Using API Management, with all its delightful advantages, is a metered service.

Hope this clarifies your question.

Best regards,
0 Kudos
Dear Axel, Thank you for this nice blog.

I´m working on a project right now build over SAP BTP Cloud foundry environment.

Basically we are building SAP FIORI Custom Apps and we execute oData Service trough Cloud Connector configured on Premise and destination configuration trough Single Sign On from the trust AD configured from the client (To access S/4 with the SAP User associated to user´s email and the application with their email account).

As per of my understanding in this case APIM is not neccesary to use APIM unless we want to add more control to those exposed OData services like Quota management etc. ?

Thanks for your comments


Hello Axel,

Thanks for the detailed and easy to follow instructions.

I am trying to achieve an Integration Flow which uses an OData API. The connection would work over a Cloud Connector to an on-premise system.

My first question is: do I need an API Provider to achieve this?

Then, I tried to follow the tutorial. The Cloud Connector was already set up so I didn't change anything about it. The page localhost:8443 does not load for me (ERR_CONNECTION_REFUSED), but maybe that is because I can't set up or change Cloud Connectors in my organization.

When I set up the API Provider, I got the response "System is up and reachable. However, the ping check responded with code : 401; Message : Unauthorized".

I continued with the rest of the tutorial. When the API is set up, and I click the API Proxy URL, I get the response "{"fault":{"faultstring":"Unsupported Encoding \"br\"","detail":{"errorcode":"protocol.http.UnsupportedEncoding"}}}". From testing (Try Now > Execute) in the resources tab of the API, it seems like the "media" is a logo from the SAP Application Server. There, it just shows the 401 Unauthorized as well (with the logo).

In an Integration Flow, when I try to simply do a request reply, When I press on Processing > Resource Path > Select and type in the details, I always get an error "Failed to connect to system.".

That error message is not very helpful. I'm not sure where to start looking for the problem.

Kind Regards

0 Kudos
Hello Axel,

Thanks for this detailed blog.

Currently oData Provisioning offers multi-origin feature, which helps with retrieving data from multiple backend systems, aggregating them in one single service and also posting data to backend systems. How would that be handled with SAP Integration suite?





0 Kudos

Great Blog

Used the steps, our Gateway is central hub , got below error

<html><meta http-equiv="refresh" content="0"><body onload="Javascript&colon;document.location.reload(true);"><H1>Your browser is not configured for using SPNego</H1>Press F5 (Page Refresh) to continue.</body></html>



0 Kudos

Hi Axel,

I'd like to clarify exactly how the OData services need to be exposed on the backend ECC system to be used with Integration Suite API Management.

With Neo OData Provisioning it connects to the /sap/iwbep SICF service on the backend ECC system to retrieve the OData Service Catalog and to do regular OData Service CRUD operations. This works fine with systems that are very old (e.g. NW 7.00) which can only install the IW_BEP Gateway backend component.

Can you confirm if the API method from BTP Integration Suite to expose OData Services can also do the same (communicate with /sap/iwbep backend component on the ECC system for OData operations)? I'd like to understand if this is a 100% replacement for ODP, or if it has limitations - such as it only works with systems that can have Gateway Frontend (IW_FND/GW_CORE or SAP_GWFND) installed and OData Services exposed via /IWFND/MAINT_SERVICE and visible under /sap/opu/odata/xxxxxx. The blog and comments so far seem to indicate the latter, but I'd like to check to be sure.