Skip to Content
Technical Articles
Author's profile photo Axel Albrecht

From OData Provisioning (Cloud Foundry) to SAP Integration Suite

As announced in the blog post “SAP BTP, Serverless Runtime to be discontinued and replaced by SAP BTP, Kyma Runtime and SAP Integration Suite” (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.

deployment%20options

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

Service%20Z_MY_ODATA_SERVICE

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%203%3A%20Register%20Service

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%204%3A%20Add%20Selected%20Services

fig 4: Add Selected Services

Check and confirm the new screen.

fig%205%3A%20Service%20Summary

fig 5: Service Summary

 

You should get a success message like the following:

fig%206%3A%20Success%20Message

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%207%3A%20Service%20added%20to%20the%20Catalog

fig 7: Service added to the Catalog

 

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

fig%208%3A%20Gateway%20Service%20opened%20n%20Browser

fig 8: Gateway Service opened n Browser

 

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

fig%209%3A%20OData%20Metadata%20in%20Browser

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%2010%3A%20Export%20of%20Service%20List%20from%20ODP%20Neo

fig 10: Export of Service List from ODP Neo

 

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

fig%2011%3A%20List%20of%20exported%20ODP%20Services

fig 11: List of exported ODP Services

 

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

fig%2012%3A%20Shortlist%20of%20ODP%20Service%20Names

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 https://tools.hana.ondemand.com/#cloud. 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].hana.ondemand.com/.  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%2013%3A%20Details%20of%20BTP%20Account

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%2014%3A%20add%20Subaccount%20in%20Cloud%20Connector

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%2015%3A%20Subaccount%20Details

fig 15: Subaccount Details

 

If the connection was successful, the following popup appears.

fig%2016%3A%20Confirmation%20of%20Successful%20Connection

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%2017%3A%20Cloud%20Connector%20Subaccount%20Dashboard

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%2018%3A%20Select%20Coud%20To%20On-Premise

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%2019%3A%20Table%20of%20Virtual%20Systems%20in%20Cloud%20Connector

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%2020%3A%20Virtual%20System%20with%20allowed%20Resources

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%2021%3A%20Cloud%20Connector%20View%20in%20SAP%20BTP%20Cockpit

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%2022%3A%20SAP%20Integration%20Suite%20Landing%20Page

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%2023%3A%20API%20Portal%20-%20Configure%20Space

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%2024%3A%20Create%20an%20API%20Provider

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%2025%3A%20API%20Provider%20Catalog%20Service%20Settings

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%2026%3A%20API%20Provider%20Connection%20Test

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%2027%3A%20API%20Portal%20Develop%20Space

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%2028%3A%20Create%20an%20API%20by%20Using%20the%20Discover%20Function

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%2029%3A%20List%20of%20Discovered%20Services

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%2030%20-%20API%20Details

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%2031%3A%20Save%20and%20Deploy%20the%20API

fig 31: Save and Deploy the API

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

fig%2032%3A%20Details%20of%20Deployed%20API

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.

Assigned Tags

      19 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Frank Li
      Frank Li

      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.

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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 api.sap.com 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,
      Axel

      Author's profile photo Balamurugan Gunasekaran
      Balamurugan Gunasekaran

      Dear Axel,

      Nice document covering all aspects of oData Provisioning through Gateway.

      Author's profile photo Kevin Hu
      Kevin Hu

      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?
      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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.

      Author's profile photo Sascha Weidlich
      Sascha Weidlich

      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!

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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,
      Axel

      Author's profile photo Sascha Weidlich
      Sascha Weidlich

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

      Sascha

       

      EDIT:

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

      EDIT2:

      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.

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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

      Author's profile photo Sascha Weidlich
      Sascha Weidlich

      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!

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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.

      Author's profile photo Sascha Weidlich
      Sascha Weidlich

      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,

      Sascha

       

      Author's profile photo David Nguyen
      David Nguyen

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

      Author's profile photo Lamia FARHAT
      Lamia FARHAT

      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

      Lamia

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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?

      thx,
      Axel

      Author's profile photo Lamia FARHAT
      Lamia FARHAT

      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 

      Lamia 

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

      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?

      regards,
      Axel

      Author's profile photo Lamia FARHAT
      Lamia FARHAT

      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

      Lamia

      Author's profile photo Axel Albrecht
      Axel Albrecht
      Blog Post Author

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

      regards,
      Axel