Mapping of json keys about cumulocity-dynamic-mapper

[switschel]

Hm we can investigate that but full generic mappings are always very dangerous. A lot of bad stuff can happen when using it. Our core concept is that we use a specific topic as a key for a mapping. So when the topic is /devicename/measurementname the payload including keys should always be the same (except the values of course).
You can also use a template where you define all possible keys by hand and map them accordingly in just one mapping.

[sagIoTPower]

Hi @simeonthefirst ,

you can try to use the following sample, to generate dynamicaliy new nodes:

This will transform the source msg. as follows:

If your mapping requires more flexibility, then I recommend using the programmatic approach. This means writing your own mapping class in Java and upload this to the mapper. A sample implementation can be found here.
The extension mechanism is documented here.

Pls. let me know if this helps.

--Christof

[simeonthefirst]

Hi,
thank you ! Your exampe, @sagIoTPower gives the flexibility to ignore the key-string on the device-side message what is part of what i wanted to achieve.
It does not enable me to change the measurement or series name on cumulocity side of the mapping. To realize a mapping like this (see below) , i will need to implement an extension. I will let you know when i do.

(device side)
{
 "Measurementname": "Airsensor",
 "Seriesename":"Humidity",
 "value":10,
 "unit":"%",
}
-->
(cumulocity side)
{
  "Airsensor": {
    "Humidity": {
      "unit": "%",
      "value": 10
    }
  }
 "time": ....
...
}

[sagIoTPower]

Hi @simeonthefirst,

I added a new setting RepaiStrategy = REMOVE_IF_NULL and added a sample, mapping number 23 ( flexMeasurement).

Could you pls. take a look if this helps and fits for your use case?

Regards Christof

[simeonthefirst]

Hi @sagIoTPower ,

thank you! I did not had the time to test it jet, but took a look at the example. For me it looks like the measurement-/fragmentname can now vary between different pre-known names. Or do i get it wrong?
More important for me would be to set the measurement-/fragmentname and/or also series name to something you don't now at the time when you create the mapping. I'm sorry if this was a misunderstanding.

best regards,
Simeon

[sagIoTPower]

Hi @simeonthefirst,
the graphical mapper aims to cover mapping where the structure of the messages is well understood and stable. This allows for a certain flexibility.
In your case you would like to define a mapping for messages with varying structure.
Could you take a look at the sample processor extension for JSON payload?
The sample defines a mapping as a processor extension in a Java class. This allows a higher degree of control over how to handle different payload structures.
The additional RepairStrategy.CREATE_IF_MISSING helps in this case as well.

The release v.3.1.7 covers this new strategy.

Regards

Christof