Hi,

Hmm.. that part seems a bit outdated, though partially true still. Should be improved in some future version..

As long as the Broker itself supports the wildcard topic string given to a Reader configuration, SDK should be able to get the raw MQTT messages (use a Reader configuration with null or 0 in place of PublisherId/WriterGroupId/WriterId etc). However, it might not be able to process them all yet. If interested, the raw messages are obtainable via PubSubSystem event listeners
pubSubSystem.addEventListener(PubSubMqttEvents.PUB_SUB_MQTT_RAW_MESSAGE_RECEIVED, event -> …)
(This is what our https://prosysopc.com/products…..a-browser/ uses in the PubSub ‘Log’ view for the raw messages)

For MQTT-UADP side the processing probably wont work that well yet or the results are undefined if more than one PublisherId+WriterId messages are seen, as there is a sequence number and those are not yet handled in a wildcard way.

For MQTT-JSON side the processing should work. However, it would only make sense if you handle those messages manually from the events send by the PubSubSystem, i.e. something like this:

pubSubSystem.addEventListener(PubSubMqttEvents.PUB_SUB_MQTT_JSON_NETWORK_MESSAGE_RECEIVED, event -> {
event.getNetworkMessage().getMessages().forEach(msg -> {
if (msg instanceof PubSubJsonDataSetMessage) {
PubSubJsonDataSetMessage dsmsg = (PubSubJsonDataSetMessage) msg;
dsmsg.getDataSetFields().forEach((field, value) -> System.out.println(field + “:” + value));
}
if (msg instanceof PubSubJsonDataSetMetaDataMessage) {
// Can be ignored
}
});
});
i.e. trying to do e.g. PubSubMqttJsonDataSetReaderConf.Builder.setSubscribedDataSet(PubSubTargetVariablesConf wouldn’t work in practice as it would work only a defined dataset, not in a wildcard way.

Eventually our Browser should use the above wildcard logic, but doesn’t yet do that, but the concept in general should work already for the JSON side (let us know if not).

Regarding the DataSetMetaData, nowadays those are stored outside of the Readers. SDK keeps by default 1000 latest received metadatas (number changed via PubSubSystemOverrides). As long as there is a matching metadata for PublisherId+WriterId for a message (and that the Publisher side used a format that includes these fields in the header part!), it will be used in the decoding. In the absense of the metadata for UADP side SDK will create fieldnames (e.g. Field1,2,3…), for JSON it tries to use heuristics to guess them from the JSON data itself (there is more than one format depending on the flags used by the Publisher). Pre-known DatasetMetaDatas can be given to PubSubSystemConf. UADP RAW format is not yet supported.

P.S.
It should be noted that in the future it is intended (at least the UA specification assumes this) that only the new JSON encoding modes Compact/Verbose would be used, for which we added some support in 5.5.0. Also, in general one should preferably choose one of the “header layouts” defined by the spec in https://reference.opcfoundatio…..5/docs/A.3, which fixes some bits (some can be configured). Probably some future SDK version will add some helpers regarding these as for now they are somewhat cumbersome to configure right now.

What version of the SDK you are using?

The periodic DataSetMetaData sending should just work. If you use https://prosysopc.com/products…..a-browser/ or a generic MQTT client and the SDK samples you should be able to see it working. At least in 5.6.2 distribution packages, first starting ‘samplebroker’ without any arguments, connecting Browser (or some other MQTT client) to it and then starting ‘samplepublisherserver’ with either “-e uadp -a mqtt://localhost:1883” or “-e json -a mqtt://localhost:1883” arguments (without quotes) you should see about every 30 seconds a metadata message for both sample datasets (one variable, one event) in prosysopc/sample/metadata in the Browser’s Log tab/view (or any other MQTT client). The samples do set the 30s in com.prosysopc.ua.samples.pubsub.SamplePubSubConfiguration.initBrokerTransportSettings(Builder, String, String).

Assuming the above works for you, you could print both PubSubSystemConf of the sample (from SamplePubSubConfiguration.createPubSubSystem(…) once it is built) and your application’s one and compare them to find differences.

We do not support all metadata parameters such as versioning and not all data forms in general (such as RawData in UADP). If the configuration of a DataSet changes, that should change the metadata as well, but e.g. nodes datatype change by itself does not change it. Though changing DataSets is pretty much untested still, it should somewhat work at least with our Subscriber side.

It should be noted that the sample is a bit outdated vs. current spec. The idea at least is that a topic tree defined at https://reference.opcfoundatio…..cs/7.3.4.7 could be used in the future to allow more generic discovery of Publishers. We have some support for it, though it requires currently not setting neither of the QueueName and MetaDataQueueName, the prefix comes from PubSubSystemConf.getMqttTopicTreePrefix() (“opcua” is used if nothing is set). In this world there might not be much sense to send the metadata unless it changes as a single topic will hold single metadata (assuming the Broker supports RETAIN messages, as one can be held per topic) or the Broker is restated (if it doesn’t hold RETAIN messages over restarts as well).