SAP Cloud Integration: HTTP vs. OData Receiver Adapter

[anoukvandenengel]

Introduction

In SAP Cloud Integration, receiver adapters are crucial for enabling communication with external systems. When integrating with an OData API, developers can choose to use either an OData (V2/V4) receiver adapter or an HTTP receiver adapter. While the OData adapter offers convenience by automating some tasks, it also comes with limitations that may necessitate the use of an HTTP adapter. In this blog, I will share my experiences regarding the advantages and limitations of the OData adapter in comparison to the HTTP adapter.

Advantages of the OData Receiver Adapter

Automated X-CSRF-Token & Cookie Handling

One of the key advantages of the OData adapter is its automatic handling of the X-CSRF-Token and cookies, which is essential for making POST, PUT, and DELETE requests. When making a POST, PUT, or DELETE request using the HTTP receiver adapter without providing a valid token and cookie, you will likely encounter the error...: “HTTP operation failed invoking … with statusCode: 403” with the response body “CSRF token validation failed”. (Important to note is that - although this error seems to indicate a missing or invalid X-CSRF-Token - it may also be caused by missing or invalid cookies).

In order to resolve this error, you must manually retrieve the X-CSRF-Token through a separate call and ensure that both the token and the cookie header are reused for subsequent requests. On the contrary, the OData adapter automatically takes care of both the X-CSRF-Token and the cookies and thereby eliminates the need for these manual steps.

Built-in Tool to Facilitate the Development Process

Another advantage of the OData adapter is the intuitive tool that it provides for entity selection and query options such as filtering and sorting. This tool simplifies the development process and reduces the likelihood of errors.

Additionally, this tool offers a feature to automatically generate an XSD file containing the required payload structure for the request, which is particularly useful for message mapping.

Straightforward XML Structure

Another significant difference between the OData and HTTP adapters related to the way in which the XML message body needs to be structured before sending a request. The HTTP adapter requires the payload to be formatted exactly as the receiver expects, including proper namespaces, xml version and encoding. In contrast, with the OData adapter, the message body needs to be defined in a straightforward structure, as shown below:

<EntitySetName>
  <EntityTypeName>
    <Property1></Property1>
    <Property2></Property2>
    <Property3></Property3>
    <!-- etc. -->
  </EntityTypeName>
</EntitySetName>

The OData adapter then takes care of sending the payload in the required structure.

As an example, if you want to create a supplier invoice using the "API_SUPPLIERINVOICE_PROCESS_SRV" service, you can define the message body in the following way:

<A_SupplierInvoice>
	<A_SupplierInvoiceType>
		<CompanyCode></CompanyCode>
		<DocumentDate></DocumentDate>
		<PostingDate></PostingDate>
        <!-- etc. -->
	</A_SupplierInvoiceType>
</A_SupplierInvoice>

However, the resulting request will be structured as follows:

<?xml version="1.0" encoding="UTF-8"?>
<entry xml:base="https://xxxxxxxxxx/sap/opu/odata/sap/API_SUPPLIERINVOICE_PROCESS_SRV/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">
<content type="application/xml">
<m:properties>
			<d:CompanyCode></d:CompanyCode>
			<d:DocumentDate></d:DocumentDate>
			<d:PostingDate></d:PostingDate>
                <!-- etc. -->
		</m:properties>
	</content>
</entry>

So, the following request from Cloud Integration:

will be received as follows:

In other words, the OData adapter generally involves much less manual work compared to the HTTP adapter. However, there are specific cases in which using the HTTP adapter is necessary, even though the endpoint is an OData service.

Limitations of the OData Receiver Adapter

XML-only Payload

One of the main limitations of the OData adapter is that it only supports XML message bodies. Attempting to use the OData adapter with non-XML payloads results in the following error: “org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not ...”.

In many cases, this can easily be resolved by converting the message to XML format, such as by using a JSON-to-XML converter.

However, in some specific cases, a non-XML message body is inevitable. This is for example the case if you want to post an attachment using the "AttachmentContentSet" entity of the "API_CV_ATTACHMENT_SRV" service, which requires the payload to be a binary string. Attempting to send an XML body will lead to the following error: "com.sap.gateway.core.ip.component.odata.exception.OsciException: Bad Request : 400 : HTTP/1.1". In this case, the HTTP adapter provides the necessary flexibility regarding content-types.

No Support for Navigation Paths

Another limitation of the OData adapter is that it does not support navigation entities in the resource path, which can lead to errors like “...UriNotMatchingException: Could not match segment: …”. For example, retrieving bank data from a business partner using “A_BusinessPartner('{BusinessPartner}')/to_BusinessPartnerBank” of the API_BUSINESS_PARTNER service is not possible with the OData adapter.

Fortunately, as long as you only need to obtain data using a GET request, the HTTP adapter is fairly straightforward to use, because it usually does not require an X-CSRF-Token and cookie. However, if you need to create, update or delete data, a few more steps are needed to manually retrieve and set the X-CSRF-Token and cookie.

Conclusion

The considerations for choosing between the HTTP and OData receiver adapters in SAP Cloud Integration depend on your integration scenario's specific requirements. The OData adapter simplifies integration with automated token handling and entity management, making it ideal for standard SAP services with XML payloads. However, for specific scenarios that require non-XML payloads or navigation paths, the HTTP adapter provides the necessary flexibility.

I hope this blog provides some insights into when and how to use the HTTP and OData adapters effectively. Please feel free to share any additional experiences or tips in the comments.

Summary Table

Feature	HTTP Adapter	OData Adapter
Automated X-CSRF-Token & Cookie Handling	No	Yes
Built-in Tool to Facilitate the Development Process	No	Yes
Automatic .xsd File Generation	No	Yes
Automatically Takes Care of Namespaces	No	Yes
Allows Non-XML Payload	Yes	No
Allows Navigation in Resource Path	Yes	No