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 https://blogs.sap.com/2019/01/16/sap-cloud-platform-integration-headers-whitelisting-in-odata-v2-out...
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.
Note:
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
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.
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.
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}.
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).
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 https://blogs.sap.com/2018/01/18/sap-cpi-clearing-the-headers-reset-header/ 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.
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.
Introduction
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.
Note:
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 https://blogs.sap.com/2018/01/18/sap-cpi-clearing-the-headers-reset-header/ 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) { headers.remove(headerName); } } return message; } |
| restore Headers from cache | def Message restoreHeadersFromCache(Message message) { def headersFromCache = message.getProperty("Original_Exchange_Headers"); if (headersFromCache != null){ message.setHeaders(headersFromCache); } return message; } |
| removeHeadersBasedOnPatterns | def void removeHeadersBasedOnPatterns(Message message, def pattern) { def headers = message.getHeaders(); if (headers != null){ Iterator<String> itr = headers.iterator(); while(itr.hasNext()){ String headerName = itr.next().getKey(); if(headerName.matches(pattern)) { itr.remove(); }//if } //while }//if message.setHeaders(headers) ; } |
- SAP Managed Tags:
2 Comments
