Currently custom operation handlers are defined for a cloud mapper, and the mapper will execute a command using the operation definitions stored in the /etc/tedge/operations/c8y/ directory.

However, now that the workflow concept was introduced, it would make more sense for the workflows to be the main way to execute some custom user action, and the mappers would only need a mapping definition to map from the cloud message to the tedge command interface, e.g. te/device/main///cmd/<custom_op>/<cloud>-<id>.

Current Custom Operation Handler

file: /etc/tedge/operations/c8y/set_wifi

command = "/usr/bin/set_wifi"
topic = "c8y/s/dc/custom_devmgmt"
on_message = "dm101"

Ideas

• Decouple incoming data model with the command sent to the workflow
• Consider options to publish the command to different sinks, e.g. a workflow (via mqtt) could be one sink, but a TCP stream (socket) could be another. A TCP stream sink could be useful when trying to launch an independent process such as the c8y-remote-access-plugin which is triggered via a systemd socket activated service, which would allow the c8y-remote-access-plugin to be fully independent from the process which triggered the c8y-remote-access-plugin instance allow for the mapper to be restarted (as the c8y-remote-access-plugin is not a child process of the mapper).