Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
yuri_ziryukin
Employee
Employee

Introduction


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.
2 Comments