Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Durant le cycle de vie d’une solution IoT, il est fréquent d’avoir à déplacer des appareils d’un hub IoT à un autre. Les raisons de ce déplacement peuvent inclure les scénarios suivants :
Géolocalisation et géolatence : quand un appareil change souvent d’emplacement, il doit être migré vers un hub IoT plus proche de son emplacement pour améliorer la latence du réseau.
Multi-tenant : un appareil peut être utilisé dans la même solution IoT et réassigné à un nouveau client ou à un nouveau site client. Ce nouveau client peut être serviceé à l’aide d’un autre hub IoT.
Changement de solution : un appareil est déplacé dans une nouvelle solution IoT ou une solution IoT mise à jour. Cette réaffectation peut nécessiter que l’appareil communique avec un nouveau hub IoT connecté à d’autres composants principaux.
Mise en quarantaine : ce scénario est similaire à un changement de solution. Un appareil défectueux, compromis ou obsolète peut être réaffecté à un hub IoT qui peut uniquement mettre à jour et revenir en conformité. Une fois que l’appareil fonctionne correctement, il est transféré à nouveau vers son hub principal.
La prise en charge du reprovisionnement dans le service Device Provisioning permet de gérer ces différents scénarios. Les appareils peuvent être automatiquement réaffectés à de nouveaux hubs IoT en fonction de la stratégie de reprovisionnement configurée sur l’entrée d’inscription de l’appareil.
Données d’état de l’appareil
Les données d’état de l’appareil englobent les fonctionnalités de l’appareil et du jumeau d’appareil. Ces données sont stockées dans l’instance du service Device Provisioning et dans le hub IoT auquel l’appareil est assigné.
Quand un appareil est initialement provisionné avec une instance du service Device Provisioning, les étapes suivantes sont effectuées :
L’appareil envoie une demande de provisionnement à l’instance du service Device Provisioning. L’instance du service authentifie l’identité de l’appareil par rapport à une entrée d’inscription et crée la configuration initiale des données d’état de l’appareil. L’instance du service assigne l’appareil à un hub IoT en fonction de la configuration de l’inscription, puis retourne cette assignation de hub IoT à l’appareil.
L’instance du service Device Provisioning transmet une copie des données d’état initiales de l’appareil au hub IoT assigné. L’appareil se connecte au hub IoT assigné et commence ses opérations.
Au fil du temps, les opérations d’appareil et les opérations principales peuvent mettre à jour les données d’état de l’appareil sur le hub IoT. Les données d’état initiales de l’appareil qui sont stockées dans l’instance du service Device Provisioning ne sont pas modifiées. Ces données correspondent à la configuration initiale.
Selon le scénario, à mesure qu’un appareil se déplace entre les hubs IoT, il peut également être nécessaire de migrer l’état de l’appareil mis à jour sur le hub IoT précédent vers le nouveau hub IoT. Les stratégies de reprovisionnement dans le service Device Provisioning peuvent prendre en charge cette migration.
Stratégies de réapprovisionnement
Selon le scénario, un appareil could peut envoyer une demande à une instance du service Device Provisioning au redémarrage. Il prend aussi en charge une méthode pour déclencher manuellement le provisionnement à la demande. La stratégie de reprovisionnement sur une entrée d’inscription définit de quelle manière l’instance du service Device Provisioning gère ces demandes de provisionnement. La stratégie détermine également si les données d’état de l’appareil doivent être migrées au moment du reprovisionnement. Les mêmes stratégies sont disponibles pour les inscriptions individuelles et les groupes d’inscriptions :
Réapprovisionner et migrer les données : il s’agit de la stratégie par défaut pour les nouvelles entrées d’inscription. Cette stratégie est appliquée quand des appareils associés à l’entrée d’inscription envoient une nouvelle demande (1). Selon la configuration de l’entrée d’inscription, l’appareil peut être réaffecté à un autre hub IoT. Si l’appareil change d’IoT Hubs, l’inscription de l’appareil avec le hub IoT initial est supprimée. Les informations d’état de l’appareil mises à jour de ce hub IoT initial sont migrées vers le nouveau hub IoT (2). Durant la migration, l’état de l’appareil indique Affectation.
Réapprovisionner et rétablir la configuration initiale : cette stratégie est appliquée quand des appareils associés à l’entrée d’inscription envoient une demande de nouveau approvisionnement (1). Selon la configuration de l’entrée d’inscription, l’appareil peut être réaffecté à un autre hub IoT. Si l’appareil change d’IoT Hubs, l’inscription de l’appareil avec le hub IoT initial est supprimée. Les données de configuration initiale que l’instance du service Device Provisioning a reçues au moment du provisionnement de l’appareil sont transmises au nouveau hub IoT (2). Durant la migration, l’état de l’appareil indique Affectation.
Cette stratégie est souvent utilisée dans le cadre d’une réinitialisation aux paramètres d’usine sans changer les hubs IoT.
Ne jamais réapprovisionner : l’appareil n’est jamais réassigné à un autre hub. Cette stratégie est fournie pour gérer la compatibilité descendante.
Remarque
DPS appelle toujours le webhook d’allocation personnalisé, quelle que soit la stratégie de réapprovisionnement en cas de nouvelles ReturnData pour l’appareil. Si la politique de reprovisionnement est définie sur 'ne jamais reprovisionner', le webhook est appelé, mais l’appareil ne modifie pas son hub affecté.
Pendant que vous concevez votre solution et définissez une logique de reprovisionnement, il existe quelques points à prendre en compte. Exemple :
- La fréquence à laquelle vous prévoyez que vos appareils redémarreront
- Les quotas et limites DPS
- La durée de déploiement attendue pour votre flotte (déploiement échelonné ou tous en même temps)
- La fonctionnalité de nouvelle tentative implémentée sur votre code client, telle que décrite dans les recommandations générales concernant les nouvelles tentatives dans le Centre des architectures Azure
Conseil
Nous vous recommandons de ne pas provisionner chaque redémarrage de l’appareil, car cette action peut entraîner des problèmes lors de la reprovisionnement de plusieurs milliers ou millions d’appareils à la fois. Vous devez plutôt tenter d’utiliser l’API de recherche de l’état d’inscription de l’appareil pour essayer de vous connecter avec ces informations à IoT Hub. En cas d'échec, essayez de reprovisionner, car les informations de l'IoT Hub peuvent changer. N’oubliez pas que l’interrogation de l’état d’inscription compte comme nouvelle inscription d’appareil. Vous devez donc envisager la limite d’inscription de l’appareil. Envisagez également d’implémenter une logique de nouvelle tentative appropriée, telle que l’interruption exponentielle avec la randomisation, comme décrit dans les instructions générales des nouvelles tentatives. Dans certains cas, selon les fonctionnalités de l’appareil, il est possible d’enregistrer les informations IoT Hub directement sur l’appareil pour se connecter directement à IoT Hub après la première mise en service à l’aide de DPS. Si vous choisissez d’enregistrer directement sur l’appareil, veillez à implémenter un mécanisme de secours en cas d’erreurs spécifiques à partir d’IoT Hub . Par exemple, examinez les scénarios suivants :
- Réessayez l’opération IoT Hub si le code de résultat est 429 (Trop de requêtes) ou une erreur dans la plage 5xx. Ne réessayez pas pour d’autres erreurs.
- Pour les erreurs 429, réessayez uniquement après le temps indiqué dans l'en-tête Retry-After.
- Pour les erreurs 5xx, utilisez un recul exponentiel, avec la première tentative au moins 5 secondes après la réponse.
- Lors d’erreurs autres que 429 et 5xx, réeffectuez l’inscription par le biais de DPS
- Dans l’idéal, vous devez également prendre en charge une méthode directe pour déclencher manuellement l’approvisionnement à la demande.
Nous vous recommandons également de tenir compte des limites du service lors de la planification d’activités telles que l’envoi (push) de mises à jour à votre flotte. Par exemple, la mise à jour de la flotte en une seule fois peut entraîner la réinscription de tous les appareils par le biais de DPS (ce qui pourrait facilement dépasser le quota d’inscriptions). Pour de tels scénarios, envisagez de planifier les mises à jour de l’appareil en plusieurs phases, au lieu de mettre à jour l’ensemble de votre flotte en même temps.
Gestion de la compatibilité descendante
Avant septembre 2018, les assignations d’appareils à des hubs IoT avaient un comportement fixe. Quand un appareil suivait un processus de provisionnement, il était seulement réassigné au même hub IoT.
Pour les solutions qui dépendent de ce comportement, le service d’approvisionnement inclut la compatibilité descendante. Ce comportement est actuellement maintenu pour les appareils selon les critères suivants :
Les appareils se connectent avec une version d’API antérieure à la mise à disposition de la prise en charge native du reprovisionnement dans le service Device Provisioning. Reportez-vous au tableau d’API suivant.
Il n’existe pas de stratégie de reprovisionnement configurée dans l’entrée d’inscription des appareils.
Cette compatibilité garantit que les appareils précédemment déployés conservent le même comportement que celui qu’ils avaient lors des tests initiaux. Pour conserver le comportement initial, ne configurez pas de stratégie de reprovisionnement pour ces inscriptions. Si une stratégie de reprovisionnement est configurée, elle est prioritaire sur le comportement. Les clients peuvent alors mettre à jour le comportement de l’appareil sans avoir à réinitialiser ce dernier.
L’organigramme suivant aide à illustrer le processus du comportement :
Le tableau suivant répertorie les versions d’API antérieures à la mise à disposition de la prise en charge native du reprovisionnement dans le service Device Provisioning :
| API REST | Kit de développement logiciel (SDK) C | Kit de développement logiciel (SDK) Python | SDK de Node | Kit de développement logiciel (SDK) Java | Kit de développement logiciel (SDK) .NET |
|---|---|---|---|---|---|
| 2018-04-01 et versions antérieures | 1.2.8 et versions antérieures | 1.4.2 et versions antérieures | 1.7.3 ou version antérieure | 1.13.0 ou version antérieure | 1.1.0 ou version antérieure |
Remarque
Ces valeurs et ces liens sont susceptibles de changer. Les SDK et API Azure IoT sont versionnés pour garantir que les applications et les services continuent de fonctionner à mesure que les produits et LES API évoluent. Nous vous recommandons de vérifier les dernières versions des kits SDK et API Azure IoT dans la documentation de référence de ces KITS sdk et API. Par exemple, la dernière version de l’API REST du service Azure IoT Hub Device Provisioning est 2021-10-01.