I’ve got a JSON string as a parameter in a function and I’m trying to create an object variable which will be used to store the deserialised JSON.
I would preferably want it to be an
JObject so I can reuse it throughout the Function.
As I have it now it would be impossible to use, due to the
OrderAlloc.GetListOfOrders BO method having only single line expressions as a parameter.
I’d prefer not to have to pass all the parameters into the method and only pass in the JSON serialised string.
If anyone has an idea to get around this that would be great.
Just use the var keyword and then deserialize your JSON string from there
Calling the Function:
Consume the json string (with the use of a local dynamic variable):
Access by key
I meant with regards of adding a new variable to the ‘global’ variable list in the Function Designer.
I may have gotten around this by deserialising the json and reserialising back to a DataSet.
Just in case. Object is not an abstract type. It’s a kind of a weak type.
Anyway, we will not support object as a parameter type in EFx. It is not serialization-friendly and too weak from the type-safety point of view.
I have a plan to add custom types in EFx (the way to define your ‘data contract’ on per-library base), but there is no ETA. You could request such a feature to make it more ‘visible’ for the management.
If not already planned, please do include adding BAQ references and data schema support for input and output parameters. It’d be a huge help for integrations where optimized data schemas/interfaces can significantly simplify the development, support, and integration performance/efficiency. Particularly for e-commerce and xRM integrations where the differences in performance between a consolidated interface vs lots of small interface calls can be the difference between being able to retrieve related master and pricing data real time versus requiring the data and logic to be replicated in the external system(s).
It is one of the potential enhancements. Both for EFx and BPM.
Moreover, it looks like a replacement for BPM Queries.
But again, no ETA.
The main limitation of current BAQ is the output format. It supports only flat table-like data. So you have to de-normalize your data hierarchy.