Hi,

In OPC UA the Types are also nodes, therefore the DataType Attribute returns the NodeId for the corresponding DataType node. For the standard types, these NodeIds are constants defined by the specification. For spec version 1.03, they and links to the csv files can be found in Part 6 Annex A, however in practice you only need to use the Identifiers class as the constants have been codegenerated to it. Therefore you can do e.g.:

If you want to display the data type nodeid e.g. in an UI you can read the DisplayName of it (to clarify, you would read using the dataTypeId in the above example)

– Bjarne

Hi,

The UaDataType interface models the nodes in the Types/DataTypes folder. Each type there is a scalar type (even e.g. ByteString which has array-like semantics). The Class object returned by getJavaClass therefore gives the java type that matches the scalar type of OPC UA. There are no separate nodes for array types as it would make no sense as there can be e.g. 3-dimensional arrays (and also the dimension might not be fixed at all, see ValueRanks 0, -2, -3). Therefore the only way is to check the ValueRank Attribute of the node.

During runtime you could also check the the class of the Variant.getValue() (assuming non-null value), however note that gives the value as it is encoded (per spec Part 6) e.g. Enumerations are encoded as UA Int32 (java Integer), therefore you need the DataType to separate those from normal Int32 values.

The codegen is a (completely) separate program, so unfortunately there is no convenience methods for this case in the SDK. However in practice you can: for ValueRanks > 0 you just add equal number of dimensions to the base type. For the Any -2, OneOrMoreDimensions 0, ScalarOrOneDimension -3 ValueRanks, you could ignore them probably at the moment as I have not seen them used in actual models.

If I may ask, what are you trying to generate? (i.e. is there a feature that could be implemented to the codegen as a newer version of it will be in the upcoming 3.0)

– Bjarne

Generating more than 1-level deep accessors is problematic.

One of the problems is that e.g. in the above example the FolderType InstanceDeclaration is backed by FolderType(Node/Impl). Code of that class obviously cannot change. This would mean the only place where the accessor code could go is MyType(Node/Impl) class. However this gives new problems and questions:
1. How deep should the search go?
2. How to make obivious that the accessor is for not one level deep? Probably would needed to be prefixed by something to avoid clashing names if same node is on more levels deep. The method names would end up quite long after 2 levels..
3. Should accessors be created also for those nodes that are part of the TypeDefinition of the InstanceDeclaration? FolderType does not have any subnodes, but many ObjectTypes do.

I would recommend that e.g. in the above example a new subtype of FolderType would be created, lets say AType, then you could do e.g. getAInstanceDeclrationName().getElem1(). This might work if the number of types is not large.