Hi,

(I’ll answer shortly and continue next week if needed, as tomorrow is national holiday here)

Please read UA Specification (v 1.03) Part 5 section 12.16 (Table 157) on the ModelChangeStructureDataType. It explains the possible “verbs”.
For node add/delete: the node in question must have the nodeversion property, i.e. the node that was added or deleted).
For reference add/delete: the node for which references are added/removed must have the nodeversion property (i.e. the node must be target or source of the reference).

Therefore calling initNodeVersion on Objects folder only triggers events if references are added/removed from it directly. If you want NodeAdded, then the node in question which was added must itself have the initNodeVersion called before adding it to the address space (e.g. NodeManagerUaNode.addNode triggers it if the node to be added has the NodeVersion property). You still need to call NodeManagerRoot.begin/endModelChange in order for the event to be sent to the client (normally you send one event for multiple operations in case they are done at the same time).

As for the second question, the default NodeManager.getNode implentation keeps a cache to the last asked node as often it is needed multiple times in a row. Deleting and adding the same node back is not a very common scenario, however we should probably add logic to invalidate the cache if the given node is removed. Thanks for noticing this 🙂

– Bjarne

Yes that is correct.

Hmm.. I might have been misunderstanding the scenario. Do you mean about adding nodes from the client side via the AddNodes service call? As that is what the NodeManagerListener.onAddNode handler is for. If this is the case, then to my knowledge combining the model change events with AddNodes service calls is never done before (both of these features are used seldom). I suppose in this case the SDK could maybe in the future automatically create and trigger the event completely as there is clear starting and end points (start of adding the nodes and end after all nodes in the request have been added). IF this was the case, let me know, as workaround by overriding few methods should fix the issue.

Assuming you are adding the nodes in the server side, just call begin before calling NodeManagerUaNode.addNode and end after you have added all nodes.

Ok, then I had the right feeling about this..

I see at least 2 workaround options:

1)
For NodeManagerUaNode the AddNodes call routes to the following method which you could override in a subclass:
protected NodeId addNode(ServiceContext serviceContext, NodeId nodeId, NodeId parentNodeId,
QualifiedName browseName, NodeClass nodeClass, ExpandedNodeId typeDefinitionId, NodeAttributes attributes,
NodeId referenceTypeId) throws StatusException

You would call begin for the model change, then call the super implementation via super.addNode(…) and then end after. Note that since this method is called once per node to add in the request, so you would get one event per node. Also note that as-is this wont work for NodeAdded events, as the NodeVersion property does not exist for the node at this point. However the NodeManagerListener.onAddNode is called before the node is added internally calling addNode, therefore you could maybe init it there. Note that the super call is probably best to be done in a try-finally block in order to ensure end is called for the model change.

The node to be added is created is done in
protected UaNode createNodeForAddNode(NodeId nodeId, QualifiedName browseName, NodeClass nodeClass,
ExpandedNodeId typeDefinitionId, LocalizedText displayName)
therefore that would be another option (that is called before the listener onAddNode is called.

Also mentioning this just in case.. currently the way the AddNodes service is implemented, it creates 1:1 nodes of the ones requested, however this is one area where I’m not sure on the specification i.e. if node would be added via AddNodes and the TypeDefinition of the node is complex, i.e. has subnodes that are modelled as ModellingRule Mandatory. Currently it is assumed that client adds all the requested nodes, but the method can also be overridden to use createInstance or createNodeBuilder of the NodeManagerUaNode if it is desired that adding a single node with complex typedefinition would create all the nodes of that type.

You would need to override each NodeManagerUaNode for which nodes are added from the client side in order for this to work.

2)
There might be maybe easier way, assuming the ReferenceAdded/Deleted events are enough, however it would be a bit experimental as we don’t usually instruct to override these..

Create subclass of NodeManagementServiceHandler, with a constructor that passes values to the super constructor. Override
protected void addNodes(ServiceContext serviceContext, AddNodesRequest request, AddNodesResponse response)
throws ServiceException
similarly as in 1) with calling begin for model changes, then calling the super implemtation of the method and after that end. And like in 1), probably best to do in a try-finally block to ensure the end is called. Then create a subclass of UaServer, override:
protected NodeManagementServiceHandler createNodeManagementServiceHandler()
with creating the subclass of the NodeManagementServiceHandler done above (pass the sessionManager and nodeManagerTable protected fields as parameter). The events should then work and you should receive one event per AddNodes service call.

Sorry for the long post, please let me know if either did work. Probably we end up implementing something like 2) for the SDK in the future (directly to the existing class).

Also I suppose there is always option 3) IF your add operations are simple e.g. one kind of nodes to one place or something like that, you could also just create an Ua Method, and in the implementation of the method create the nodes (and call begin/end), and e.g. one Variable that would contain e.g. configuration timestamp which would be incremented and other clients would the rebrowse the address space as needed if they notice that the configuration timestamp has changed. Just mentioning this as an idea, as it probably is easier to implement anyway for both sides.

– Bjarne