Hi,

This is one of the most complicated things in OPC UA.

In short, you can try

but note that it might no longer work with all servers, as OPC UA 1.04 defined a new way for the Structure’s metadata with the new DataTypeDefinition Attribute. Also it added e.g. support for multidimensional array field encoding, which cannot be represented with the old DataTypeDictionary concept (which in SDK 3.x the TypeDictionary is using; in 4.x it will abstract to using DataTypeDefinition first and then DataTypeDictionaries as a backup).

If the TypeDictionary.decode worked, it will output a DynamicStructure that you can use to get the information, modify the data, and TypeDictionary.encode(…) it back to ExtensionObject.

Was there an explanation in any nested exception in the full stacktrace?

Do you have an information model (as a NodeSet2 XML file) that would contain the structure type in question?
Or do you in general know what Structure it is?
Can you check the address space with e.g. our Browser tool or with UaExpert?
Does the server have a node in Root/Types/DataTypes/OPC Binary/ that has the same namespace in the NodeId as the typeId of the ExtensionObject?
Can you paste the TypeId here?

It can be a bit hard to locate what node it is, since the encoding id is not the datatype nodeId, but the node below it (but it is also nonhierarchical so not typically visible in tree views, though our Browse has a toggle to show them as well). But if you check them all manually so that you know whose DataType ‘Default Binary’ node that is you would then know the DataType (or do an inverse Browse with the SDK from the encoding node). Then you could check does it have a DataTypeDefinition Attribute. Or in general, does any Structure type in the server have that? Note that you must be running our Browser or a somewhat recent version of UaExpert to see that 1.04 specific Attribute in the first place.

Technically IF you have the type in a NodeSet2 XML you could also codegenerate that type with the Codegen of the SDK, but that would not work in a generic case (since it is an offline tool). Also would not help if it e.g. had multidimensional array field since that would require 1.04 knowledge for decoding.

But in general, IF you have an option to try with 4.x and if that would work, then pretty much upgrading to 4.x is the solution.

P.S.
Very unlikely, but it could also be the 1.04 new DataType ‘Decimal’, which is not a Structure, but only encoded as such. Then the encoding typeId would be exactly i=50 in the standard base namespace (so index 0 or uri http://opcfoundation.org/UA/).

OH! Well, that makes an answer much easier.

That part of the sample only works with 1.04 clients, as mentioned in the comments:
“
private void createCustomStructure() throws StatusException {
// This creates a simple custom Structure type and an instance using it.
// NOTE! This wont create DataTypeDictionaries, thus only 1.04 clients capable of using 1.04
// introduced Attribute DataTypeDefinition can handle this.
“

And that is because it only makes the DataTypeDefinition (the new 1.04 Attribute; StructureSpecifications are converted to it internally) and not the old DataTypeDictionaries.

Similarly, you might encounter a 1.04 Server in the real world that does the same. In that case the only option is to start to use SDK 4.x.

While technically it would be possible to edit the sample with some non-trivial amount of work to add the dictionary nodes, it would not help for a generic client. The only situation where it would help is if you would all the servers you are connecting to. Plus you could not use e.g. multidimensional array fields in Structures, since that 1.04 concept cannot be represented by any rule in the old dictionary system.

In short: there is no version of 4.x (nor there ever be a version of the SDK) that would use “the stack” anymore, since it basically doesn’t anymore exist.
Note on https://github.com/OPCFoundation/UA-Java-Legacy (and note that the repo name is *-Legacy nowadays)
“This repository is provided by OPC Foundation as legacy support for an Java version for OPC UA. It will not receive further features and updates.

The OPC Foundation will continue maintenance of the .NET Stack which is based on .NET Standard. It can be found here.”

In longer:
No, as the stack was effectively discontinued we cannot use it anymore, thus in 4.x there is no longer a concept of a “stack”. As explained in the migration guide: “The OPC UA Stack is now integrated as part of the Prosys OPC UA SDK. It is based on the open source OPC Foundation Java Stack, but based on our agreement with the OPC Foundation we can provide it under the Prosys OPC UA SDK license.” Due to that it is the way it is.

But it should be noted, that there is no longer a separation of the “stack level” and “SDK level” in the code. Things that were previously “in the stack” do nowadays depend on “SDK level” classes. For example, the Structure has the same API mostly as the DynamicStructure and it has the .specification etc. that returns SDK class StructureSpecification. This allows handling of all Structures in a dynamic manner.

That being said, the migration process from 3.x to at least 4.0.0 should be relatively simple with mostly renaming imports. There are a few areas that might require a bit more code, such as e.g. AccessLevel etc. “OptionSetLike” types (in OPC UA 1.04 the OPC Foundation added subtypes for the Attributes that are now proper types thus it required some changes as we didn’t want to have effectively duplicate classes in the SDK). IF there is a problem with it please let us know..

Please answer Matti’s question in https://forum.prosysopc.com/forum/opc-ua-java-sdk/how-to-import-nodeset-xml-file-in-sampleconsoleserver/#p5747 or basically send the nodeset to uajava-support@prosysopc.com once (if) you can.

The node existed already. NodeIds must be unique and SDK will prevent you from making 2 nodes with the same id. Since the NodeId had the format i=13932, i.e. without a namespaceindex it means it is in the 0 namespace, or the so called “base namespace” or sometimes I have used the term “standard namespace”.

This is a simplified version, but you cannot add nodes (technically; you can, but you should never basically do that) to the standard namespace, it is handled by the SDK automatically. Trying to add nodes to it will basically fail, as you observed. We load internally the NodeSet2 XML for the base/standard/index0 namespace and the model is embbed inside the SDK. This is not user-updateable (since basically any updates to it will in practice require updates to the SDK; e.g. the latest errata for the base namespace added new kinds of Structures; so we cannot yet update to the very latest one 1.04.10, until we add support for the new features so e.g. 4.6.2 still ships with 1.04.9, this just an example and should not be related to this case).

If you have used some sort of an export tool, e.g. UaExpert has a (paid/commercial) plugin for that, please do not export the namespaceindex 0. Note that an export might not have 100% same exact info as the server had if it loaded such nodeset, but typically it is close enough.

As to why it doesn’t work I could theoretize few A4 pages worth of problem scenarios we have encountered during the years. It is complicated. To start we need to know is this an OPC UA 1.04 Server that does support DataTypeDefinition Attribute and does it support it for all DataTypes. If not, things might go differently as this is a new mechanism added in OPC UA 1.04.

Also, we do not support every possible thing yet of 1.04. Does the Structure type contain fields that are subtypes of the OptionSet Structure type OR are they a subtype of unsigned integer types (Byte, UInt16, UInt32, UInt64) where the DataType node has a Property whose BrowseName is “OptionSetValues”? If yes then in short they do not yet work properly with the SDK (explanation is long, so I’ll skip for now). It should work maybe better if you have the NodeSet2 and can run our codegen tool for it, but it doesn’t really help in a generic client case. But since you made similar type with the SDK it might not be this (but it is still possible, long story to explain..).

When connecting to your customer’s server, do you see INFO level log “TypeDictionary initialized successfully”. Regradless, you could try logging with DEBUG level on package ‘com.prosysopc.ua.typedictionary’ and send that to uajava-support@prosysopc.com (if possible). That might output somewhat a lot of lines, but should show if we fail to resolve some types (4.x by default will read all types on connect and initializes the TypeDictionary, which will hold custom StructureSpecifications and EnumerationSpecifications).

Basically the best would be to get the value of the DataTypeDefinition Attribute of the DataType (if it doesn’t have that, then it is a lot complicated, so I’ll skip explanations for now how the older DataTypeDictionaries work).