Partager via

Générer des modules WASM pour les flux de données dans VS Code

La fonctionnalité de traitement des données WebAssembly (WASM) personnalisée dans Azure IoT Operations permet le traitement des données de télémétrie en temps réel au sein de votre cluster Azure IoT Operations. En déployant des modules WASM personnalisés, vous pouvez définir et exécuter des transformations de données dans le cadre de votre graphe de flux de données ou du connecteur HTTP/REST.

Cet article explique comment utiliser l’extension AZURE IoT Operations Data Flow VS Code pour développer, tester et déboguer vos modules WASM localement avant de les déployer sur votre cluster Azure IoT Operations. Vous allez apprendre à :

  • Exécutez une application de graphe localement en exécutant un graphe prédéfini avec des exemples de données pour comprendre le flux de travail de base.
  • Créez des modules WASM personnalisés en créant de nouveaux opérateurs dans Python et Rust avec des fonctionnalités de mappage et de filtre.
  • Utilisez le magasin d’états pour maintenir l’état dans le traitement des messages.
  • Utilisez la validation du Registre de schémas pour valider les formats de message à l’aide de schémas JSON avant le traitement.
  • Déboguer des modules WASM à l’aide de points d’arrêt et de débogage étape par étape dans le cadre du développement local.

L’extension est prise en charge sur les plateformes suivantes :

  • Linux
  • Sous-système Windows pour Linux (WSL)
  • Fenêtres

Pour en savoir plus sur les graphiques et WASM dans Azure IoT Operations, consultez :

Prerequisites

Environnement de développement :

Images Docker :

docker pull mcr.microsoft.com/azureiotoperations/processor-app:1.1.4
docker tag mcr.microsoft.com/azureiotoperations/processor-app:1.1.4 host-app

docker pull mcr.microsoft.com/azureiotoperations/devx-runtime:0.1.8
docker tag mcr.microsoft.com/azureiotoperations/devx-runtime:0.1.8 devx

docker pull mcr.microsoft.com/azureiotoperations/statestore-cli:0.0.2
docker tag mcr.microsoft.com/azureiotoperations/statestore-cli:0.0.2 statestore-cli

docker pull eclipse-mosquitto

Utiliser l’extension VS Code pour exécuter une application graphe localement

Cet exemple utilise un exemple d’espace de travail qui contient toutes les ressources nécessaires pour générer et exécuter une application graphe localement à l’aide de l’extension VS Code.

Ouvrir l’exemple d’espace de travail dans VS Code

Clonez le référentiel Explorer les opérations IoT si vous ne l’avez pas déjà fait.

Ouvrez le samples/wasm dossier dans Visual Studio Code en sélectionnant Fichier > Ouvrir le dossier et en accédant au samples/wasm dossier.

Générer les opérateurs

Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher des opérations Azure IoT : générer tous les opérateurs de flux de données. Sélectionnez la mise en production en tant que mode de génération.

Cette commande génère tous les opérateurs de l’espace de travail et crée des .wasm fichiers dans le operators dossier. Vous utilisez les fichiers .wasm pour exécuter l’application graphe localement.

Exécuter l’application graphe localement

Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher azure IoT Operations : Exécuter Application Graph. Sélectionnez la mise en production comme mode d’exécution. Cette commande exécute localement l’application graphe à l’aide de l’environnement d’exécution local avec le fichier graph.dataflow.yaml de l’espace de travail.

Il lit également à partir de hostapp.env.list pour définir la variable TK_CONFIGURATION_PARAMETERS d’environnement pour les paramètres de configuration de l’opérateur de flux de données.

Lorsque vous êtes invité à entrer des données d’entrée, sélectionnez le data-and-images dossier dans l’espace de travail. Ce dossier contient les fichiers de données d’entrée de l’application graphique, y compris les données de température et d’humidité, ainsi que certaines images du module d’instantané.

Attendez de voir une notification VS Code indiquant que les journaux sont prêts : Log files for the run can be found at ...\wasm\data-and-images\output\logs.

La sortie se trouve dans le output dossier sous le data-and-images dossier. Vous pouvez ouvrir le output dossier dans l’espace de travail pour afficher les fichiers de sortie. Le .txt fichier avec la date et l’heure du nom de fichier contient les données traitées, et il ressemble à l’exemple suivant :

{"tst":"2025-09-19T04:19:13.530381+0000","topic":"sensors","qos":0,"retain":0,"payloadlen":312,"properties":{"payload-format-indicator":1,"message-expiry-interval":10,"correlation-data":"...","user-properties":{"__ts":"001758255553528:00000:...","__protVer":"1.0","__srcId":"mqtt-source"},"content-type":"application/json"},"payload":{"temperature":[{"count":2,"max":653.888888888889,"min":204.44444444444449,"average":429.16666666666669,"last":204.44444444444449,"unit":"C","overtemp":true}],"humidity":[{"count":3,"max":85,"min":45,"average":69.666666666666671,"last":79}],"object":[{"result":"notebook, notebook computer; sliding door"}]}}

La sortie indique que l’application de graphique a traité les données d’entrée et généré la sortie. La sortie inclut les données de température et d’humidité, ainsi que les objets détectés dans les images.

Créer un graphe avec des modules WASM personnalisés

Ce scénario vous montre comment créer une application de graphe avec des modules WASM personnalisés. L’application de graphe se compose de deux opérateurs : un map opérateur qui convertit les valeurs de température de Fahrenheit en Celsius et un filter opérateur qui filtre les messages avec des valeurs de température supérieures à 500 °C.

Au lieu d’utiliser un exemple d’espace de travail existant, vous créez un espace de travail à partir de zéro. Ce processus vous permet de découvrir comment créer une application de graphe et programmer les opérateurs en Python et Rust.

Contrainte de dénomination d’opérateur

Actuellement, n’utilisez pas de traits d’union (-) ou de traits de soulignement (_) dans les noms d’opérateurs. L’extension VS Code applique cette exigence, mais si vous créez ou renommez manuellement des modules, cela provoque des problèmes. Utilisez des noms alphanumériques simples pour les modules tels que filter, , mapstateenrichou schemafilter.

Créer un projet d’application graphe en Python

Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes VS Code et rechercher les opérations Azure IoT : Créez une application de flux de données :

  1. Pour le dossier, sélectionnez un dossier dans lequel vous souhaitez créer le projet. Vous pouvez créer un dossier pour ce projet.
  2. Entrez my-graph comme nom.
  3. Sélectionnez Python comme langage.
  4. Sélectionnez Mapper comme type.
  5. Entrez map comme nom.

Vous disposez maintenant d’un nouvel espace de travail VS Code avec la structure de projet de base et les fichiers de démarrage. Les fichiers de démarrage incluent le fichier graph.dataflow.yaml et le code source du modèle d’opérateur de mappage.

Important

Pour utiliser un module Python dans une instance Azure IoT Operations déployée, vous devez déployer l’instance avec le profil de mémoire broker défini sur Moyen ou Élevé. Si vous définissez le profil de mémoire sur Low ou Tiny, l’instance ne peut pas extraire le module Python.

Ajouter du code Python pour le module d’opérateur de carte

Ouvrez le fichier et remplacez le operators/map/map.py contenu par le code suivant pour convertir une valeur de température entrante de Fahrenheit en Celsius :

import json
from map_impl import exports
from map_impl import imports
from map_impl.imports import types

class Map(exports.Map):
    def init(self, configuration) -> bool:
        imports.logger.log(imports.logger.Level.INFO, "module4/map", "Init invoked")
        return True

    def process(self, message: types.DataModel) -> types.DataModel:
        # TODO: implement custom logic for map operator
        imports.logger.log(imports.logger.Level.INFO, "module4/map", "processing from python")

        # Ensure the input is of the expected type
        if not isinstance(message, types.DataModel_Message):
            raise ValueError("Unexpected input type: Expected DataModel_Message")

        # Extract and decode the payload
        payload_variant = message.value.payload
        if isinstance(payload_variant, types.BufferOrBytes_Buffer):
            # It's a Buffer handle - read from host
            imports.logger.log(imports.logger.Level.INFO, "module4/map", "Reading payload from Buffer")
            payload = payload_variant.value.read()
        elif isinstance(payload_variant, types.BufferOrBytes_Bytes):
            # It's already bytes
            imports.logger.log(imports.logger.Level.INFO, "module4/map", "Reading payload from Bytes")
            payload = payload_variant.value
        else:
            raise ValueError("Unexpected payload type")

        decoded = payload.decode("utf-8")

        # Parse the JSON data
        json_data = json.loads(decoded)

        # Check and update the temperature value
        if "temperature" in json_data and "value" in json_data["temperature"]:
            temp_f = json_data["temperature"]["value"]
            if isinstance(temp_f, int):
                # Convert Fahrenheit to Celsius
                temp_c = round((temp_f - 32) * 5.0 / 9.0)

                # Update the JSON data
                json_data["temperature"]["value"] = temp_c
                json_data["temperature"]["unit"] = "C"

                # Serialize the updated JSON back to bytes
                updated_payload = json.dumps(json_data).encode("utf-8")

                # Update the message payload
                message.value.payload = types.BufferOrBytes_Bytes(value=updated_payload)

        return message

Vérifiez que Docker est en cours d’exécution. Ensuite, appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher les opérations Azure IoT : générez tous les opérateurs de flux de données. Créez un module de mise en production .

Le processus de génération place le map.wasm fichier de l’opérateur map dans le operators/map/bin/release dossier.

Ajouter du code Rust pour le module d’opérateur de filtre

Créez un opérateur en appuyant Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher azure IoT Operations : Créer un opérateur de flux de données :

  1. Sélectionnez Rust comme langue.
  2. Sélectionnez Filtrer comme type d’opérateur.
  3. Entrez filter comme nom.

Ouvrez le operators/filter/src/lib.rs fichier et remplacez le contenu par le code suivant pour filtrer les valeurs où la température est supérieure à 500 °C :

mod filter_operator {
    use wasm_graph_sdk::macros::filter_operator;
    use serde_json::Value;

    fn filter_init(_configuration: ModuleConfiguration) -> bool {
        // Add code here to process the module init properties and module schemas from the configuration

        true
    }

    #[filter_operator(init = "filter_init")]
    fn filter(input: DataModel) -> Result<bool, Error> {

        // Extract payload from input to process
        let payload = match input {
            DataModel::Message(Message {
                payload: BufferOrBytes::Buffer(buffer),
                ..
            }) => buffer.read(),
            DataModel::Message(Message {
                payload: BufferOrBytes::Bytes(bytes),
                ..
            }) => bytes,
            _ => return Err(Error { message: "Unexpected input type".to_string() }),
        };

        // ... perform filtering logic here and return boolean
        if let Ok(payload_str) = std::str::from_utf8(&payload) {
            if let Ok(json) = serde_json::from_str::<Value>(payload_str) {
                if let Some(temp_c) = json["temperature"]["value"].as_i64() {
                    // Return true if temperature is above 500°C
                    return Ok(temp_c > 500);
                }
            }
        }

        Ok(false)
   }
}

Ouvrez le operators/filter/Cargo.toml fichier et ajoutez les dépendances suivantes :

[dependencies]
# ...
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

Vérifiez que Docker est en cours d’exécution. Ensuite, appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher les opérations Azure IoT : générez tous les opérateurs de flux de données. Créez un module de mise en production .

Le processus de génération place le filter.wasm fichier de l’opérateur filter dans le operators/filter/bin/release dossier.

Exécuter l’application graphe localement avec des exemples de données

Ouvrez le fichier graph.dataflow.yaml et remplacez son contenu par le code suivant :

metadata:
    $schema: "https://www.schemastore.org/aio-wasm-graph-config-1.0.0.json"
    name: "Temperature Monitoring"
    description: "A graph that converts temperature from Fahrenheit to Celsius, if temperature is above 500°C, then sends the processed data to the sink."
    version: "1.0.0"
    vendor: "Microsoft"
moduleRequirements:
    apiVersion: "1.1.0"
    runtimeVersion: "1.1.0"
operations:
  - operationType: source
    name: source
  - operationType: map
    name: map
    module: map
  - operationType: filter
    name: filter
    module: filter
  - operationType: sink
    name: sink
connections:
  - from:
      name: source
    to:
      name: map
  - from:
      name: map
    to:
      name: filter
  - from:
      name: filter
    to:
      name: sink

Copiez le data dossier qui contient les exemples de données du référentiel explore-iot-operations\samples\wasm\data d’exemples clonés dans l’espace de travail actuel. Le data dossier contient trois fichiers JSON avec des exemples de données de température d’entrée.

Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher des opérations Azure IoT : Exécuter Application Graph :

  1. Sélectionnez le graph.dataflow.yaml fichier de graphique.
  2. Sélectionnez la mise en production comme mode d’exécution.
  3. Sélectionnez le data dossier que vous avez copié dans l’espace de travail.

Le conteneur DevX démarre pour exécuter le graphique. Le résultat traité est enregistré dans le data/output dossier.

Pour savoir comment déployer vos modules ET graphiques WASM personnalisés sur votre instance Azure IoT Operations, consultez Déployer des modules WASM et des graphiques de flux de données.

Prise en charge du magasin d’état pour les opérateurs WASM

Cet exemple montre comment utiliser le stockage d’états avec des opérateurs WASM. Le magasin d’états permet aux opérateurs de conserver et de récupérer des données dans le traitement des messages et d’activer les opérations avec état dans vos graphiques de flux de données.

Ouvrir l’espace de travail d’exemple du magasin d’état

Clonez le référentiel Explorer les opérations IoT si vous ne l’avez pas déjà fait.

Ouvrez le samples/wasm/statestore-scenario dossier dans Visual Studio Code en sélectionnant Fichier > Ouvrir le dossier et en accédant au samples/wasm/statestore-scenario dossier. Ce dossier contient les ressources suivantes :

  • graph.dataflow.yaml - Configuration du graphe de flux de données avec un opérateur doté d’un magasin d’état activé.
  • statestore.json - Configuration du magasin d’état avec des paires clé-valeur.
  • data/ - Exemples de données d’entrée pour les tests.
  • operators/ - Code source pour les opérateurs otel-enrich et filter.

Configurer le magasin d’états

  1. Ouvrez le statestore.json fichier pour afficher la configuration actuelle du magasin d’états.

  2. Vous pouvez modifier les valeurs de factoryId ou machineId pour les tests. Le paramètre d’enrichissement fait référence à ces clés.

  3. Ouvrez graph.dataflow.yaml et passez en revue la configuration de l’enrichissement. Les sections significatives de ce fichier sont présentées dans l’extrait de code suivant :

    moduleConfigurations:
  - name: module-otel-enrich/map
    parameters:
      enrichKeys:
        name: enrichKeys
        description: Comma separated list of DSS keys which will be fetched and added as attributes
        default: factoryId,machineId
operations:
  - operationType: "source"
    name: "source"
  - operationType: "map"
    name: "module-otel-enrich/map"
    module: "otel-enrich"
  - operationType: "sink"
    name: "sink"

    La valeur par défaut du paramètre enrichKeys (factoryId,machineId) détermine les clés récupérées du magasin d’état et ajoutées comme attributs.

  4. Vérifiez que chaque clé répertoriée enrichKeys existe dans statestore.json. Si vous ajoutez ou supprimez des clés dans statestore.json, mettez à jour la valeur de default ou remplacez-la à l’aide de la variable d'environnement TK_CONFIGURATION_PARAMETERS.

Mettre à jour les données de test (facultatif)

Vous pouvez modifier les données de test dans le data/ dossier pour tester différentes valeurs d’entrée. Les exemples de données incluent des lectures de température.

Construire et exécuter le scénario de magasin de l'état

  1. Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher des opérations Azure IoT : générer tous les opérateurs de flux de données.

  2. Sélectionnez la mise en production en tant que mode de génération. Attendez la fin de la génération.

  3. Appuyez Ctrl+Shift+P de nouveau et recherchez Azure IoT Operations : Exécuter Application Graph.

  4. Sélectionnez la mise en production comme mode d’exécution.

  5. Sélectionnez le data dossier dans votre espace de travail VS Code pour vos données d’entrée. Le conteneur DevX démarre pour exécuter le graphique avec l’exemple d’entrée.

Vérifier la fonctionnalité de magasin d’état

Une fois l’exécution du graphique terminée :

  1. Affichez les résultats dans le data/output/ dossier.

  2. Ouvrez le fichier généré .txt pour afficher les données traitées. La section user properties des messages de sortie inclut les valeurs factoryId et machineId récupérées à partir du magasin d’états.

  3. Vérifiez les journaux dans data/output/logs/host-app.log pour confirmer que l’opérateur otel-enrich a récupéré des valeurs à partir du magasin d’état et les a ajoutées comme propriétés utilisateur aux messages.

Prise en charge du registre de schémas pour les modules WASM

Cet exemple montre comment utiliser le registre de schémas avec des modules WASM. Le registre de schémas vous permet de valider les formats de message et de garantir la cohérence des données dans le traitement de votre flux de données.

Ouvrir l’exemple d’espace de travail du Registre de schémas

Clonez le référentiel Explorer les opérations IoT si vous ne l’avez pas déjà fait.

Ouvrez le samples/wasm/schema-registry-scenario dossier dans Visual Studio Code en sélectionnant Fichier > Ouvrir le dossier et en accédant au samples/wasm/schema-registry-scenario dossier. Ce dossier contient les ressources suivantes :

  • graph.dataflow.yaml - Configuration du graphe de flux de données.
  • tk_schema_config.json - Schéma JSON que l’application hôte utilise localement pour valider les charges utiles de message entrantes avant d’atteindre les opérateurs en aval. Conservez ce fichier synchronisé avec tout schéma que vous publiez dans votre environnement Microsoft Azure.
  • data/ - Exemples de données d’entrée avec différents formats de message à tester.
  • operators/filter/ - Code source de l’opérateur de filtre.
  • (Facultatif) hostapp.env.list - L’extension VS Code génère automatiquement une configuration à l’exécution en ajoutant TK_SCHEMA_CONFIG_PATH=tk_schema_config.json. Si vous fournissez votre propre fichier de schéma, assurez-vous que la variable pointe vers celle-ci.

Comprendre la configuration du schéma

Ouvrez le tk_schema_config.json fichier pour afficher la définition du schéma :

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "humidity": {
      "type": "integer"
    },
    "temperature": {
      "type": "number"
    }
  }
}

Ce schéma définit un objet JSON de niveau supérieur qui peut contenir deux propriétés numériques : humidity (entier) et temperature (nombre). Ajoutez un tableau "required": ["humidity", "temperature"] si vous devez les rendre obligatoires, ou élargissez la section properties à mesure que votre format de charge évolue.

Les limitations suivantes s’appliquent au fichier de schéma local (tk_schema_config.json). Fichier de schéma :

  • Utilise la syntaxe standard du projet JSON Schema version 07, le même projet pris en charge par le registre de schémas d'Azure IoT Operations.
  • Est fonctionnellement le même contenu que celui que vous inscrivez dans le registre de schémas cloud. Vous pouvez copier et coller entre les deux pour rester cohérent.
  • Est référencé par l’application hôte via la variable TK_SCHEMA_CONFIG_PATHd’environnement.

Actuellement, les limitations suivantes s’appliquent dans le runtime de développement local :

  • Un seul fichier de configuration de schéma est chargé. Aucune inclusion multi-fichiers ni analyse de répertoire n’est prise en charge.
  • $ref vers les fichiers externes ou les URL n’est pas pris en charge localement. Maintenez le schéma indépendant. Vous pouvez utiliser des références de pointeur JSON internes comme {"$ref":"#/components/..."}.
  • Les mots clés draft-07 couramment utilisés comme type, properties, required, enum, minimum, maximum, allOf, anyOf, oneOf, not et items fonctionnent tous. Le validateur sous-jacent peut ignorer les fonctionnalités moins courantes ou avancées comme contentEncoding et contentMediaType.
  • Conservez la taille de vos schémas à moins de ~1 Mo pour les démarrages à froid rapides.
  • Les stratégies d’évolution de version et de schéma ne sont pas appliquées localement. Vous êtes responsable de rester aligné sur le registre cloud.

Si vous vous appuyez sur des constructions avancées qui échouent localement, validez le même schéma sur le registre cloud après la publication pour garantir la parité.

Pour plus d’informations, consultez les concepts du Registre de schémas Azure IoT Operations.

Passer en revue les données de test

Le data/ dossier contient trois fichiers de test :

  • temperature_humidity_payload_1.json - Contient à la fois les données de température et d’humidité et passe la validation. Toutefois, la valeur d’humidité n’est pas un entier spécifié dans le schéma, de sorte que les données sont filtrées.
  • temperature_humidity_payload_2.json - Contient uniquement les données d’humidité et est filtré.
  • temperature_humidity_payload_3.json - Contient à la fois les données de température et d’humidité et passe la validation.

Générer et exécuter le scénario de Registre de schémas

  1. Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher des opérations Azure IoT : générer tous les opérateurs de flux de données.

  2. Sélectionnez la mise en production en tant que mode de génération. Attendez la fin de la génération.

  3. Appuyez Ctrl+Shift+P de nouveau et recherchez Azure IoT Operations : Exécuter Application Graph.

  4. Sélectionnez le graph.dataflow.yaml fichier de graphique.

  5. Sélectionnez la mise en production comme mode d’exécution.

  6. Sélectionnez le data dossier dans votre espace de travail VS Code pour vos données d’entrée. Le conteneur DevX démarre pour exécuter le graphique avec l’exemple d’entrée.

Vérifier la validation du schéma

Une fois le traitement terminé :

  1. Vérifiez le dossier data/output/ contenant les résultats.

  2. La sortie contient uniquement la version traitée du temperature_humidity_payload_3.json message, car elle est conforme au schéma.

  3. Le data/output/logs/host-app.log fichier contient des entrées de journal indiquant quels messages sont acceptés ou rejetés en fonction de la validation du schéma.

Cet exemple montre comment le registre de schéma valide les messages entrants et filtre les messages qui ne sont pas conformes au schéma défini.

Déboguer des modules WASM à l’aide de l’extension VS Code

Cet exemple montre comment déboguer localement des modules WASM à l’aide de points d’arrêt et du débogueur intégré dans VS Code.

Prerequisites

Terminez l’exemple de la prise en charge du registre de schéma pour les modules WASM afin de configurer l’espace de travail d’exemple.

Configurer le débogage

  1. Ouvrez le fichier operators/filter/src/lib.rs dans l’espace schema-registry-scenario de travail.

  2. Recherchez la filter fonction et définissez un point d’arrêt en cliquant dans la marge en regard du numéro de ligne ou en appuyant F9sur .

    fn filter(message: DataModel) -> Result<bool, Error> {
    let DataModel::Message(message) = input else {
        return Err(Error {message: "Unexpected input type.".to_string()});
    };
    // ... rest of function
}

Compilation pour le débogage

  1. Appuyez Ctrl+Shift+P pour ouvrir la palette de commandes et rechercher des opérations Azure IoT : générer tous les opérateurs de flux de données.

  2. Sélectionnez déboguer comme mode de compilation. Attendez la fin de la génération.

Exécuter avec débogage activé

  1. Appuyez sur Ctrl+Shift+P et recherchez Opérations Azure IoT : exécuter Application Graph.

  2. Sélectionnez le lldb-debug.graph.dataflow.yaml fichier de graphique.

  3. Sélectionnez déboguer comme mode d’exécution.

  4. Sélectionnez le data dossier dans votre espace de travail VS Code pour vos données d’entrée. Le conteneur DevX démarre pour exécuter le graphique avec l’exemple d’entrée.

  5. Une fois le conteneur DevX lancé, le conteneur host-app démarre avec un lldb-server pour le débogage.

Vous utilisez un fichier graphique de débogage spécial, car le débogueur actuel peut s’attacher à un seul opérateur WASM personnalisé dans une session de débogage. Le graphe de débogage dédié vous permet de conserver votre code normal graph.dataflow.yaml et empêche le débogueur de s’attacher de façon imprévisible lorsque plusieurs modules existent.

Pour créer votre propre fichier graphique de débogage :

  1. Copiez votre fichier normal graph.dataflow.yaml dans un nouveau fichier. L’utilisation du lldb- préfixe est une convention, mais le nom est arbitraire.
  2. Supprimez tous les autres opérateurs WASM personnalisés, sauf celui que vous souhaitez déboguer.
  3. Régénérez l’opérateur cible en mode débogage afin que les symboles soient disponibles.
  4. Exécutez le graphe de débogage avec le mode d’exécution défini sur debug. L’extension lance un lldb-server et attache automatiquement VS Code.

Déboguer le module WASM

  1. L’exécution s’arrête automatiquement au point d’arrêt que vous définissez dans la filter fonction.

  2. Utilisez l’interface de débogage VS Code pour :

    • Inspectez les valeurs des variables dans le panneau Variables .
    • Parcourez le code à l’aide F10 ou F11.
    • Affichez la pile des appels dans le panneau Pile des appels .
    • Ajoutez des surveillances pour des variables ou des expressions spécifiques.

  3. Poursuivez l’exécution en appuyant ou en sélectionnant F5 le bouton Continuer .

  4. Le débogueur s’arrête au point d’arrêt de chaque message en cours de traitement, ce qui vous permet d’inspecter le flux de données.

Conseils de débogage

  • Utilisez la console Debug pour évaluer les expressions et inspecter l’état d’exécution.
  • Définissez des points d’arrêt conditionnels en cliquant avec le bouton droit sur un point d’arrêt et en ajoutant des conditions.
  • Utilisez cette option F9 pour activer et désactiver les points d’arrêt sans les supprimer.
  • Le panneau Variables affiche l’état actuel des variables locales et des paramètres de fonction.

Cette fonctionnalité de débogage vous permet de résoudre les problèmes, de comprendre le flux de données et de valider votre logique de module WASM avant le déploiement en production.

Problèmes connus

Configuration du flux de données

  • Valeurs booléennes dans YAML : les valeurs booléennes doivent être entre guillemets en tant que chaînes pour éviter les erreurs de validation. Par exemple, utilisez "True" et "False" au lieu de true et false.

    Exemple d’erreur lors de l’utilisation de booléens sans guillemets :

    * spec.connections[2].from.arm: Invalid value: "boolean": spec.connections[2].from.arm in body must be of type string: "boolean"
* spec.connections[2].from.arm: Unsupported value: false: supported values: "False", "True"

  • Configuration requise pour les modules Python : pour utiliser des modules Python, Les opérations Azure IoT doivent être déployées avec le répartiteur MQTT configuré pour utiliser le profil de mémoire moyen ou élevé . Les modules Python ne peuvent pas être extraits lorsque le profil de mémoire est défini sur Low ou Tiny.

  • Minutage du déploiement de module : l’extraction et l’application de modules WASM peuvent prendre un certain temps, généralement environ une minute, en fonction des conditions réseau et de la taille du module.

Extension VS Code

  • Détails de l’erreur de build : lorsqu'une build échoue, le message d’erreur dans la notification contextuelle peut ne pas fournir suffisamment de détails. Vérifiez la sortie du terminal pour obtenir des informations d’erreur plus spécifiques.

  • Compatibilité Windows : sur Windows, la première fois que vous exécutez une application de graphique, vous pouvez rencontrer une erreur « Échec de la commande avec le code de sortie 1 ». Si cette erreur se produit, réessayez l’opération et elle doit fonctionner correctement.

  • Stabilité de l’application hôte : l’environnement d’exécution local peut parfois cesser de fonctionner et nécessiter un redémarrage pour récupérer.

Résolution des problèmes

Consultation des journaux

Pour afficher les journaux du service de flux de données, exécutez la commande suivante :

kubectl logs -n azure-iot-operations -l app.kubernetes.io/name=microsoft-iotoperations-dataflows

Pour afficher les journaux du service de traitement des données, exécutez la commande suivante :

kubectl logs -n azure-iot-operations -l app.kubernetes.io/instance=aio-dataflow-default

Pour afficher les journaux d’activité de gestion des modules, exécutez la commande suivante :

kubectl logs -n azure-iot-operations -l app.kubernetes.io/instance=aio-dataflow-graph-controller

Procédures de récupération

Réinitialisation de l’extension VS Code : si l’extension VS Code se comporte de façon inattendue, essayez de la désinstaller et de la réinstaller, puis redémarrez VS Code.

  • Last updated on