This Blog blog post is to give the reader a complete overview of how X-CSRF token is handled in CPI when calling an on-premises R3 system ODATA POST call to insert a row into the backend system.

Overview

Here in this example, we are connecting an on-premises system through cloud connector to CPI. CPI uses a HEAD request to first get the X-CSRF token and the http session cookies that is needed for the subsequent http POST call. Special care needs to be taken in the IFLOW configuration when http adapter is used so the same http session cookies are transferred to the POST call in the format that is required by the on-premises system. This wiki goes through how to configure such an IFLOW using HTTP adapter and how to trace the data in CPI.

Note: when using ODATA adapter there is no need for this special handling. ODATA adapter takes care of x-csrf-token call implicitly.

Sample IFLOW showing an ODATA POST call with an on-premises system.

This is a simple IFLOW which shows how to call an ODATA POST call to insert a row into the backend system. For an ODATA POST call to work XCSRF token is necessary. The HTTP HEAD call for the X-CSRF token retrieval and the HTTP POST call should happen in the same HTTP session for the insert to work successfully in the backend system. For that, make sure that the Integration Process, runtime configuration is set to HTTP Session Reuse to “On Exchange”.

The next flow step is the http receiver adapter HEAD request to retrieve the X-CSRF token. Here the mseodata:3000 is the virtual host and virtual port of the cloud connector configuration. Make sure your Request Header and Response Header is * so the custom header fields are sent in and response got back.

The http HEAD call returns the X-CSRF token as well as the HTTP session information from the backend. The X-CSRF token will be valid only if the POST call is sent with the same HTTP session information. The HTTP session information is returned as “set-cookie” in the HTTP HEAD call. This “set-cookie” has to be modified to “cookie” in the next two flow steps.

1. The content modifier Message header tab has “Content-Type” values as application/json as we are sending the payload of the POST call information in json format to the on-premises system.

The Exchange Property tab has an exchange property to change the “set-cookie” to “cookie” as the backend system understands cookie and not set-cookie.

The Message Body tab has the actual payload (data that needs to be inserted) for the POST call.

The next flow step is a groovy script to make sure the “cookie” header fields are delimited with ‘;’. Without the previous content modifier step and this groovy script step the POST call will not be successful.

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;


def Message processData(Message message) {
def properties = message.getProperties();
def cookies = properties.get("cookie");
message.setHeader("cookie", String.join("; ", cookies));
return message;
}

The next flow step is the actual POST call with the HTTP adapter. Here also we are using the virtual server and the virtual port of the Cloud Connector.

Deployed the flow and Successfully post the data.

conclusion 

Follow the above steps so that you can successfully post the data without any CSRF token Issue.