Skip to Content
Product Information
Author's profile photo Deepak G Deshpande

SAP Cloud Integration – OData V2 Headers Propagation and Response Body

UPDATE: From SAP Cloud Integration version 2.49.x, you need to provide allowed headers in the request and response headers and implicit conversion will not be done by the OData V2 outbound adapter. For more information, check out the blog 

UPDATE: From SAP Cloud Integration version 2.46.x, all the response headers from the OData V2 service back end system will be converted to message/exchange headers by OData V2 receiver adapter/connector.


SAP Cloud Integration version 2.43.x comes with some enhancements in OData V2 receiver adapter along with some behavioural changes.

This blog explains about the new enhancements, change in behavior and how to handle the behavioural changes.



This change in behaviour can be observed from OData V2 component version 1.7.

Where to see the component version?

In SAP Cloud Integration, you can get the version of a specific component by pressing “i” (information icon) button. Sample screenshot below




OData V2 Adapter Enhancements

Headers Propagation

There were use cases in which, the headers – declared as message headers in Content Modifier or Script step – to be propagated to OData V2 endpoint as HTTP request headers. Till now, this wasn’t possible because OData V2 adapter was filtering out such headers and used to send only specific HTTP request headers to OData V2 endpoint.

To address such use cases, headers propagation has been enabled. So, if you have a header, e.g. if-none-match, and if you wish this header to be passed as HTTP request header, then you can achieve this from OData V2 1.7 version onwards. You just need to create this header as message header in content modifier or script step, before the OData V2 adapter step, and this message header will be converted to HTTP request header and then it will be propagated to OData V2 backend.

Header camelhttpresponsecode

The response code of OData V2 service is now set to the camelhttpresponsecode header. You can now make use of this response code, available as part of camelhttpresponsecode header, to model your Integration Flow projects behavior after the OData V2 receiver adapter step.

Response Body

The response body is now available as part of the expression ${in.body}. If you are modeling your integration flow project with an exception subprocess to handle the erroreous situation gracefully, you can now make use of the response body available in ${in.body}.


Behavioural Change

The enhancement of Headers Propagation, brings some behavioral changes as well. Meaning, till OData V2 version 1.7, you might have declared some message headers which were being used for some specific purpose in your Integration Flow Projects. When you now plan to enhance your existing with OData V2 adapter (1.7 or greater), those headers will also be converted to HTTP request headers and it may introduce unexpected behavior (e.g., invoking of OData V2 endpoint may fail because the service may not support some custom HTTP request headers).

Adopting to Behavioural Change

To adopt to behavioral change, you need to do some header clean-up activities. If you are aware of how to remove the unwanted headers via content modifier or script steps, then you can go ahead and add these steps and adopt your integration flow.

Below are some examples on how to adopt header removal with content modifier and script step.

Content Modifier: You can refer the blog on how to remove headers via content modifier

Script Step: You can also use groovy step to achieve the same. Script step is recommended because you can re-use the groovy script across different places in Integration Flow project. Below are some sample script functions which may be helpful for you. If you are an expert in script, you can go ahead and make use of your own script functions.


Scenario Sample Groovy Script Function
cache Headers before removal

def void cacheHeadersBeforeRemoval(Message message)


def headers = message.getHeaders();

if (headers != null){

//create a new shallow copy of Map of header and putAll headers into it

def copyOfHeaders =   headers.clone();

message.setProperty(“Original_Exchange_Headers”, copyOfHeaders);




remove given headers from message

// e.g. headers to be removed

def listOfHeadersToBeRemoved= [“Transfer-encoding”, “Content-Length”];


def Message removeHeaders(Message message)


def headers = message.getHeaders();

if (headers != null){

for (headerName in listOfHeadersToBeRemoved) {




return message;


restore Headers from cache

def Message restoreHeadersFromCache(Message message)


def headersFromCache = message.getProperty(“Original_Exchange_Headers”);

if (headersFromCache != null){



return message;



def void removeHeadersBasedOnPatterns(Message message, def pattern)


def headers = message.getHeaders();

if (headers != null){

Iterator<String> itr = headers.iterator();


String headerName =;





} //while


message.setHeaders(headers)    ;





Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo John Bethany Salonga
      John Bethany Salonga

      Hi Thanks for sharing this information.


      Using SF Adapters, can you advise how to add in the request headers information like the message process id of the artifact execution in CPI ? I see it in some standard integration, these request headers are added and serves as good identifier when reviewing Odata API Audit log to cross reference which execution the logs generated are for.




      Author's profile photo Deepak G Deshpande
      Deepak G Deshpande
      Blog Post Author

      Hi John,

      As described in the documentation , the SAP Cloud Integration SuccessFactors outbound/receiver adapter/connector adds the required headers. It is done by the connector itself.

      I request you to visit this documentation section.

      Hope this info helps you.