2021/02/22

Getting Started with Automatiko - IoT and MQTT - Part 1

Around a month ago there was the first release of Automatiko project. It aims at providing an easy to use yet powerful toolkit to build services and functions based on workflows and decision. You can read up more information about the Automatiko project at the website or blog.

This blog post is very basic introduction that attempts to address the first level of entry when starting with Automatiko. 

Before you start...

So first things first... to get you up and running you need few things on your local computer

  • Java 11 +
  • Maven 3.6 +
  • Eclipse IDE  and Automatiko plugin
  • Optionally docker or podman to run services as containers

Head directly to documentation of Automatiko project to follow step by step instruction how to get the above up and running.

The use case

The use case of this introductory sample is very simple - to connect to MQTT to receive data from the sensors that are being published there. It mainly focuses on the steps to get this working and further articles will provide more advanced features in action.

Let's get started


To get started you need to create a project, a maven project to be precise. Luckily Automatiko comes with bunch of maven archetypes that makes this task way faster. One of the is `automatiko-iot-archetype` and this is the one we are going to use today.

Archetype can be used from IDE or command line so whatever you prefer can be used and result will be exactly the same.

Once the project is there, you need to define your data model that will be used by the workflow - as data objects. In this example you can create simple POJO like class names `Temperature` that will have two fields

  • value - of type double that will contain the temperature value from the sensor
  • room - the location where the temperature was measured

Next step is to create a workflow definition that will be responsible for connection to MQTT broker. This is realised by message start event that allows not only to be the entry point for new instances but also allows to define some characteristics of the connectivity and processing.



All that is needed to talk to the MQTT broker is defined directly in the workflow definition. In our sample case, the topic in MQTT broker is simple taken from the message defined on the start event.

At the same time, data that is received from the MQTT topic is automatically converted to the data model - represented as 'Temperature` class and mapped to a `temp` data object inside the workflow instance.

Lastly, user task is also added to the workflow definition that introduces a human actor into the flow. That is mainly for demonstration purpose to show we receive data from MQTT that is properly converted into a Temperature class instance and set within the workflow instance data objects (aka variables).

A bit of advance...

As you will see when running this sample, ID of the workflow instance is auto generated (in UUID format). But that can be changed and take advantage of either data or the MQTT topic itself. By setting correlation or correlation expression on the message (via its custom attributes) you can set the id to be more domain specific.




In this case, we take the room from the message and use it as correlation. Correlation upon start of the workflow instance becomes its id - aka business key and by that it can be used in exchange with the generated ID. With that said you can use this when interacting with service API.


You can look at the introduction video that covers the content of this article.

Let's get this running...

To get this running we need a MQTT broker. Personally I find Mosquitto to be excellent choice but any MQTT compliant broker would work.  

You can get Mosqiutto running with just a simple command (docker required)

docker run -it -p 1883:1883 -p 9001:9001 eclipse-mosquitto

There are other ways to run mosquitto so visit website if docker is not an option.

Run the Automatiko service

Since Automatiko generates fully functional service there is no much to do to see it in action. It is based on maven and leverages Quarkus as runtime so most Quarkus features are also available out of the box e.g. dev mode, Dev UI etc.

mvn clean quarkus:dev

and then wait a bit for maven to download all the bits....

Once it's started you should see similar log entries


You can head directly to http://localhost:8080/swagger-ui and you will be presented with nicely document API of your service


So it is now fully functional service connected to your local MQTT broker. With this you can start publishing sensor data to it and see how quickly they are consumed by Automatiko service.

You can use mosquitto client command to publish messages from command line

mosquitto_pub -t temperature -m '{"room":"livingroom", "value" : 25.0}'

use Swagger UI to see created instances based on incoming messages from MQTT.

Running as container

In case you would like to get this running as container then it is again dead simple, just run maven command with `container` profile enabled

mvn clean package -Pcontainer

And that's it. As soon as build is over you will have the container image in your local registry.

Conclusion

That's it for the first introduction - I hope it will get you interested and you will look forward for the next articles. They will come ever other week... at least that's the plan. Please share your feedback either here or via mailing list and twitter. 

If you have any ideas for the use cases to cover with Automatiko don't hesitate to let us know about them as we are here to help and explore.

Thanks for reading!