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.