OData v4 Adapter not implementing the bind operation


In this post I’d like to inform our fellow developers about one important, missing feature in the current OData v4 receiver adapter implementation.

I’m writing this post, because this gap is not declared in other documents.

Also, I’d like to present a workaround, to handle this usecase with the HTTP adapter.

Furthermore, I’d be very happy, if you vote for this feature on Influence SAP:

If this influence request will get enough votes, it will be implemented in the odata v4 receiver adapter. And no ugly workaround will be necessary :).


as we had to painfully discover, the OData v4 Adapter is unfortunately not implemented according to the OData v4 specification.

One of most important features from OData is not implemented. Making Bindings between entities.


A Product belongs to a Category. To manage that in a OData V4 Service we use navigation properties.

If you want to create a Product and bind it to a Category you make a request as follows:

POST http://host/service/Products HTTP/1.1 { "Name": "myProduct", "Category@odata.bind": "Categories(6)"

Example from: OASIS OData v4.0 specification (8.5 Bind Operation)

In this case “Category” is also a navigation property in the Product entity. So you can update this property with a “@odata.bind” declaration and the according Entity reference.


To implement such a request in the CPI one would use the OData Adapter.
However, the procedure is different because the XML protocol is used instead of JSON. But in XML you cannot create such a request. Something like this is not possible:

POST http://host/service/Products HTTP/1.1 <Products> <Product> <Name>myProduct</Name> <Category>6</Category> </Product>

Even if this blog Payload structure in OData V4 adapter – SAP Cloud Integration states, there is a solution like:

POST http://host/service/Products HTTP/1.1 <Products> <Product> <Name>myProduct</Name> <Category> <Id>6</Id> </Category> </Product>

This unfortunately, is also not working.

More Transparency!!!:

The OASIS OData v4.0 specification: OASIS OData Version 4.0. Part 1: Protocol Plus Errata 03 is written and defined by two parties, by SAP SE and Microsoft. Back in the days 2016.

If SAP has defined this protocol and is advertising it for future use as a holy grail, why is it still not implemented correctly in the integration tools (CPI) they build?

We also wouldn’t know, if this is supported or not, if we didn’t make contact with the support team. AND there might be a lot more gaps!

To make proper decisions, the features of the “current” OData v4 receiver adapter have to be listed separately. But there is no documentation of this adapter and its functionality.

There is also no “warning” or sign of “beta” state. Which is totally misleading.

And with the provided functionality we have experienced many bugs and misbehavior.


If you’d like to make a binding operation or update a navigation property. You have to make two separate calls.

1. OData v4 Request

Update your odata entity like you used to do with the OData Adapter. Bu be aware you can only do a simple update/create. Not a deep insert. Like this one:

POST http://host/service/Products HTTP/1.1 <Products> <Product> <Name>myProduct</Name> </Product>

This approach will do the type conversions for you. For example (String -> number, boolean etc.). This is helpful, because the CPI is handling all fields as a string, but the OData API will reject fields which are not in the right format, like defined in the service metadata.

2. HTTP Request

Not you can do the binding operation separately with the HTTP adapter.

Be aware that you will have to do a PATCH operation. Otherwise the other fields, which you have posted in the previous call, will be deleted.

PATCH http://host/service/Products HTTP/1.1 { "Category@odata.bind": "Categories(6)"


To clarify: use the OData v4 receiver adapter with CAUTION!

It is not implemented like documented!

To make this happen, please vote for this influence call

If you have further question, I’d be glad to talk about this topic.


Dennis Sentler