IoT Hub: Routing Messages to Different Destinations

Not long ago I was here talking about how to use IoT Edge to be able to deploy workloads on “on-prem” infrastructure, therefore solving the problems associated with network latencies or data protection (remember that with a processing model using IoT Edge, the data is processed within the client’s infrastructure).

I will never get tired of saying that each client is a world and the needs of one do not usually fit with those of another. It’s something I love because it makes everyday life more entertaining, but it makes our Azure-based IoT solution (Smart Concepts) have to be flexible and adaptable. Let’s remember the basic scenario we have:

Devices send data to IoT Hub.
An Azure Function collects the data from the Event Grid, processes it, and persists it.
They are exploited and monitored.

The problem

Although this model is effective and functional, our client has found it necessary to send a series of critical data for its business as part of the data. A good case of this could be for example sending alarms from devices, nobody wants an alarm to go unnoticed, right? What would happen if our processing is down or the message’s lifetime in Event Grid stopped? And what if the processing fails?

Message routing to the rescue

A good solution to this, for example, is to route the messages to an Azure Storage and have IoT Hub send them directly, or to a Service Bus, etc. We could redefine our previous scenario by changing the approach a bit so that all messages are received in an Azure Function, and this one sends them to the corresponding routes:

If we take a look, the scenario is exactly the same as the previous one, but we have added an Azure Function that is in charge of dispatching the messages to different routes, from where our processing system will pick them up to continue. This gives us on the one hand the possibility to use a more durable persistence for the messages, and on the other hand, it forces us to add extra infrastructure that must also be able to process the number of messages coming from IoT Hub. This is not always easy since IoT Hub is a service designed to be able to receive a large volume of messages, typical of IoT scenarios.

Filtering and routing messages from IoT Hub

Fortunately, IoT Hub natively supports that message filtering scenario to route messages to different destinations. Specifically, IoT Hub supports up to 10 different routes at the time of writing. To make it clear what I mean by route, an IoT Hub route is the “pipe” and filter that makes a message arrive at its destination. It is also important to note that IoT Hub routes are not exclusive, i.e. a message can be sent to more than one destination if the filters on several routes are met.

Our new scenario would be something like this:

The best of all this is that those “queries” with which we are going to make the filter, can use any of the properties, but they are also capable of using the body of the message itself.

In order to use the body of the message you must meet a series of requirements such as being in “UTF-8” and the “contentType” attribute being “application/json“.

Once we have this clear, we will see how to carry it out, in this case, for example, to route the messages to storage.

Creating a route from IoT Hub to Azure Storage

For this case, let’s assume that we have already created our IoT Hub and our Azure Storage account. The first thing we are going to do is to go to our IoT Hub instance and inside it to the message routing section, where we will create a new connection point by hitting the add button:

On the context menu that shows the add button, click on the option “Storage”. On this, a new form will guide us to create the connection point, where we will select things like the name of the point, the account, and storage container where they will be saved, as well as the name of the file and the frequency with which it is saved.

Once we have saved it, we should find that we can now find the connection point inside the storage section:

Once we have the connection point ready, we only need to create the routing that will make the magic. To do this, just go back to the routes tab and click on the add button:

Again, this leads to a form where we are asked for data such as the name of the route, the connection point where we want to send the messages, the origin of the data, and the routing query:

If we now send a message to IoT Hub from a device, we may find that within our Azure Storage account a file has been created with the received message. This is because right now, the routing query is always “true” so it will always apply, it will be when we modify this query for one that meets our needs when we will be able to apply the path correctly.

For this, we are simply going to change the “true” value of the query to an expression that returns either a “true” or a “false”. We will be able to do this using the IoT Hub query syntax.

In addition, the web interface allows us to test the queries on the spot, being able to simulate the message thanks to the test options it gives us. This is as simple as expanding the test section and adding some sample data in the corresponding section (properties, body, twin device).

Once the sample data has been added, we simply write our query and click on the “Test Path” button to validate whether the query would be activated or not: