Skip to Content
Product Information

SAP Cloud Platform Integration – Headers whitelisting in OData V2 Outbound Connector

Introduction

As described in the blog https://blogs.sap.com/2018/08/14/sap-cloud-platform-integration-odata-v2-headers-propagation-and-response-body/, in SAP Cloud Platform Integration version 2.43.x and above, all the message headers implicitly getting converted to HTTP request headers and sent to OData V2 endpoint with OData V2 outbound adapter/connector.  This required some extra steps to clean up headers via script before invoking OData V2 endpoint. This ended up in multiple scripts steps in integration flow and, it was difficult identify the message headers which were creating issues in invoking OData V2 endpoint.

SAP Cloud Platform Integration version 2.49.x reduces this complexity. OData V2 outbound adapter now comes with a UI enhancement where-in, you can add the headers which you want to send as HTTP header(s) to OData V2 endpoint. This blog explains how to whitelist the request headers.

 

Request and Response Headers

The OData V2 outbound connector/adapter properties UI has been enhanced with text fields to capture/whitelist the request and response as shown below

 

 

Request Headers

Consider an example Integration Flow project with HTTP inbound connector, a content modifier and an OData V2 outbound connector.

 

 

Now consider that you wish to send an if-match header and a myHeader to OData V2 endpoint.

The if-match header is being passed from the caller system (e.g. POSTMAN client) who invokes the HTTP endpoint, provisioned after the deployment of Integration Flow. For this, you need to make an entry of if-match in Allowed Headers field of Integration flow properties.  Another header called as myHeader, created in content modifier. To propagate these two headers to OData V2 endpoint, you need to add/whitelist these two Request headers (under HEADER DETAILS section) field as shown below.

 

 

Usage of apikey

If you are configuring OData v2 endpoints in SAP Cloud Platform Integration OData V2 outbound/receiver adapter, which are authenticated by apikey, then you can create a header named apikey in either content modifier or script step (like myHeader in the above section) and provide the required value to apikey.

Then, you need to provide this header in Request Headers of HEADER DETAILS section as well as Request Headers of METADATA DETAILS section as shown below.

 

 

Since apikey will be used as authentication header, you need to set the Authorization property drop down control of OData V2 outbound/receiver connector properties to None.

 

OData V2 outbound connector will now convert these two headers as HTTP header and sets the values of each headers as available and sends it to the OData V2 endpoint.

After deployment of this integration flow, you get access to the endpoint from the monitoring view under Integration Content

When you invoke this endpoint from a client, for example, POSTMAN client, with proper if-match header value, the Supplier response will be sent, as shown in the screenshots below.

 

 

 

 

Response Header(s)

If you expect some of the response headers, which will be sent by the OData V2 services, to be converted as message headers, then you should make such header entries in Response field.

 

Summary

With option to whitelist the request and response headers, you now have more control of the headers to be sent to OData V2 backend and the response headers to be allowed in the integration pipeline.

8 Comments
You must be Logged on to comment or reply to a post.
  • Hi Deepak,

     

    Thanks for the article.
    Do we have the chance to also whitelist incoming headers in the ODATA inbound connector? (Same would be nice for other HTTP-based inbound connectors like IDOC too)

    A scenario this requirement comes from is testing of integration flows.

     

    Regards,

    Uwe

    • Hi Uwe,

      For inbound connectivity, there is an option at the integration flow project level called “Allowed Header(s)”, where you can whitelist the incoming headers to integration pipeline. You can find this option under “Runtime Configurations” property of the integration flow.

       

      I hope this helps.

       

      Thanks

      Deepak

  • Hello Deepak,

    I have to pass two header fields to the OData service in the GET request.

    In SAP, I would fill these in the SAP Gateway Client in the following way (this is only an example!)

     

    How can I pass these two parameters using the CPI?

    /
    • Hi Kevin,

      As mentioned in the blog, for your example, you need to create HEADER1 and HEADER2 in either content modifier or script, assign required values for HEADER1 and HEADER2, and then, provide these header names HEADER1 and HEADER2 in the Request Headers under HEADER DETAILS section of OData V2 outbound adapter.

      Hope this information helps you, let me know in case if you have further queries.

       

      Thanks

      Deepak

  • Hello Deepak,

    we have a CPI scenario including a message mapping step followed by an Request/Reply step with OData receiver adapter configured for batch processing in combination with POST method.
    Thereby 1..n IDocs are mapped to OData batch target structure and here we would like to create one http header field including corresponding IDoc number per batchChangeSetPart:

    During the tests with activated CPI trace we recognized that the OData receiver step “Message Before Receiver Adapter” consists our desired IDoc numbers in the form of http header fields but the subsequent step “Message After Receiver Adapter” doesn’t contain the http header fields (also the target system doesn’t received it):

    Also with configured Request Header field “integrationMessageId” or “*” wildcard setting in OData receiver adapter the HTTP field is removed.

    Is this a restriction for OData batch calls or did we forget an important setting to make it work?

    Best Regards,

    Tobias

    • Hi Tobias,

      In tracing for OData V2 outbound/receiver adapter, “Message After Receiver Adapter” gives the details of response from the service. So, what you see in “Message After Receiver Adapter” is the response of your $batch operation (as I see in the your screenshot, HTTP/1.1 201 Created).

      Are you looking for these header information in the response as well?

      Also configured Request Header field makes the provided headers to be part of the HTTP request headers to the backend service. But in case of $batch, these will be part of the payload of $batch under the header XML tags.

       

      Hope this helps

      Thanks

      -Deepak

  • Hello Deepak,

    thanks a lot for your explanation. First I thought the “message after receiver step” illustrates the OData batch request at the last stage before CPI sends it to the receiver system but you of course you are right – this step consists the OData batch response. However, I only need the header information in the request and not in the response.

    Regarding your $batch statement:  As the step “Message before Receiver Adapter” shows that the http header field “integrationMessageId” is already provided with an IDoc no. value I assume now, that the receiver system doesn’t process it properly. Therefore in CPI logic anything works fine.

    Best Regards,

    Tobias