Log In
Register
Forum
Topic RSS
12:59, EEST
July 30, 2015
Offline
Suppose I have an ExpandedNodeId in variable expandedNodeId. I want to “serialize” it for future use, like this:
String serializedExpandedNodeId = expandedNodeId.toString();
Then, later, maybe in a future session I would recreate the ExpandedNodeId like this:
ExpandedNodeId restoredExpandedNodeId
= ExpandedNodeId.parseExpandedNodeId(serializedExpandedNodeId);
However, doesn’t work for me, because serialization with .toString() does url encoding to the name space uri, which .parseExpandedNodeId apparently does not decode. Instead takes %3A (colon), %5C (backslash) as parts of the uri.
My SDK version is 2.1.0.
* * *
Questions:
Is .parseExpandedNodeId() supposed to be the inverse of .toString() for ExpandedNodeId?
If not, what is the proper way to produce a .parseExpandedNodeId-compatible string representation of an ExpandedNodeId?
Is there a best practice for storing references to nodes (as string) so that they will work across sessions?
thanks,
Mikko
15:48, EEST
April 3, 2012
Offline
Hi,
Good questions.
Is .parseExpandedNodeId() supposed to be the inverse of .toString() for ExpandedNodeId?
The ExpandedNodeId is part of the stack, not the SDK, therefore it is a bit hard to say. We only do some maintaining work and some new feature every now for the stack (depending on the opc foundation). Looking at some call hierarchies, it seems the parse method is used by the XmlDecoder, so the format should be the one defined in specification Part 6, section 5.3.1.11, but it seems it does not do the decoding which toString does. Given that the toString does similar format (I’m not 100% sure the encoding is one needed for XML encoding, since the stack does not support XML encoding, but the encoding aside the string format looks same), I guess it could be assumed that it should be parseable back. And the decoder not decoding the uri seems to be a bug (or maybe the decoder using the parse method is the bug).
If not, what is the proper way to produce a .parseExpandedNodeId-compatible string representation of an ExpandedNodeId?
Until the issue is fixed, I guess the best option is to replace the nsu part with ExpandedNodeId.getNamespaceUri (unless you have ‘;’ in your uri). Our codegen also seems to use the same format in TypeDefinitionId annotations, e.g. in AnalogItemType we have “@TypeDefinitionId(“nsu=http://opcfoundation.org/UA/;i=2368″)”.
Is there a best practice for storing references to nodes (as string) so that they will work across sessions?
Not for strings particular, but these are my general observations (and assuming session means different execution, but same software):
– Use namespace uri always, unless you can be certain that the namespace index of that uri never changes e.g. between server restarts
– ServerIndex can be assumed to be always 0 (if it would be anything other, then it would point to a different server, i.e. it would require special handling from the client and so far I do not know any client which would do this, also I have never seen the server index to be anything other than 0)
– Use UaClient.getNamespaceTable to convert between uri and id and between Expanded and normal NodeId
The format in Part 6, section 5.3.1.11 is probably still the best for a single string, i.e.:
svr=serverindex;ns=namespaceindex; type=value
or
svr=serverindex;nsu=namespaceuri; type=value
– Bjarne
15:56, EEST
April 3, 2012
Offline
Hmm seems that the reserved characters for the NamespaceUri encoding are only ‘;’ and ‘%’ (the encoding algorith itself, i.e. % with hex for reserved chars, seems to be correct) so the toString does not encode the namespace uri to the format specified in part 6, 5.3.1.11. Thing is that I don’t know if it is supposed to since it is just a “toString” and not “encode”. I need to discuss with some people that are currently on vacation so this might take a while.
– Bjarne
7:02, EEST
July 30, 2015
Offline
Thank you for quick analysis of the topic!
I think I’ll proceed by URLDecode.decode() ‘ing (from java.net.URLDecoder) the string produced by ExpandedNodeId.toString() so that ExpandedNodeId.parse() gets an unencoded string representation of the id. Seems to work.
To me it would seem logical if there was a public counterpart of .parse for the ExpandedNodeId class. On the other hand, it is a bit counter-intuitive that ExpandedNodeId.toString() produces URL-encoded string, as toString functions in general output human-readable representations.
But of course I can live with the fix above, no problem!
regards,
Mikko
Most Users Ever Online: 1919
Currently Online:
19 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 738
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1524
Posts: 6451
Newest Members:
jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettingerModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
