AWS IoT Greengrass Version 1 est entré dans la phase de durée de vie prolongée le 30 juin 2023. Pour plus d'informations, consultez la politique de AWS IoT Greengrass V1 maintenance. Après cette date, AWS IoT Greengrass V1 ne publiera pas de mises à jour fournissant des fonctionnalités, des améliorations, des corrections de bogues ou des correctifs de sécurité. Les appareils qui fonctionnent AWS IoT Greengrass V1 sous tension ne seront pas perturbés et continueront à fonctionner et à se connecter au cloud. Nous vous recommandons vivement de migrer vers AWS IoT Greengrass Version 2, qui ajoute de nouvelles fonctionnalités importantes et prend en charge des plateformes supplémentaires.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utiliser le contexte IDT

Lorsque IDT exécute une suite de tests, la suite de tests peut accéder à un ensemble de données qui peuvent être utilisées pour déterminer comment chaque test s'exécute. Ces données sont appelées contexte IDT. Par exemple, la configuration des données utilisateur fournie par les exécuteurs de tests dans unuserdata.jsonest mis à la disposition des suites de tests dans le contexte IDT.

Le contexte IDT peut être considéré comme un document JSON en lecture seule. Les suites de tests peuvent extraire des données du contexte et les écrire à l'aide de types de données JSON standard tels que des objets, des tableaux, des nombres, etc.

Schéma contextuel

Le contexte IDT utilise le format suivant :

{
    "config": {
        <config-json-content>
        "timeoutMultiplier": timeout-multiplier
    },
    "device": {
        <device-json-device-element>
    },
    "devicePool": {
        <device-json-pool-element>
    },
    "resource": {
        "devices": [
            {
                <resource-json-device-element>
                "name": "<resource-name>"
            }
        ]
    },
    "testData": {
        "awsCredentials": {
            "awsAccessKeyId": "<access-key-id>",
            "awsSecretAccessKey": "<secret-access-key>",
            "awsSessionToken": "<session-token>"
        },
        "logFilePath": "/path/to/log/file"
    },
    "userData": {
        <userdata-json-content>
    }
}

Accédez aux données dans le contexte

Vous pouvez interroger le contexte à l'aide de la notation JSONPath à partir de vos fichiers JSON et de votre exécutable de texte avec leGetContextValueetGetContextStringAPI. La syntaxe des chaînes JSONPath pour accéder au contexte IDT varie comme suit :

Le tableau suivant décrit les opérateurs dans une expression JSONPath typique :

Pour créer des expressions de filtre, utilisez la syntaxe suivante :

<jsonpath> | <value> operator <jsonpath> | <value> 

Dans cette syntaxe :

Vous pouvez utiliser des requêtes JSONPath sous la forme {{requête}} sous forme de chaînes d'espace réservé dans leargsetenvironmentVariableschamps danstest.jsonet dans le dossierenvironmentVariableschamps danssuite.jsonfichiers suivants. IDT effectue une recherche de contexte et remplit les champs avec la valeur évaluée de la requête. Par exemple, dans lesuite.json, vous pouvez utiliser des chaînes d'espace réservé pour spécifier des valeurs de variables d'environnement qui changent avec chaque cas de test et IDT renseignera les variables d'environnement avec la valeur correcte pour chaque cas de test. Toutefois, lorsque vous utilisez des chaînes d'espace réservé danstest.jsonetsuite.json, les considérations suivantes s'appliquent à vos requêtes :

En raison de ces considérations, nous recommandons que, dans la mesure du possible, vous utilisiez l'API pour accéder au contexte de votre logique de test plutôt que des chaînes d'espace réservé danstest.jsonetsuite.jsonfichiers suivants. Cependant, dans certains cas, il peut être plus pratique d'utiliser des espaces réservés JSONPath pour récupérer des chaînes uniques à définir comme variables d'environnement.