Usare hub IoT routing dei messaggi per inviare messaggi da dispositivo a cloud ai servizi di Azure

  • Articolo

Il routing dei messaggi consente di inviare messaggi dai dispositivi ai servizi cloud in modo automatizzato, scalabile e affidabile. Il routing dei messaggi può essere usato per:

  • Inviare messaggi ed eventi di telemetria del dispositivo all'endpoint predefinito e agli endpoint personalizzati. Gli eventi che possono essere indirizzati includono eventi relativi al ciclo di vita del dispositivo, eventi di modifica del dispositivo gemello, eventi di modifica del dispositivo digitale ed eventi dello stato della connessione del dispositivo.

  • Filtrare i dati prima di instradarli applicando query avanzate. Il routing dei messaggi consente di eseguire query sulle proprietà dei messaggi e sul corpo del messaggio, nonché sui tag e sulle proprietà del dispositivo gemello. Per altre informazioni, vedere Query nel routing dei messaggi.

L'hub IoT definisce un formato comune per tutta la messaggistica da dispositivo a cloud per l'interoperabilità tra i protocolli. Per altre informazioni, vedere Creare e leggere messaggi dell'hub IoT.

Nota

Alcune delle funzionalità indicate in questo articolo, come la messaggistica da cloud a dispositivo, i dispositivi gemelli e la gestione dei dispositivi, sono disponibili solo nel livello Standard dell'hub IoT. Per altre informazioni sui livelli di hub IoT basic e standard/gratuiti, vedere Scegliere il livello di hub IoT appropriato per la soluzione.

Endpoint di routing

Ogni hub IoT ha un endpoint di routing predefinito denominato messages/events compatibile con Hub eventi. È anche possibile creare endpoint personalizzati che puntano ad altri servizi nella Sottoscrizione di Azure.

hub IoT supporta attualmente gli endpoint seguenti per il routing dei messaggi:

  • Endpoint predefinito
  • Contenitori di archiviazione
  • Code del bus di servizio
  • Argomenti del bus di servizio
  • Hub eventi
  • Cosmos DB

Per altre informazioni su ognuno di questi endpoint, vedere hub IoT endpoint.

Ogni messaggio viene indirizzato a tutti gli endpoint di cui corrisponde il routing delle query, il che significa che un messaggio può essere indirizzato a più endpoint. Tuttavia, se un messaggio corrisponde a più route che puntano allo stesso endpoint, hub IoT recapita il messaggio all'endpoint una sola volta.

Hub IoT richiede l'accesso in scrittura a questi endpoint di servizio affinché il routing dei messaggi funzioni correttamente. Se si configurano gli endpoint tramite il Portale di Azure, verranno aggiunte le autorizzazioni necessarie. Se si configurano gli endpoint usando PowerShell o l'interfaccia della riga di comando di Azure, è necessario fornire l'autorizzazione di accesso in scrittura.

Per informazioni su come creare endpoint, vedere gli articoli seguenti:

Assicurarsi di configurare i servizi per supportare la velocità effettiva prevista. Ad esempio, se si usano Hub eventi come endpoint personalizzato, è necessario configurare le unità elaborate per tale hub eventi in modo che possa gestire l'ingresso degli eventi che si prevede di inviare tramite hub IoT routing dei messaggi. In modo analogo, quando si usa una coda di Bus di servizio come endpoint, è necessario configurarne la dimensione massima per garantire che la coda possa contenere tutti i dati in ingresso, fino a quando non vengono eliminati dai consumer. Durante la prima configurazione della soluzione IoT, potrebbe essere necessario monitorare gli altri endpoint e quindi apportare le modifiche necessarie per il carico effettivo.

Se l'endpoint personalizzato dispone di configurazioni del firewall, provare a usare l'eccezione di prima parte attendibile di Microsoft.

Eseguire il routing a un endpoint in un'altra sottoscrizione

Se la risorsa endpoint si trova in una sottoscrizione diversa rispetto all'hub IoT, è necessario configurare l'hub IoT come servizio Microsoft attendibile prima di creare un endpoint personalizzato. Quando si crea l'endpoint personalizzato, impostare il tipo di Autenticazione sull'identità assegnata dall'utente.

Per altre informazioni, vedere Connettività in uscita dall'hub IoT ad altre risorse di Azure.

Query di routing

hub IoT routing dei messaggi offre una funzionalità di query per filtrare i dati prima di instradarli agli endpoint. Ogni query di routing configurata ha le proprietà seguenti:

Proprietà Descrizione
Nome Il nome univoco che identifica la query.
Origine L'origine del flusso dati su cui intervenire. Ad esempio, i dati di telemetria del dispositivo.
Condizione Espressione di query per la query di routing eseguita sulle proprietà dell'applicazione del messaggio, proprietà di sistema, corpo del messaggio, tag del dispositivo gemello e proprietà del dispositivo gemello per determinare se si tratta di una corrispondenza per l'endpoint.
Endpoint Il nome dell'endpoint in cui l'hub IoT invia i messaggi corrispondenti alla query. È consigliabile scegliere un endpoint nella stessa area dell'hub IoT.

Un singolo messaggio può corrispondere alla condizione di più query di routing. In questo caso, l'hub IoT invia il messaggio all'endpoint associato a ciascuna query associata. hub IoT anche deduplicare automaticamente il recapito dei messaggi, quindi se un messaggio corrisponde a più query con la stessa destinazione, viene scritto una sola volta in tale destinazione.

Per altre informazioni, vedere hub IoT sintassi delle query di routing dei messaggi.

Leggere i dati indirizzati

Usare gli articoli seguenti per informazioni su come leggere i messaggi da un endpoint.

Route di fallback

La route di fallback invia tutti i messaggi che non soddisfano le condizioni di query in nessuna delle route esistenti all'endpoint predefinito (messaggi/eventi), compatibile con Hub eventi. Se il routing dei messaggi è abilitato, è possibile abilitare la funzionalità di route di fallback. Dopo aver creato una route, i dati smette di passare all'endpoint predefinito, a meno che non venga creata una route a tale endpoint. Se non sono presenti route all'endpoint predefinito e viene abilitata una route di fallback, solo i messaggi che non corrispondono ad alcuna condizione di query sulle route verranno inviati all'endpoint predefinito. Anche se tutte le route esistenti vengono eliminate, la funzionalità di route di fallback deve essere abilitata per ricevere tutti i dati nell'endpoint predefinito.

È possibile abilitare o disabilitare la route di fallback nel portale di Azure nel pannello Routing messaggi. È anche possibile usare Azure Resource Manager per FallbackRouteProperties in modo da usare un endpoint personalizzato per la route di fallback.

Eventi non di telemetria

Oltre ai dati di telemetria del dispositivo, il routing dei messaggi consente anche l'invio di eventi non telemetrici, tra cui:

  • Eventi di modifica del dispositivo gemello
  • Eventi relativi al ciclo di vita del dispositivo
  • Eventi relativi al ciclo di vita dei processo del dispositivo
  • Eventi di modifica del gemello digitale
  • Eventi dello stato della connessione del dispositivo

Ad esempio, se viene creata una route con l'origine dati impostata su Eventi di modifica dispositivo gemello, hub IoT invia messaggi all'endpoint che contengono la modifica nel dispositivo gemello. Analogamente, se viene creata una route con l'origine dati impostata su Eventi del ciclo di vita del dispositivo, hub IoT invia un messaggio che indica se il dispositivo o il modulo è stato eliminato o creato. Per altre informazioni sugli eventi del ciclo di vita dei dispositivi, vedere Notifiche relative al ciclo di vita dei dispositivi e ai moduli.

Quando si usa Azure Plug and Play IoT, uno sviluppatore può creare route con l'origine dati impostata su Eventi di modifica di Gemelli digitali e hub IoT invia messaggi ogni volta che viene impostata o modificata una proprietà del gemello digitale, viene sostituito un gemello digitale o quando si verifica un evento di modifica per il dispositivo gemello sottostante. Infine, se viene creata una route con origine dati impostata su Device Connessione ion State Events, hub IoT invia un messaggio che indica se il dispositivo è stato connesso o disconnesso.

L'hub IoT si integra anche con Griglia di eventi di Azure per pubblicare gli eventi dei dispositivi supportando le integrazioni in tempo reale e l'automazione dei flussi di lavoro in base a questi eventi. Vedere le principali differenze tra il routing dei messaggi e Griglia di eventi per determinare la soluzione ottimale per il proprio scenario.

Limitazioni per gli eventi dello stato della connessione del dispositivo

Gli eventi dello stato della connessione del dispositivo sono disponibili per i dispositivi che si connettono usando il protocollo MQTT o AMQP, oppure usando uno di questi protocolli su WebSockets. Le richieste effettuate solo con HTTPS non attiveranno le notifiche sullo stato della connessione del dispositivo. Per hub IoT avviare l'invio di eventi di stato della connessione del dispositivo, dopo l'apertura di una connessione un dispositivo deve chiamare l'operazione di ricezione di messaggi da cloud a dispositivo o l'operazione di telemetria da dispositivo a cloud. Al di fuori degli SDK di Azure IoT, in MQTT queste operazioni equivalgono alle operazioni SUBSCRIBE o PUBLISH negli argomenti di messaggistica appropriati. Nel protocollo AMQP queste operazioni equivalgono al collegamento o al trasferimento di un messaggio nei percorsi del collegamento appropriati. Per altre informazioni, vedere gli articoli seguenti:

hub IoT non segnala ogni singolo evento di connessione e disconnessione, ma pubblica invece lo stato di connessione corrente acquisito in uno snapshot periodico di 60 secondi. La ricezione dello stesso evento dello stato della connessione con numeri di sequenza diversi o di eventi dello stato della connessione diversi significa che si è verificato un cambiamento nello stato della connessione del dispositivo durante la finestra di 60 secondi.

Testare le route

Quando si crea una nuova route o si modifica una route esistente, è consigliabile testare la query di route con un messaggio di esempio. È possibile testare singole route o testarle tutte contemporaneamente. Nessuno messaggio viene indirizzato agli endpoint durante il test. Per i test è possibile usare il portale di Azure, Azure Resource Manager, Azure PowerShell e l'interfaccia della riga di comando di Azure. I risultati consentono di identificare se il messaggio di esempio corrisponde o meno alla query, oppure se il test non è stato eseguito perché il messaggio di esempio o la sintassi della query non sono corretti. Per altre informazioni, vedere Testare la route e Testare tutte le route.

Latenza

Quando si instradano messaggi di telemetria da dispositivo a cloud, si verifica un lieve aumento della latenza end-to-end dopo la creazione della prima route.

Nella maggior parte dei casi, l'aumento medio della latenza è inferiore a 500 millisecondi. Tuttavia, la latenza che si verifica può variare e può essere superiore a seconda del livello dell'hub IoT e dell'architettura della soluzione. È possibile monitorare la latenza usando routing: latenza dei messaggi per messaggi/eventi o d2c.endpoints.latency.builtIn.events hub IoT metriche. La creazione o l'eliminazione di qualsiasi route dopo la prima non ha alcun impatto sulla latenza end-to-end.

Monitorare e risolvere i problemi

L'hub IoT prevede diverse metriche correlate al routing e agli endpoint per offrire una panoramica dell'integrità dell'hub e dei messaggi inviati. È anche possibile tenere traccia degli errori che si verificano durante la valutazione di una query di routing e dell'integrità dell'endpoint percepiti da hub IoT con la categoria route nei log delle risorse hub IoT. Per altre informazioni sull'uso di metriche e log delle risorse con hub IoT, vedere Monitoraggio hub IoT di Azure.

È possibile usare l'API REST Get Endpoint Health (Ottieni integrità endpoint) per ottenere lo stato di integrità degli endpoint.

Usare la guida alla risoluzione dei problemi per il routing per altri dettagli e il supporto per la risoluzione dei problemi di routing.