Skip to Content
Technical Articles
Author's profile photo Yuri Ziryukin

Best Practice for Using CSRF Protected Flag in CPI OData Adapter (Outbound)


SAP Cloud Platform Integration has an OData receiver adapter (V2) that can be used to call OData services in the backend systems. It can be used both for reading (GET) and for changing (POST / PATCH / MERGE / DELETE) operations.

In the “Connection” properties of the OData adapter you will find the flag “CSRF Protected”. CSRF stands for Cross-site Request Forgery – a specific type of attack that exploits the trust that a site has in a user’s browser.

CSRF protection in the OData adapter works in a way, that technically two HTTP calls will be made to the OData endpoint. During the first call the OData adapter will only fetch the CSRF token and the second (real) HTTP call will be made with the token that was provided by the server in the previous response.

As technically two HTTP calls are made, the performance of the OData adapter call may suffer due to the overhead for the initial, technical HTTP call (including all network components that are typically taking part in the network communication).

Often switching CSRF protection off is also not an option, as many SAP OData services require CSRF protection for the normal functioning. If this option is disabled, the service returns HTTP error 403 – CSRF token validation failed.

Typical use case and procedure

In many customer scenarios integration flows are built in a way, that several OData calls are taking place. For example, first a call with GET operation checks an existence of an object in the backend system and depending on the result a subsequent POST or PATCH operation is called to perform a creation or change of the object.

In such kind of scenario you would like to minimize the number of technical HTTP calls that are made to the backend to achieve optimal performance. In order to eliminate unnecessary calls the following settings have to be enabled in your integration flow.

Step 1: Activate HTTP session reuse

OData adapter is capable of reusing CSRF token between the calls. E.g. that the token generated for the preceding GET call will be immediately reused for the subsequent POST call. In order for this functionality to work, the HTTP session reuse has to be activated. This setting is located in the Runtime options of the integration flow:

Set the value of this field to “On Exchange” to enable HTTP session reuse during processing of a single message.

Step 2: Disable “CSRF Protected” flag for the first OData call with GET operation

In the “Connection” properties of the adapter make sure that the flag is disabled.

Step 3: Enable”CSRF Protected” flag for the subsequent OData calls with changing operations

In the “Connection” properties of the adapter make sure that the flag is enabled.

With such kind of setup you should not have any additional HTTP calls to the backend while using the OData receiver adapter.

Assigned Tags

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

      Hi Yuri,

      Thank You for the blog.

      I am using 1 GET call to check for the customerID in C4C and then 2 POST calls( to call 2 different APIs).

      my first POST call is working but the second one fails with error 


      Could you pleasorg.apache.camel.CamelExchangeException: Sequential processing failed for number 0. Exchange[ID-vsa7385530-45173-1590525568149-345-5]. Caused by: [org.apache.camel.CamelExchangeException - Sequential processing failed for number 1. Exchange[ID-vsa7385530-45173-1590525568149-345-10]. Caused by: [ - Internal Server Error : 500 : HTTP/1.1 ]], cause: Internal Server Error : 500 : HTTP/1.1e


      Can you please suggest what can be the issue here?

      Please note: CSRF protected is enabled in all the 3 calls.

      Author's profile photo Yuri Ziryukin
      Yuri Ziryukin
      Blog Post Author

      Hello Akshay,

      sorry for the late reply. Somehow I forgot to check my notifications.

      Error 500 indicates a problem on C4C side. You have to go to your C4C tenant and look for the root cause there. If there is a CSRF token issue, I think you would rather get HTTP 403 error instead of 500.