When I call /${Epicor10Hostname}/Epicor10Live/api/v1/BaqSvc/${BAQName} (or even just bring it up in a web browser for testing) it returns JSON, but the numbers are all formatted strings instead of numbers.
For example, if the PartMtl.QtyPer = 1, I see this:
“PartMtl_QtyPer”:“1.00000000”
This is causing issues in the front end, which is not expecting these unnecessary zeros after the decimal point.
I have tried changing the format string to things like “##0.#####”, “##0”, and “>>>>>9”, and even making it empty, but this has absolutely no effect on the string that is returned.
Is there some way to fix this without having to create a lot of special cases (e.g. a list of fields that have this issue to be processed) in the code that handles the API return?
At the moment it looks like a good workaround is to simply check if every (string) value in the returned data is a number, and if so convert it to one.
What I do if I need to keep the schema correct in all cases is make an Epicor Function, from which I call the BAQ through the BO (not through REST) to get a dataset, and then serialize it to XML through DataSet.WriteXml, including the schema. Then I encode the XML to Base64 and return that from the function as a string. On the client side I read the base64, decode it to XML, and then use DataSet.ReadXml() to restore the original dataset 100% like the original. This keeps everything (column types, table relationships, formulas, etc).
Otherwise you can do a bunch of TryParse() to recompute the type from JSON strings… There are only a few types you really care about: dates, decimal, bools, and strings. So basically if DateTime.TryParse returns false, try decimal.TryParse, then bool.TryParse… If it’s none of the above it’s a string.
It’s just sucky that Epicor decided to use the absolute dumbest dialect of JSON when it fully supports all of the above types…
