Review concept for separation of templateTopic (mappingTopic) & subscriptionTopic about cumulocity-dynamic-mapper

[switschel]

Currently we support on subscribing on e.g. devices/# while having multiple mappings for sub paths like devices/type1/modelA/+ etc.

If we assume that templateTopic is equal subscriptionTopic this will not be supported anymore. In the example above you have to define the subscription like this devices/type1/modelA/+ for each mapping you want to define. This is more intentional in my view as devices/# is too abstract to define mappings in most cases.
Also subscribing devices/# might lead to a lot of spam message where we don't have any mapping defined, while the more concrete subscription path with "+" option leads to desired messages only.

Btw. "+" should be possible also to be used at the end of a topic path. e.g. devices/+/modelA/+ So we don't care about the type in the middle and deviceID in the end but only modelA.

[sagIoTPower]

For the moment we don't change this.
When additional connectors to different backend system/broker, e.g. Kafka, ... have been implemented and the implications are clearer, we might consider this again.
Currently the idea of these to properties are separate but linked:

• templateTopic -> is used as a key to store the mapping in an internal tree of mappings, for faster lookup at runtime. (in the meantime has been the property templateTopic has been renamed to mappingTopic)
• subscriptionTopic -> is relevant to subscribe on the connected broker

[sagIoTPower]

Close this was implemented. we renamed templateTopic -> mappingTopic