Enviado datos desde RPi hacia Azure Event Hub

Una de las principales decisiones que debemos tomar cuando desarrollamos sobre plataformas de IoT, es como poder envíar datos desde nuestra plataforma hacia un servicio que me permita procesar y disponer de la información de manera correcta.

Generalmente muchas de estas soluciones se basan en la lectura de determinados sensores y la toma de acción a partir de los valores que los mismos adquieren. Para poder capturar y disponer fuera del dispositivo de dichos valores, debemos contar con un servicio que sea escalable y con alta disponibilidad.

Para poder recibir los eventos de las lecturas de los sensores, podemos disponer del Event Hub de Azure. Este componente de plataforma como servicio fue diseñado específicamente con este fin.

Lo primero que debemos realizar es configurarlo en Azure.

image

Una vez especificado el nombre que deseamos dar y la URI del servicio, seleccionamos crear.

image

Ya que tenemos el servicio creado, dentro del dispositivo RPi podamos utilizar Node.JS para generar un proceso que envíe los datos de nuestros sensores al Event Hub.

Dentro de nuestra solución debemos agregar el paquete npm “eventhubs-js”.

image

image

Posteriormente podemos utilizar la librería desde nuestro código para poder invocar al servicio y enviar los datos al Event Hub.

image

Aquí les comparto el código de la solución Node.JS.

Patrones de Azure Service Bus y diferencias

Dentro del Service Bus de Azure hay varios patrones de mensajería que podemos utilizar. Cada una de estas modalidades resuelven distintos problemas y necesidades de conexión.

Descarga de código de ejemplo.

image

Colas

Productores: Múltiples productores pueden generar mensajes, aunque en la mayoría de los casos es uno solo.

Consumidores: Múltiples consumidores pueden leer mensajes de la cola, pero el mensaje obtenido por un consumidor no será entregado a otro, siendo único cada mensaje existente en la cola. Si un mensaje es devuelto a la cola por un consumidor, por algún caso de error, el mismo podrá ser procesado por otro consumidor o por él mismo.

SB - Queue

Si dos consumidores realizan una lectura al mismo tiempo el mensaje que recibirá el primer consumidor es distinto al mensaje que recibirá el segundo.

Dentro de la configuración para colas encontraremos las siguientes opciones:

image

Dentro de estas opciones encontraremos dos puntos bastante importantes, uno de ellos es la duración de un item en la cola, la cual determina el tiempo que puede estar no disponible un consumidor, sin tener riesgos de que perdamos el mensaje. Otra de las opciones importantes es la posibilidad de enviar los items en error a una cola de errores, sin la necesidad de que creemos esta cola e implementemos dicha lógica.

Código del productor

image

Código del consumidor

image

Tópicos

Productores: Múltiples productores pueden generar mensajes, tanto de un tipo distinto cada uno como de tópicos similares.

Consumidores: Pueden existir múltiples suscriptores para cada tópico. Lo interesante de este caso es que los mensajes pueden ser ruteados en función del contenido del mensaje.

SB - topics

Código del productor

image

image

image

Código del consumidor

image

Centro de eventos

Productores: En este escenario se pueden tener múltiples productores, generalmente diseñado para que desde algún tipo de dispositivo se envíen eventos de sensores o estado de algún dispositivo.

Consumidores: Los consumidores pueden ser tantos en paralelo como particiones hayamos configurado. Cada una de las particiones tiene un índice individual para indicar el número de mensaje que cada consumidor ha procesado hasta el momento.

SB - EH

Código del productor

image

Código del consumidor

image

image

image

image