The aim of this single-file project is to automatically create Disque jobs
from data that is being pushed to an MQTT broker. The implementation is meant to
be given as part of the configuration of the generic mqtt2any bridge. The
assumption made by this project is that you use your MQTT topic hierarchy in a
REST-routing like manner: the project will be able to extract the value of some
fields between the slashes /
of the MQTT topic hiearchy and to copy their
values into the job data that is created at the remote Disque server. For
proper operation, this project depends on disque, the Tcl implementation of
the Disque API. The project is JSON-opinionated (-validate
option turned on
by default, see below) but can also be used for any other type of data.
In its easiest form, the implementation takes a file describing MQTT topic
matching and data templating out of the various items extracted out of the topic
path together with the incoming data, i.e. together with the data that was sent
to the topic. Topics are delimited by slashes /
and the file is able to
specify how to work on the various elements between the slashes. The format is
so that lines starting with a hash mark #
are comments and will be ignored and
so will empty lines. Otherwise should a dash-led key followed by the value be
contained on the lines. Whenever the value starts with a @
-character, its
content will be got from the path consistuted of the remaining characters of the
value. This is particularily useful for complex values that span multiple lines.
Relative paths are relative to the directory that contained this file. The
recognised keys are the following.
-
-marker
is a regular expression describing a marker that should be looked for in the path. This marker will have an implicit order number of 0 and following slash separated items will have order number 1, 2, 3, etc. Whenever no marker is present, the first item is ranked as 0. When the marker cannot be found, no matching or templating operation will be performed. -
-match
should contain an even long list alternating a rank number starting from the marker and a regular expression. All these expressions should match the items in the topic path at this rank number. -
-template
is a string that will be used to form the content of what is being pushed to the Disque queue. In that string, any occurrence of an integer surrounded by%
signs, e.g.%1%
will be replaced by the value of that item in the topic, starting from the marker. Any occurrence of%data%
will be replaced by the data that was sent to the MQTT topic.
An almost real-life example is provided below:
# Force to look for the first possible appearance of myapi in the topic list,
# this is typically the first item in the slashed topic. Topics that do not
# contain my api will be completely ignored.
-marker myapi
# Starting from the marker, arrange to force the presence of a version number,
# followed by the keywords device and data.
-match {1 {1.\d+(.\d)?} 2 device 3 data}
# Some other fields that we wish to collect from the topic will be picked up and
# used in the forward.tpl file
-template @forward.tpl
The content of the forward.tpl
could look like the following. In this example,
the fields #4 and #5 in the MQTT topic hierarchy contain a customer and location
identifiers, these are passed further to the JSON expression that is being
constructed as part of the template. It would have been possible to force some
formatting check as part of the -match
list in the file examplified above.
Note the use of %data%
which copies the data that arrived at the MQTT topic
verbatim.
{
"customer": "%4%",
"location": "%5%",
"data": %data%
}
The project can be configured using a number of options. When interfacing with
mqtt2any
, the best solution consists in creating environment variables that
are named after the name of the options. For a given dash-led option, remove the
leading dash, change it to upper case and insert DISQUE_
at the beginning,
where DISQUE
is the uppercased basename of the implementation.
Longer options such as password or queue can have a value that will start with
a @
-sign. In that case, the remaining characters will form the path to a file
containing the true value of the option. This can be useful for secret values
or longer values.
The dash-led options accepted are as follows:
-host
Hostname of the Disque server to post templated data to.-port
Port number at the Disque server to post templated data to.-password
Password at the Disque server. The content of this option can be redirected from a file using a leading @-sign as described above.-queues
List of queues at the Disque server to send data to. The content of this option can be redirected from a file using a leading @-sign as described above.-ttl
TTL for jobs-retry
Max number of seconds for retries.-async
Boolean telling if we should post jobs in asynchronous manner to the Disque cluster. This trusts that the cluster is not dismantled at the time of job posting to guarantee persistence when set totrue
(the default).-replicate
Number of job replicas, negative for Disque default.-comment
Character to lead comments in files, this is#
by default and changing is at your own risks.-redirect
Character to detect redirections of values to filepaths. This is@
by default and changing is at your own risks.-validate
Boolean requiring the data to be received and used as part of the template in%data%
to be valid JSON. This requires to be able to load the tcllib json package, the package is lazy-loaded, meaning that it will not be loaded when the boolean is false.
You should arrange for the procedure called forward
to be the one that is
bound to the MQTT topic subscription in the mqtt2any
configuration.
Easiest is to pass the full path to the configuration file (see above) as an
argument to the procedure. Further details are provided in the mqtt2any
manual, but this involves the use of the !
special character for separating
the path from the name of the procedure.
Another solution is to pass the different options described in the file
configuration section above, i.e. -marker
, -match
, -template
together with
their values as arguments to the procedure called forward
. However, this
usually rapidly turns to lines too long to visually parse, provided the large
number of !
separators to provide.
As mqtt2any
uses sandboxed interpreters, you will have to do some extra
configuration work. Through the options that can be specified as part of the routing specifications. Interesting options to look for/at are:
-allow
to open the firewall and make sure that your slave interpreter is able to access the disque server/cluster.-access
to make sure the slave interpreter is able to read the configuration and/or templating files.-path
to modify the package access path.-package
to help the slave obtaining the disque package, even though this is made explicit at the beginning of the implementation.