Tous les produits
Search
Centre de documentation

IoT Platform:Guide de migration pour les scénarios types

Dernière mise à jour :Aug 10, 2026

IoT Platform prend en charge la migration des applications depuis des instances publiques vers des instances Enterprise. Les scénarios métier types suivants illustrent le processus de migration et les points clés à considérer.

Scénario 1

Scénario métier

  • Les appareils utilisent l'authentification par certificat unique par appareil et un nom de domaine d'instance publique pour se connecter à IoT Platform.

  • Les appareils utilisent des rubriques personnalisées pour signaler les données, transférées vers vos serveurs métier via d'autres produits cloud grâce à la fonctionnalité de transfert de messages.

  • Le serveur appelle l'API Pub pour envoyer des messages aux appareils.

Guide de migration

  1. Aucune modification n'est requise côté appareil.

  2. Procédez à une migration progressive pour vérifier les appareils par petits lots.

  3. Lors de la migration progressive, les configurations des produits, du transfert de messages vers les produits cloud et des abonnements côté serveur AMQP sont automatiquement migrées. Les instances Enterprise ne prenant pas en charge les abonnements côté serveur MNS, utilisez des abonnements côté serveur AMQP.

  4. Vérifiez que les appareils sont en ligne et peuvent signaler les données normalement.

  5. Vérifiez les appels à l'API Pub et assurez-vous que vos services fonctionnent comme prévu.

    L'API Pub prend en charge les ID d'instance Enterprise. Ouvrez un ticket pour demander cette fonctionnalité et réduire les modifications côté serveur.

  6. Migrez les appareils existants via une migration par lots progressifs ou une migration complète.

Scénario 2

Scénario métier

  • Les appareils utilisent l'authentification par certificat unique par appareil et un nom de domaine d'instance publique pour se connecter à IoT Platform.

  • Certains appareils se connectent à IoT Platform en tant que sous-appareils d'un appareil passerelle.

  • Les appareils utilisent des rubriques personnalisées pour signaler les données, transférées vers vos serveurs métier via d'autres produits cloud grâce à la fonctionnalité de transfert de messages.

  • Le serveur appelle l'API Pub pour envoyer des messages aux appareils.

Guide de migration

  1. Aucune modification n'est requise côté appareil. Pour les appareils connectés en tant que sous-appareils d'un appareil passerelle, veillez à ce que la topologie reste inchangée pendant la migration.

  2. Procédez à une migration progressive pour vérifier les sous-appareils par petits lots.

  3. Lors de la migration progressive, les configurations des produits, du transfert de messages vers les produits cloud et des abonnements côté serveur AMQP sont automatiquement migrées. Les instances Enterprise ne prenant pas en charge les abonnements côté serveur MNS, utilisez des abonnements côté serveur AMQP à la place.

  4. Vérifiez que les appareils sont en ligne et peuvent signaler les données normalement.

  5. Vérifiez les appels à l'API Pub et assurez-vous que vos services fonctionnent comme prévu.

    L'API Pub prend en charge les ID d'instance Enterprise. Ouvrez un ticket pour demander cette fonctionnalité et réduire les modifications côté serveur.

  6. Procédez à une migration progressive pour vérifier les appareils passerelle en suivant les étapes 2, 3, 4 et 5.

  7. Migrez les appareils existants via une migration par lots progressifs ou une migration complète.

Scénario 3

Scénario métier

  • Les appareils utilisent la pré-authentification par certificat unique par produit et un nom de domaine d'instance publique pour se connecter à IoT Platform.

  • Les appareils utilisent des rubriques personnalisées pour signaler les données, envoyées à vos serveurs métier via un abonnement côté serveur AMQP.

  • Le serveur appelle l'API Pub pour envoyer des messages aux appareils.

Guide de migration

  1. Aucune modification n'est requise côté appareil.

  2. Procédez à une migration progressive pour vérifier les informations sur les appareils.

  3. Lors de la migration progressive, les produits sont automatiquement migrés et un nouvel abonné côté serveur AMQP est généré. Mettez à jour et vérifiez l'application côté serveur.

  4. Vérifiez que les appareils sont en ligne et peuvent signaler les données normalement.

  5. Vérifiez les appels à l'API Pub et l'abonnement côté serveur AMQP, et assurez-vous que vos services fonctionnent comme prévu.

    L'API Pub prend en charge les ID d'instance Enterprise. Ouvrez un ticket pour demander cette fonctionnalité et réduire les modifications côté serveur.

  6. Une fois la vérification progressive terminée, créez directement les nouveaux appareils dans l'instance Enterprise de destination et vérifiez que vos services fonctionnent comme prévu.

  7. Migrez les appareils existants via une migration par lots progressifs ou une migration complète.

Scénario 4

Scénario métier

  • Le produit est défini à l'aide de la fonctionnalité de modèle Thing Specification Language (TSL). Les appareils utilisent l'authentification par certificat unique par appareil et un nom de domaine d'instance publique pour se connecter à IoT Platform.

  • Les appareils utilisent des rubriques Alink pour signaler les données, transférées vers vos serveurs métier via d'autres produits cloud grâce à la fonctionnalité de transfert de messages.

  • Le serveur appelle l'API InvokeThingService pour invoquer les services fournis par les appareils.

Guide de migration

  1. Aucune modification n'est requise côté appareil.

  2. Procédez à une migration progressive pour vérifier les appareils par petits lots.

  3. Lors de la migration progressive, les configurations des produits, du transfert de messages vers les produits cloud et des abonnements côté serveur AMQP sont automatiquement migrées. Les instances Enterprise ne prenant pas en charge les abonnements côté serveur MNS, utilisez des abonnements côté serveur AMQP.

  4. Vérifiez que les appareils sont en ligne et peuvent signaler les données normalement.

  5. Vérifiez les appels à l'API InvokeThingService et assurez-vous que vos services fonctionnent comme prévu.

    L'API InvokeThingService prend en charge les ID d'instance Enterprise. Ouvrez un ticket pour demander cette fonctionnalité et réduire les modifications côté serveur.

  6. Pour migrer les données historiques des propriétés, événements et services du modèle TSL, activez la synchronisation des données et attendez 7 à 30 jours.

  7. Après 7 à 30 jours, migrez les appareils existants via une migration par lots progressifs ou une migration complète. Après la migration, les appareils de l'instance Enterprise disposeront des données historiques des 7 à 30 derniers jours.