Skip to Content
Technical Articles
Author's profile photo Johan Wigert

Every OData call through API Management transformed into a GET call

I recently struggled with a confusing issue related to SCP API Management, SAP NetWeaver Gateway, and OData. The issue was that irrespective of the HTTP verb used when calling the API through API Management, the OData service interpreted the call as a GET call. In this blog post I’ll provide some details on the issue as well as the solution implemented to remedy the issue.

The issue

I had created an OData service that supported the HTTP verbs GET and PUT. When calling the OData service directly, everything worked as expected. I then set the OData service up as an API in SCP API Management. When calling the API with the HTTP verb GET, everything worked as expected. When calling the API with the HTTP verb PUT however, the call was interpreted by the SAP backend as a GET call.

Analyzing the issue

My first thought was that API Management must be doing something strange to the call. Maybe I had done some trivial mistake in a policy applied to the API? After examining the policies as well as debugging the call in API Management, I had to rule this possibility out. Everything looked perfectly fine in API Management.

The next suspect was the Cloud connector used to communicate between API Management and the SAP Gateway / backend server. I activated tracing in the Cloud connector, but the HTTP verb was correct according to the trace files.

I then decided to debug the request in the back-end SAP system. The first method call I was able to debug was /IWFND/CL_SODATA_HTTP_HANDLER->IF_HTTP_EXTENSION~HANDLE_REQUEST. Here the request_method (local variable LV_HTTP_METHOD) had the value GET.

Something strange happened to the call between the Cloud connector and the SAP backend, but what?

The solution

After having discussed the issue with SAP development, the recommendation we got was to solve the issue by creating a SAML policy and assigning it to the service in transaction SICF.

Creating the SAML policy

We ran transaction SAML2 which opens the URL https://servername/sap/bc/webdynpro/sap/saml2.

When creating the policy, the key setting is IdP-Initiated SSO:

The setting must be Preserve original method. Otherwise, every call gets transformed into a GET call.

Using the SAML policy for the service

The SAML policy must be linked to the service in transaction SICF. This is done like this:


Even though the solution was very simple to implement, the issue cost us a lot of time. I hope that the post is useful to someone else facing the same issue.

This blog post first appeared on the Developer Voyage blog at

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Maximiliano Colman
      Maximiliano Colman

      Hey Johan,

      I reached same point long time ago, but the main issue was that I was forwarding the SAML token from consumer till backend server( so you are forced to enable SAML 2.0 functionalities in backend system ), and the “correct configuration” is:

      1. You read the SAML token in APIM to extract the user identifier
      2. In APIM you generate short-lived SAML token to propagate the user in opproxy
      3. SAP Cloud Connector must trust in the corresponding certificate of short-lived SAML token
      4. You use short-lived certificates between SAP Cloud Connector and Backend system.


      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      Thanks for sharing, Johan! Yet another thing SAP developers have to learn on top of everything. 🙂

      Author's profile photo Manikandan Rajasekaran
      Manikandan Rajasekaran

      Thanks for sharing Johan Wigert , may I know which SAP component did help you in identifying the issue ?