Business Central does not currently support JSON parameters or return types for codeunit web services.
For webservice calls, I have to receive JSON serialized text and then parse the JSON object as one text element of the JSON body.
For outputs, I have to assemble my JSON object and then use JsonObject.WriteTo(Text) to create a serialized a text return value. I then have to parse that text back to JSON in the system calling the web service.
It is very difficult to sell Business Central's interface capabilities when ECMA-404 The JSON Data Interchange Standard was introduced in 1999, has been widely adopted in the 2000's, and **still** isn't inherently supported by Business Central in 2021.
Please don't hesitate to contact me for more details to make this feature standard in future releases.
Sincerely,
Kieran Sweeney
Comments
one way to implement this to use xmlport to part to handle json file for export and import.
Category: Development
We have also often this suggest,All Parters who want to send Data to Business Central are receive then, cant work directly with Json, the must Split the Values and conert them to Json.In the Inbound Direction it is also an Problem. We must Split the Invalue from the Json, as an String Part and convert it to an Json.
Category: Development
I agree to Kieran suggestion
Category: Development
This is a must. Plain and simple.
Category: Development
Please take this issue into consideration.Agree what Bjarki Hall is saying in latest comment.Very hard to move from legacy SOAP web services if complex data type are not easily manageable via OData unbound actions.
Category: Development
PLEASE make this available.
API Pages are unintuitive, especially when you get to the point of subpages and defining EDM Types for nested objects and its limitations. (There was somewhere a limit of 2 nested objects).
So, i was blown away we could just publish a codeunit, define a text parameter and handle the text, like parse in json, xml and so on.
Well, not so much.
The parameter is ONE single object in the document, and so the value is ONE string:
So function like this: procedure TestProc(inputJson: Text): Integer
Does NOT work like this:
{
“inputJson”: {
“str”: “Hello world!”,
“confirm”: true
}
}
Does work as a single string after the first Json Token:
{
“inputJson”: “{\”str\”:\”Hello world!\”,\”confirm\”:true}”
}
Show stopper 🙁
Category: Development
I would love this to be supported (especially since BC doesn't integrate well with other APIs), just thinking what should happen with signature conflicts?
If the raw http body is like this:
{
"a": "",
"b": ""
}
and the content-header is "application/json",
then it already fits this function signature:
procedure Foo(a: Text; b: Text);
So should this just take priority over:
procedure Foo(j: JsonObject); // j = { "a": "", "b": "" }
procedure Foo(j: JsonToken); // even better - allows j.AsObject, j.AsArray or even raw j.AsValue
Do we want this to be explicitly opt-in via a custom http header (ALRequestType: "JsonToken") or do we want this to work implicitly out of the box (if possible)?
Also, I would like to point out that supporting $value (getting the raw JSON as response body) or a compatible header should be possible to via unbound actions.
These features combined would enable less boilerplate in AL and also a way to communicate with subscription-based API services without the need of special proxies and the overhead of parsing/serializing the JSON data.
PS. I might be going too much off topic, but we've also been trying to migrate from SOAP and by-ref arguments aren't supported in OData4, could they however be added to the response data via custom flag too?
I'm asking because overloading the procedure isn't possible, like: "procedure Bar(var a: Text): Text;" to "procedure Bar(a: Text): Text;".
Please take these points into consideration, though!
Category: Development
Business Central Team (administrator)
Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team