SAP Cloud Integration – Allowed Headers in OData V2 Outbound Connector
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 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 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 the send the required headers to the backend OData V2 system.
Request and Response Headers
The OData V2 outbound connector/adapter properties UI has been enhanced with text fields to capture the request and response as shown below
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 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 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.
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.
With option to allow 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.
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.
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.
Yes, Deepak.. this helped.
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?
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.
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?
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 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.
I have added the header name as mentioned in your blog. But it will not be sent to target system. In message trace we can see that it is missing in the step "Message after receiver adapter"
Any hint why this happens?
Thanks and regards
I think you need to check for the sequence "Message before Receiver Adapter" with help of page navigation (as I see you are at the 2nd of 6th page, top-right corner). Also, can you check the 2nd list entry (from the left-top 2nd entry) as well?
Also, you can check the SAP Note for more info https://launchpad.support.sap.com/#/notes/2852998
thanks for your fast answer!
In the message before Step, the header is filled, but one step later the header is gone....
I recommend you go through the above SAP Note for details on different sections for details.
Also, is the end to end scenario not working? Or you just looking for the entry in tracing?
I am getting an error in ERP- "Problem with SOAP Class". Followed this and came to your vlog - 2699995 - IDocs in ERP System Failed with Error Status: "Problem with SOAP class"
it is saying to set the camelhttpresponsecode header with value 200 in your integration flow before the End Message or End Event to resolve this error.
Tried but not happening.
Kindly help on how to resolve this issue please.
Is the above issue still persists? Or got resolved?
By passing this header value my issue is resolved.
set the camelhttpresponsecode header with value 200 in your integration flow before the End Message or End Event to resolve this error.
Thanks & Regards,