I have a follow on question to the already answered question https://answers.sap.com/questions/12696596/not-able-to-create-entries-with-decimal-attributes.html.
It's about formatting edm.decimal in http request bodies when sending requests to CAP services. Deviating from the OData specification, this has to be done as JSON-Strings. Fine. However, I've found tha this is not enough to make things work. Consider this request:
PATCH http://localhost:4004/admin/Products(101)
Content-Type: application/json
{
"price": "12.13"
}
where price is Decimal(9,2). This results in an error response (cds version 3.31.1 on Node.js):
"Error while deserializing payload; consider using parameter IEEE754Compatible=true in content-type with adjusted formatting. An error occurred during deserialization of the entity. A JSON number is not supported as Edm.Decimal value."
Now, extending the Content-Type header to
Content-Type: application/json;IEEE754Compatible=true
makes the request working correctly!
My question is: Is this IEEE header parameter the official recommendation by the CAP team? Is this documented somewhere (cannot find it in cap.cloud.sap at least)? Are there more consequences when setting this IEEE-parameter?
Thanks,
Klaus
Request clarification before answering.
Hi Klaus,
for JavaScript and Node.js it is the recommendation to use always the IEEE753Compatible=true format parameter. This will definitely make applications more robust as EDM.Decimal supports a larger value range then Javascript numbers and if you do JSON.parse() for request payloads then EDM.Decimal values will not be cut off .
Regards Oliver
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Maybe peter.muessig can do something that SAPUI5 does use that also by default? Currently searching for IEEE753Compatible in the SAPUI5 documentation doesn't return any link.
Hi klaus.kopecz and oliver.heinrich,
@Oliver: But even with IEEE754Compatible the search result is empty.
@Klaus: I've faced this issue in January: OData V2 Proxy issue with Decimal data type #24. With the help of oliver.klemenz this was fixed in the OData V2 Proxy.
Best regards
Gregor
Hi oliver.heinrich , klaus.kopecz, mathias.uhlmann ,
I am trying to fire a GET service from the CAP layer to our backend gateway system but the response I am getting is truncating the zeroes after decimal places and converting to whole numbers. ( 12.00 is converted to 12 while 12.13 is correctly coming as 12.13)
I am trying to pass below in the header but it gives me the error "The resource identified by the request is only capable of generating response entities which have content characteristics no acceptable according to the accept headers sent in the request.
"Content-Type" : "application/json;charset=UTF-8;IEEE754Compatible=true"
"Accept" : "application/json;odata.metadata=minimal;IEEE754Compatible=true"
Hi vansyckel,
Can you please help me out on the following issue.
I am trying to fire a GET service from the CAP layer to our backend gateway system but the response I am getting is truncating the zeroes after decimal places and converting to whole numbers. ( 12.00 is converted to 12 while 12.13 is correctly coming as 12.13)
I am trying to pass below in the header but it gives me the error "The resource identified by the request is only capable of generating response entities which have content characteristics no acceptable according to the accept headers sent in the request.
"Content-Type" : "application/json;charset=UTF-8;IEEE754Compatible=true"
"Accept" : "application/json;odata.metadata=minimal;IEEE754Compatible=true"
| User | Count |
|---|---|
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.