Hi,

You can log all request/response pairs that the SDK part handles by implementing a RequestResponseListener and setting it to the UaServer:

Note that it will not log the lower-level messages handled by the stack layer, so in general you will see requests for the CreateSession and afterwards. These are also the same that can be logged in our SimulationServer Req/Res Log view (the feature was done for this use-case). However simulating these a second time is not in practice possible.

In general it is not possible or practical to simulate the client in the server side. Currently it is easier to just create a local client and use it to send the requests.

– Bjarne

Hi,

Unless you have exactly one client that sends exactly one request at a time and waits for the response before sending the next one, it is not possible to deterministically determine the order on the network level (i.e. no guarantee that they would be in the same order the next time). Therefore the order in which the stack layer receives them is random. Then the stack layer handles each request in a blocking-work-thread-pool and after they have been submitted to the pool the order of thread execution is also random (this is normal Java). Also in general Java Threads can pause and start at any time, therefore even if you would log them before they would be handled, nothing guarantees that the execution order between them has not changed on the next line of code (this is normal Java).

In theory the pool size could be one, but then the server would not be able to serve more than one request at a time (which would not be expected performance). However in practice the stack internals use the pool quite often so setting it to one could lead to an internal deadlock.

If you have exactly one client that sends exactly one request at a time and waits for the response before sending new one, then the scenario is different as the server only has one request to handle at a time (multiple clients case would also work, if there is only one request in total from all of them at any given time). However a real client application usually does not do this, e.g. most of the clients do actively monitor or read the server status in order to determine is the server up or to check if the status changes to shutdown, also it keeps the connection from timeouting. Even for a special client that would not do this, you would need to store all session related info and somehow put it back in a simulation as OPC UA is session based protocol, i.e. it is stateful.

– Bjarne

Hi,

You can cast the request/responses e.g. to ReadRequest/Response (if you add the same listener to other XXXServiceHandlers, you need to check that they are of correct type first), and then use getters of the casted one.

– Bjarne

Hi Luke,

In general the question is do you mean:
1. The OPC UA Auditing system as whole described in the specification (multiple places, but main concept is explained in v.1.03 Part 2 section 4.12.1)
2. Just recording all Read and Write request/responses?

Note that if you send events, then all clients that are able to make subscriptions with an EventFilter for the Properties of the Audit types will receive those events/data. Currently it is not possible to limit sending event to only a specific session, however you can add a SubscriptionManagerListener which forbids non-admin users to make EventFilters that contain fields for the audit Properties.

For AuditWriteUpdateEvents that would most likely be the correct procedure. OPC UA as of 1.03 seems to contain about 40 different Audit event types so that is the implementation of one of them.

In general if you want to make complete support for the audit system, you need to read the specification for all the details and follow them, including the Objects/Server/Auditing property.

– Bjarne

The specification v1.03 Part 4 section 6.3.8 for Auditing for Attribute Service Set mentions that:
“The Read and HistoryRead Services may generate audit entries and audit Events for failed Service invocations. These Services should generate an audit Event of type AuditEventType or a subtype of it. See Part 5 for the detailed assignment of the SourceNode, SourceName and additional parameters. The Message for Events of this type should include a description of why the Service failed.”

Therefore in the scope of the Auditing system (the 1. option in my prev answer) only failed service calls will be sent as events. In practical sense reads do not modify the state of the server and most clients do read the server status node periodically (e.g. once per second), therefore events for read operations would create a lot of events, which most likely is the reason there is no event for reads.

– Bjarne