The Azure IoT Hub is your cloud gateway for ingesting telemetry.
The IoT Hub cannot persist incoming messages so these must be forwarded to other Azure services.
Traditionally, the messages are exposed over an Event Hub-compatible endpoint.
More recent, (non-functional) IoT Hub routing is added where specific Azure services can be connected as an endpoint:
At this moment we can define:
The build-in endpoint (to keep the original way of distributing messages)
Service Bus (Topics/Queues)
Storage account, blob storage (perfect for cheap cold storage)
Lately, a native endpoint for CosmosDB has been made available.
This takes the pain away of having to set up extra resources between the IoT Hub and CosmosDB, just to transport messages from one resource to another. This is mostly done using a Stream Analytics job or custom Azure Functions.
Update: Recently, Microsoft introduced the new V2 version of their IoT Edge. This blog is referencing the former but still supported V1.
We have already made great progress understanding and using the Azure Gateway SDK.
What do we have right now? We can send telemetry data from multiple ‘offline’ devices and accept commands from the IoT Hub.
The data we send is well-formatted JSON so we are good to go.
But I am a bit worried. While reading all documentation regarding the transformation from Azure Gateway SDK towards the IoT Edge SDK, it is clear that multiple types of messages are sent to the IoT Hub. For example, I can imagine that a Stream Analytics module generates other data.
And let’s look at a more ‘close to earth’ example. The gateway itself is a potential device too! But I do not want to mix data coming from the gateway and from sensor devices.
Of course, we recently got the ability to route messages using the message sent. But what about using the properties? This keeps the message content clean.