The order of payload when using Odata adapter in SAP CPI

[shin861231]

Hello Experts,

I'm encountering an unusual issue with OData queries in SAP Cloud Platform Integration (CPI), and I'm hoping someone can shed some light on this problem.

The Issue

When I perform an OData GET query, the order of the data fields in the result is reversed when using SAP CPI compared to when I use Postman.

Postman Result (Correct Order):

Product, ProductType, LastChangeDate

SAP CPI Result (Reversed Order):

LastChangeDate, ProductType, Product

I've attempted to resolve this by adding the $orderby parameter to my query, but unfortunately, this did not solve the issue. ($orderby=Product,ProductType,LastChangeDate)

My Questions are

1. Why might this reversal of field order occur when using SAP CPI?
2. How can I ensure that the field order in SAP CPI matches what I see in Postman?

As your reference, the attached screenshots show the Integration flow as well as the connection configuration for Odata Adapter, as well as the payload with reversed order.

It would be a huge help if you could please kindly advise on this one!

Thank you.

[Ryan-Crosby]

The order looks correct to me in your screenshot.

[Ryan-Crosby]

If you are referring to the positioning of the XML nodes themselves, then it does not matter because XML is a hierarchical structure.

[RobertQ]

Hi,

from my point of view, the order is relevant and SAP has a bug in its OData adapter implementation.

1.) Generally the order in XML is importent. There are cases there the order can be irrelevant. For this specific case, I would argue that SAP provides an "Generate XML Schema Definition" option and if doing so, you get an XSD that states, that the fields are in a xs:sequence. So the order of the elements is relevant.

By not following their own generated XSD any XML validator step on the payload will fail.

2.) One of the use cases of the odata response could be an Integration Advisor mapping. For that SAP also requires the fields to be in a specific order or the values are not populated in the mapping.

Based on this two point I would argue that this is a bug and SAP should correct their implementation so that the OData adapter follows the XSD or edmx order of fields instead of scrambling the fields. Even the JSON format that you can see in the trace of the message has the "correct" order, but not the generated XML.

The workaround I can suggest, is to use an mapping in beetween to order the fields. Maybe a graphical mapping with a XSD having the fields in a xs:all as source and xs:sequence in the target. (not tested) 

Best regrards

Robert Quindt

[shin861231]

Hello Ryan,

Thank you for your answer.

But the correct order is Product, ProductType, LastChangeDate.

However, what I get in payload is 

<A_ProductType>

<LastChangeDate>2024-01-10T00:00:00.000</LastChangeDate>

<ProductType>SERV</ProductType>

<Product>A001</Product>

</A_ProductType>

As you can see, the order is all reversed.

Or am I interpretating the payload wrongly?

[Aamir_Suhail]

In XML, the order is irrelevant. As long as the element hierarchy is correct (which seems to be the case), the order will not matter.