Well, yes there should be a way, although I didn’t quite understand what you expect to happen.

You can use the information model to generate code for both client and server side development. This will help you working with complete Java objects that represent the Machines.

But, there is no automatic way to create a new Machine object in the client and make it appear in the server. Or if you change the attributes of the client side object, they are not automatically copied to the server.

You will need to use the UaCliient.write (writeAttributes, etc) to modify attribute values to the server objects. And if you wish to add or remove objects, you need to

#1 enable node management

#2 call addNode/addNodes or deleteNode/deleteNodes from the client to add the objects to the server, one node at a time.

Does this answer your question?

The IOManager is responsible of responding to read and write requests. If you use the NodeManagerUaNode, it uses the default IoManagerUaNode that copies values directly to the nodes.

So, only if you have a custom NodeManager, should you need a custom IoManagaer as well.

You can still plug an IoManagerListener to the default IoManager to validate client requests, if you need to do so.

OK, you can test it like this.

Add the following Action to the SampleConsoleServer (beginning of the class), if you don’t have a server that supports NodeManagement yet:

This adds a toggle ‘N’ that you can use to enable Node Management in the server.

then you can add the following method to SampleConsoleClient – or your own client without the ‘println’ and ‘prompt’ calls:

‘prompt’ is actually a new method as well

This adds just a node of BaseObjectType to the server, but you can modify it to your needs.

Note that even when you have enabled Node Management, the server requires that you connect with a non-Anonymous UserIdentity. SampleConsoleClient takes the username (-u) and password (-p) from the command line, for example.

Also, you cannot add nodes to nodes that are in the standard Namespace, so you have to browse to MyObjects, for example, before it works.

So, this should help you to get started.

Hi,

Based on the above my assumption is that you are also using our SDK in the server side.

Assuming the information model is loaded in the server side, you basically change the typeDefinitionId in the code above to be the MachineType TypeDefinition node (the in the Types part, I’m assuming it is an ObjectType node).

Assuming NodeManagerUaNode is the manager handling the namespace on the server side, it will do the same thing as a (NodeManagerUaNode).createInstance(…) call would (see SampleConsoleServer + MyNodeManager for creating e.g. the alarm node), i.e. create all Mandatory nodes below that type. Any Optionals you would need to create yourself however, unless configured in the manager (basically the server would have then to be made to expect AddNodes to be done like this, see also the alarm creation in the MyNodeManager sample)

However, also note that this doesn’t “automatically” persist these changes in the server, unless the server reacts to it i.e. on a restart it would lose the changes.

You can note the AddNodes happening via a NodeManagerListener.onAddNode (or onAfterAddNode). The logic of making the node happens in ‘protected UaNode createNodeForAddNodesRequest(NodeId nodeId, QualifiedName browseName, NodeClass nodeClass, ExpandedNodeId typeDefinitionId, LocalizedText displayName)’, which can be overridden if needed. There is ‘createNodeForNodeSet2’ also when the nodes are loaded from a NodeSet2 file. Do note the difference is that when loading a NodeSet, it must contain all the nodes, but when the client calls AddNodes, the server shall make all Mandatory nodes below the type given (BaseObjectType has none, thus only that node was created). And also this behaviour was clarified at some point in the spec, i.e. some older servers might incorrectly just do the “top-lvl” node in types.

IF the server doesn’t even have the TypeDefinition, you can create that node-by-node via AddNodes (NodeClasses ObjectType+VariableType and for the structure other ones as well), and then use the NodeId of the Type later (the instantiation doesn’t need Codegen, just for the types to exist, and in the presense of Codegen classes those more-specific-uanode implementations would be used).

P.S. IMPORTANT
Also consider adding user validation via the NodeManagerListener to all NodeManagers, as otherwise any client that can make sessions on the server can e.g. delete the ‘Server’ node. Thus you should check that and throw a StatusException if the operation is not allowed (this is why the nodemanagement is by default disabled). If you trust and know all clients then this might not be needed.

Put the NodeId of the MachineType “type node” there. This is assuming my assumption was correct that the information model is loaded on the server side. If not you would need to load them first to the server.

Anyway, assuming the model is loaded in the Server, look with a graphical client such as our https://www.prosysopc.com/products/opc-ua-browser/ in the Types part of the server.

Alternatively, since you have generated the model in the client side, there is a XXXIds class, where XXX is the “prefix” in the configuration when generating. If no prefix was used the class is just ‘Ids’. IMPORTANT, the SDK already also includes an ‘Ids’ class internally, for the base namespace, thus be careful which class you import if this is the case (the prefix is preferred).

And technically com.prosysopc.ua.AnnotationUtils.readTypeDefinitionId(MachineType.class) would also give it, though the Ids-way would be the expected way instead of this.

Also for the first approach, we would recommend storing the NodeId as an ExpandedNodeId with the NamespaceUri instead of the NamespaceIndex (the number X in the NodeId ns=X;…) (the index points to Objects/Server/NamespaceArray the string at that index in the value is the NamespaceUri of that namespace), and then transforming it to NodeId in the context of (UaClient)client.getNamespaceTable(). This is also what you would do with the Ids output (since the generator cannot know which index it would be they are ExpandedNodeIds with the uri).

Well, in general I would say you would want to do it the other way around: only set the value to the node once you have successfully written it to the DB. Otherwise the client would see the value, but if e.g. the server machine crashed just there before it was written to the DB on a restart that value would be lost. If done database-first it would not be.

Basically at the point when the IoManagerListener onXXX are being called, the accesslevel and datatype have been checked, so basically unless you prevent it in the listener it will be successful. Thus you could write it to the DB within the listener method.