Deserialising JSON with variable property names using JKI JSON

[DavidFCannock]

I'm wondering if anyone knows of a way to deserialise JSON documents that contain "variable" properties i.e. properties with keys that are not known in advance. In other languages (C#, Python, etc.) this is straightforward; you just deserialise the document to a dictionary and iterate over each key/value pair. I'm not sure how can be done using JKI JSON though.

Note: I'm also tracking this issue here.

For example, consider this JSON document:

{
    "abs_bar": {
        "messageId": 500,
        "canPort": 1,
        "repeatRate": 50
    },
    "foo": {
        "messageId": 10,
        "canPort": 0,
        "repeatRate": 50
    }
}

I've attempted to deserialise it using this logic, trying to use an array of clusters of string/cluster pairs as a "pseudo-dictionary":

What I expect to get:

What I actually get:

[DavidFCannock · Accepted solution]

@JKSH from the GitHub issue provided a really neat solution. I've implemented it below:

From the front panel, I confirm it works even if the fields are in an arbitrary order like in the VI snippet posted above:

 

Edit: this isn't quite right yet. Fields are mixed up - I need to use the JSON deserialisation library again on the second step (within the for loop) to fix this I think.

Edit 2: fixed this by chucking `Adapt To Type.vi` in the for loop.

[drjdpowell]

This problem shows one of the difficulties of working with current LabVIEW JSON tools, that are easy to use with fully defined data clusters but more of a struggle otherwise.  I’ve made a new library, JSONtext, that I hope to make working with JSON easier.   Here is your solution in JSONtext:

[drjdpowell]

The reverse problem is also easy (should that be needed):

[DavidFCannock]

---

@drjdpowell wrote:

This problem shows one of the difficulties of working with current LabVIEW JSON tools, that are easy to use with fully defined data clusters but more of a struggle otherwise.  I’ve made a new library, JSONtext, that I hope to make working with JSON easier.   Here is your solution in JSONtext:

---

I've tried that library out and it's pretty nice! I've thrown together a prototype VI to hammer my webservice with HTTP GET's and bundle message definitions + their fields + the values of those fields:

[drjdpowell]

At some point (far future) I hope to implement the "filter" notation of JSONpath, which would simplify your testing for the existence of "repeatRate" through a Path something like:

$.data[0].[?(repeatRate)]

[DavidFCannock]

One of the nice features of your library is that it makes good use of the new malleable VIs that got released. Unfortunately, I've run into trouble using them in the past since VI package manager had a bug that prevented it from building projects that made use of them. However, I saw at the bottom of that thread that JKI have apparently fixed that issue. Awesome, I can use malleable VIs now!

In the screenshot I posted earlier you see I use one instance of a malleable VI from your library (something like "Find Item (by LV Type)"). It is the only malleable VI I use in my project. Just now I tried building a new VI package release of my project and got an Error 10 during the build. I was thinking back to that bug I encountered before with VIMs...but that can't be it, right? Surely they can't be so incompetent as to release a major version claiming to support malleable VIs when it doesn't, and then release a service pack claiming to fix the bug and still not have it fixed?

I swapped out the malleable VI for the non-malleable equivalent that just returns the result as text, and parsed the text to a number using "Fract/Exp String To Number.vi". Tried the VI package build again and it worked. Amazing.

I would love to point out that the issue still isn't resolved on JKIs forums but in their great wisdom they don't support registering over an encrypted channel...


Edit: It's interesting that your library does contain malleable VIs and you are able to distribute it as a VIPM package. My guess is that VIPM can build packages that contain malleable VIs, but not ones that contain regular VIs calling into malleable VIs.

[drjdpowell]

Are you sure you are using the bug-fixed version of VIPM?   It’s something like 2017.0.0.f1.   I know the bug is fixed as JKI asked me to beta test it with JSONtext (JSONtext includes example VIs that call VIMs, that wouldn’t build with the original VIPM version, but do with f1).

[DavidFCannock]

---

@drjdpowell wrote:

Are you sure you are using the bug-fixed version of VIPM?   It’s something like 2017.0.0.f1.   I know the bug is fixed as JKI asked me to beta test it with JSONtext (JSONtext includes example VIs that call VIMs, that wouldn’t build with the original VIPM version, but do with f1).

---

I am yes. "Check for updates" confirms I'm on the latest version.



Edit: The error I get now (Error 10) is different than the error I got when trying a similar thing with the previous version of VIPM. Same result though - can't call malleable VIs anywhere in my code.

[drjdpowell]

Not sure what the problem is then.   Does removing the VIMs make the problem go away? And if so, do the standard LabVIEW VIMs also cause the error?