Partager via

Quels sont les modèles de configuration dans le processeur de données Azure IoT (préversion) ?

  • Article

Important

Opérations Azure IoT (préversion) – activé parc Azure Arc est actuellement en PRÉVERSION. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.

Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Plusieurs types de configuration sont communs à plusieurs phases de pipeline. Cet article décrit les modèles de configuration chemin, lot, modèles, nouvelles tentatives et durée.

Chemin d’accès

Plusieurs étapes de pipeline utilisent un chemin d’accès pour identifier un emplacement dans le message dans lequel les données doivent être lues ou écrites. Pour définir ces emplacements, vous utilisez un champ Path qui utilise la syntaxe jq :

  • Un chemin d’accès est défini comme une chaîne dans l’interface utilisateur et utilise la syntaxe jq.
  • Un chemin d’accès est défini par rapport à la racine du message du processeur de données. Le chemin . fait référence à l’intégralité du message.
  • Tous les chemins commencent par ..
  • Chaque segment de chemin peut être :
    • .<identifier> pour une clé d’objet alphanumérique telle que .topic.
    • ."<identifier>" pour une clé d’objet arbitraire telle que ."asset-id".
    • ["<identifier>"] pour une clé d’objet arbitraire telle que ["asset-id"].
    • [<index>] pour un index de tableau tel que [2].
  • Les segments peuvent être chaînés pour former des chemins complexes.

Les segments de chemin d’accès individuels doivent être conformes aux expressions régulières suivantes :

Modèle Regex Exemple
.<identifier> \.[a-zA-Z_][a-zA-Z0-9_]* .topic
."<identifier>" \."(\\"\|[^"])*" ."asset-id"
["<identifier>"] \["(\\"\|[^"])*"\] ["asset-id"]
[<index>] \[-?[0-9]+\] [2]

Pour en savoir plus, consultez Chemins d’accès dans le guide jq.

Exemples de chemins d’accès

Les chemins d'accès suivants sont des exemples basés sur la structure standard du message du processeur de données :

  • .systemProperties retourne :

    {
  "partitionKey": "foo",
  "partitionId": 5,
  "timestamp": "2023-01-11T10:02:07Z"
}

  • .payload.humidity retourne :

    10

  • .userProperties[0] retourne :

    {
  "key": "prop1",
  "value": "value1"
}

  • .userProperties[0].value retourne :

    value1

Durée

Plusieurs étapes nécessitent la définition d'une durée. Par exemple, les fenêtres d’une phase d’agrégation et des délais d’attente dans une phase d’appel. Ces étapes utilisent un champ Duration pour représenter cette valeur.

Plusieurs étapes du pipeline utilisent une durée. Par exemple, l’étape d’agrégation a une propriété Windows et les étapes de légende ont une propriété de délai d’attente. Pour définir ces intervalles de temps, vous utilisez un champ Duration :

La durée est une valeur de chaîne au format suivant <number><char><number><char> où « char » peut être :

  • h : heure
  • m : minute
  • s : seconde
  • ms : milliseconde
  • us, µs : microseconde
  • ns : nanoseconde

Exemples de durée

  • 2h
  • 1h10m30s
  • 3m9ms400ns

Modèles

Plusieurs étapes vous obligent à définir une chaîne avec une combinaison de valeurs dynamiques et statiques. Ces étapes utilisent des valeurs de modèle.

Les modèles de processeur de données utilisent syntaxe Mustache pour définir des valeurs dynamiques dans des chaînes.

Les valeurs système dynamiques disponibles pour une utilisation dans les modèles sont les suivantes :

  • instanceId: ID d’instance du processeur de données.
  • pipelineId: ID de pipeline dont fait partie l’étape.
  • YYYY: année en cours.
  • MM: mois en cours.
  • DD: date actuelle.
  • HH: heure actuelle.
  • mm: minute actuelle.

Actuellement, vous pouvez utiliser des modèles pour définir des chemins de fichier dans une phase de destination.

Champs statiques et dynamiques

Certaines étapes nécessitent la définition de valeurs qui peuvent être des chaînes statiques ou une valeur dynamique dérivée d’un Path dans un Message. Pour définir ces valeurs, vous pouvez utiliser des champs statiques ou dynamiques.

Un champ statique ou dynamique est toujours écrit en tant qu’objet avec un champ type qui a l’une des deux valeurs suivantes : static ou dynamic. Le schéma varie en fonction de type.

Champs statiques

La définition statique est une valeur fixe pour type est static. La valeur réelle est conservée dans value.

Champ Type Description Obligatoire Par défaut Exemple
type chaîne const Type du champ. Oui - static
value tous Valeur statique à utiliser pour la configuration (généralement une chaîne). Oui - "static"

Les exemples suivants illustrent certaines définitions de champs statiques :

{
    "some-field": {
        "type": "static",
        "value": "some-static-value"
    }
}

{
    "some-boolean-field": {
        "type": "static",
        "value": true
    }
}

{
    "some-complex-field": {
        "type": "static",
        "value": {
            "some": [
                "nested",
                "data"
            ]
        }
    }
}

Champs dynamiques

La valeur fixe pour type est dynamic. La valeur est un chemin jq.

Champ Type Description Obligatoire Par défaut Exemple
type chaîne const Type du champ Oui - dynamic
value Chemin d’accès Chemin d’accès dans chaque message où une valeur pour le champ peut être récupérée dynamiquement. Oui - .systemProperties.partitionKey

L’exemple suivant montre une définition de champ dynamique :

{
    "some-field": {
        "type": "dynamic",
        "value": ".systemProperties.topic"
    }
}

Réessayer

Les étapes qui appellent des services externes peuvent utiliser des nouvelles tentatives pour gérer les défaillances temporaires et améliorer la fiabilité. Vous pouvez remplacer la stratégie de nouvelle tentative par défaut lorsque vous configurez une étape.

Il existe quatre stratégies de nouvelle tentative possibles :

  • default : la stratégie de nouvelle tentative par défaut consiste à utiliser une nouvelle tentative d’interruption exponentielle avec trois nouvelles tentatives et un intervalle de nouvelle tentative initial de 500 ms.
  • none : aucune nouvelle tentative n’est effectuée.
  • fixed : une stratégie de nouvelle tentative fixe retente un nombre fixe de tentatives avec un intervalle fixe entre chaque nouvelle tentative.
  • exponential : une stratégie de nouvelle tentative exponentielle retente un nombre fixe de tentatives avec un intervalle croissant de manière exponentielle entre chaque nouvelle tentative.

Si vous choisissez default ou none, vous n’avez pas besoin de fournir plus de configuration. Si vous choisissez fixed ou exponential, vous devez fournir plus de configuration :

Fixe

Champ Type Description Requis ? Par défaut Exemple
type string Nom du type de nouvelle tentative : fixed Oui S/O fixed
interval Durée Période initiale entre chaque nouvelle tentative. Non 500ms 2s
maxRetries int Nombre de nouvelles tentatives, de 1 à 20 Non 3 20

Exponentielle

Champ Type Description Requis ? Par défaut Exemple
type string Nom du type de nouvelle tentative : exponential Oui S/O exponential
interval Durée Période initiale entre chaque nouvelle tentative. Non 500ms 2s
maxRetries int Nombre de nouvelles tentatives, de 1 à 20 Non 3 20
maxInterval Durée Période maximale entre chaque nouvelle tentative. Non Aucun 100s

Les temps de nouvelle tentative exponentielle sont calculés comme suit : si l’intervalle commence par 500ms, les intervalles de nouvelle tentative suivants sont randInt(500ms, 500ms * 2^1), randInt(500ms, 500ms * 2^2) ... randInt(500ms, 500ms * 2^maxRetries).

Batch

Plusieurs destinations dans l’étape de sortie vous permettent de traiter les messages par lots avant qu’ils n’écrivent dans la destination. Ces destinations utilisent lot pour définir les paramètres de traitement par lots.

Actuellement, vous pouvez définir lot en fonction du temps. Pour définir le traitement par lots, vous devez spécifier l’intervalle de temps et un chemin d’accès. Path définit la partie du message entrant à inclure dans la sortie par lots.

Champ Type Description Obligatoire Par défaut Exemple
Heure Durée Durée de traitement par lots des données Non 60s (Dans les destinations où le traitement par lots est appliqué) 120s
Chemin d’accès Chemin d’accès Chemin d’accès à la valeur dans chaque message à inclure dans la sortie. Non .payload .payload.output

Contenu connexe