Log In
Register
Topic RSS
16:38, EET
November 26, 2019
Offline
Hello,
could someone please provide examples how to encode OPC UA Built-In types to JSON for further processing? Assuming that it should be possible, as it specified in OPC 10000-6, OPC Unified Architectur, Part 6: Mappings.
Thank you in advance
10:43, EET
April 3, 2012
Offline
Hi,
We do not support that yet. It is a relatively new thing, as it was only added in 1.04.
We will eventually release a “JsonEncoder” as it is needed for PubSub support that we are currently working on.
15:13, EEST
November 16, 2015
Offline
Hello,
I’d like to come back to this very old topic because I think a lot has happened since then. I’m using version 5.2 of the Prosys OPC UA SDK, which now includes the announced JsonEncoder/JsonDecoder. I now have a similar task: the value from a node should be read and converted to JSON. In my case, the value is of the data type Structure or Structure[]. The best solution would be as generic as possible, one that can convert virtually any value from a node to JSON. I think this is a question you’re familiar with. Unfortunately, I haven’t found any documentation on JsonEncoder other than javadoc, but it’s not very comprehensive. Am I even on the right track with JsonEncoder? Do you have any other documentation/examples that I just haven’t found?
Thank you for any advice
Michael
13:15, EEST
April 3, 2012
Offline
Hi,
Can you explain your use-case in full? The state of JSON is currently a bit of a mess.
There isn’t a “single JSON format” in OPC UA. That was the case already in 1.04. However, currently there are 2 new modes being added in the specification (plus extra PubSub rules on top of those) and the old format is being deprecated. We do not yet have a release nor a beta with the new format. It will probably take some time before we support them, as the spec isn’t finalized either, currently (as of 1.05.04) the https://reference.opcfoundatio…..5/docs/5.4 does say:
“Editors Note: The JSON encoding was changed very late in the specification release cycle with limited implementation to validate the design. Subsequent implementations and interoperability testing may result in changes to the JSON encoding in future versions of this specification.”
Regarding the com.prosysopc.ua.stack.encoding.json.JsonEncoder, generally speaking classes that are in com.prosysopc.ua.stack.* packages can be thought to be internal implementation and shouldn’t be used unless they are part of the API of other com.prosysopc.ua.* package classes. That being said sometimes (like in this case) a thing can only be done via them, but generally speaking they aren’t that well documented and can change more freely.
Probably the JsonEncoder design should also be better as well in the future, but currently the following should help:
ByteArrayOutputStream data = new ByteArrayOutputStream();
JsonEncoder enc = new JsonEncoder(ctx, new OutputStreamWriter(data, StandardCharsets.UTF_8));
enc.put("TestField", new Variant(Integer.valueOf(42)), UaIds.BaseDataType, 0);
enc.close();
String dataStr = new String(data.toByteArray(), StandardCharsets.UTF_8);
System.out.println(dataStr);
You should see {“TestField”:{“Type”:6,”Body”:42}} in the output.
You can also use some of the other public API of JsonEncoder. However, in a generic case you should have a DataValue and then the Variant within it. Skipping a bit details here, but using that Variant, then UaIds.BaseDataType to get the UaNodeId related to BaseDataType and finally 0 as the dimensions (i.e. scalar, note that the scalar Variant can contain arrays) it should work for any Variant (except e.g. we are aware that an array of Structures within a Variant doesn’t work properly currently).
18:29, EEST
November 16, 2015
Offline
Hello Bjarne,
Thank you for your quick reply. Our use case, in short: Read the value of a node (or react to a value change via a subscription) and convert it to JSON. Ideally, the conversion should be performed according to a clear specification. The node’s data type can be a built-in standard type, a structure, or an array of these types.
In the implementation, I ended up with code similar to that in your snippet. However, there were problems with arrays of structures, and the method I used, JsonEncoder.putStructure(String, Structure), is deprecated. So I wasn’t sure if I was on the right track. If I understand you correctly, there is a well-known problem with arrays of structures. However, I can replace the deprecated method, as shown in your snippet. Alternatively, I could try to implement a conversion myself based on the StructureSpecification.
14:49, EEST
April 3, 2012
Offline
I meant more like what you do with the JSON once you would have it (if possible to explain). For example, do you need to be able to parse it back, do you use only it for your app or do you need to send it etc.? Also if sending does the receiver need to “know OPC UA” and do they have access to the address space via OPC UA client-server?
16:03, EET
November 16, 2015
Offline
Hello,
we’ve updated to version 5.5 of the SDK, and I have another quick question about the JsonEncoder. We’re still using the class to convert structures to JSON strings. I’ve noticed that empty strings are now being converted to null values. This wasn’t the case in version 5.2, if I remember correctly. It’s not a problem, I’m just curious why the behavior has changed. I haven’t found any mention of this in the specification, but I could be wrong. So, my question is, was this behavior changed intentionally?
Snippet of how we’re using it:
val encoder = com.prosysopc.ua.stack.encoding.json.JsonEncoder(uaClient.encoderContext, JsonEncodingMode.VERBOSE, writer)
encoder.put(“structure”, structure, UaIds.BaseDataType, 0)
writer.toString()
Thank you in advance
10:51, EET
April 3, 2012
Offline
I do not remember all the details, but I believe it was intentional.
A possible interaction of https://reference.opcfoundatio…..ocs/5.1.11:
” The terms null, empty and zero-length are used to describe array values (Strings are arrays of characters and ByteStrings are arrays of Bytes for purposes of this discussion). A null array has no value. A zero-length or empty array is an array with 0 elements. Some DataEncodings will allow the distinction to be preserved on the wire, however, not all DevelopmentPlatforms will be able to preserve the distinction. For this reason, null, empty and zero length arrays are semantically the same for all DataEncodings. Decoders shall be able to handle all variations supported by the DataEncoding, however, decoders are not required to preserve the distinction. When testing for equality, applications shall treat null and empty arrays as equal. When a DevelopmentPlatform supports the distinction, writing and reading back an array value may result in null array becoming an empty array or vice versa. “
combined with https://reference.opcfoundatio…..docs/5.4.6 NULL-> JSON null
could be interpreted as empty being the same as null => JSON null. Though, by the same rule it would also be ok to write empty string (or both). I think we chose just always writing null to be consistent. Or it possibly was related to COMPACT mode implementation in part as there in PubSub things are compared to the default value and not written (and in some cases this also applies to the VERBOSE mode).
Also noting that your code shows the new VERBOSE mode added in 5.5.0 (together with COMPACT), so there can be some other changes as well compared to the old modes, which are avaiable as LEGACY_REVERSIBLE and LEGACY_NON_REVERSIBLE. Though that being said the null/empty thing should also apply there.
1 Guest(s)
