ditto
ditto copied to clipboard
Allow connection payload mappers to look up things before mapping
Currently Ditto's Payload Mappers in managed connections are rather "stateless".
They convert incoming payload to a Ditto Protocol message without the ability to look additional information up.
One of the reasons for that is sandboxing, so that e.g. a payload mapper e.g. does not do heavy "external lookups".
A great addition however would be if payload mappers could look up information (Ditto internally) from the "thing" they want to update, e.g. retrieving the "thing definition" or some kind of "type" attribute to execute different payload mapper code for different types of things.
That would require that a Payload Mapper can retrieve a thing (or its static information like "definition" and "attributes" - we could make that configurable what should be able to be retrieved in payload mappers as "thing context" information) before applying the actual payload mapping.
Details:
- define somehow how to extract the
thingId
to retrieve information from (e.g. via placeholders .. e.g. from the MQTT or Kafka topic or via a header, optionally applying a function)- as part of the "Connection" mapper config
- configure in Ditto "connectivity" service config which fields should be able to retrieve at all (default: thingId,definition,attributes)
- configure in the payload mapper options what to retrieve, e.g. as
fields
selector like e.g.:fields=definition,attributes
- inject the "thingStaticContext" as optional parameter to payload mappers
- also enhance the JavaScript payload mapper with that option
- think about caching - if we only retrieve static information (like "definition", "attributes"), this information should not change too often
- it should also be possible to do a "search" via attributes, as alternative to already "know" the
thingId
based from headers or topic- first match is returned, e.g.: with fields:
thingId,definition,attributes
- first match is returned, e.g.: with fields:
- the payload mapper may only map Ditto Protocol messages with the same
thingId
as the looked up one- that is a security feature and shall prevent cross-thing problems