Analyseur

Les analyseurs sont des entités de configuration qui définissent la façon dont les messages d'une classe de messages source spécifique sont analysés et transformés en enregistrements d'un type cible spécifique.

source-to-target

Une configuration d'analyseur comporte les trois composants suivants :

Association de la classe de message source : un analyseur traite les messages sources d'une seule classe de message source. Pour en savoir plus, consultez Classes de messages sources.
Association de version de type : un analyseur émet des enregistrements proto d'une seule version de type. La configuration de la version du type définit les champs qui doivent être présents dans l'enregistrement proto émis et dicte leur structure (schéma). Pour en savoir plus, consultez Type.
Script Whistle : les scripts Whistle définissent comment transformer les messages sources en enregistrements proto à l'aide d'une logique de mappage, d'analyse et de transformation. Les scripts Whistle sont écrits par les utilisateurs. Toutefois, Manufacturing Data Engine (MDE) fournit des packages de configuration pour les cas d'utilisation courants. Pour en savoir plus, consultez la section suivante.

Définition du sifflement

Whistle est un langage de mappage qui peut être utilisé pour convertir des données imbriquées complexes d'un schéma à un autre. Dans le secteur manufacturier, les modèles de données peuvent être complexes et contenir de nombreuses structures imbriquées et répétées. Il est donc difficile d'exprimer la logique de mappage dans un format procédural. Whistle résout ce problème en fournissant un langage déclaratif qui vous permet de définir la logique de mappage et de transformation de manière naturelle.

Par exemple, vous pouvez utiliser Whistle pour harmoniser plusieurs modèles de données de capteurs dans différentes usines en un modèle de type MDE unifié. Les données sources peuvent contenir des structures imbriquées, telles qu'une liste de composants ou une hiérarchie de caractéristiques. Whistle vous permet d'exprimer la logique de mappage de ces structures imbriquées de manière naturelle, sans avoir à écrire de code procédural.

Whistle est également compatible avec les fonctions qui vous permettent de décomposer des mappages complexes impliquant des structures répétées en fonctions. Cela facilite la compréhension et la gestion de votre code de mappage, ainsi que la réutilisation du code.

Whistle offre des avantages par rapport aux approches procédurales. Consultez l'exemple ci-dessous :

Prenons l'exemple de charge utile suivant :

{
  "payload": {
    "tag": "vibration-sensor"
  },
  "details": {
    "value": 0.24,
    "timestamp": "2023-06-26 12:19:20.046000 UTC"
  }
}

Et le script Whistle suivant :

package mde

[{
    tagName: $root.payload.tag
    timestamps: {
        eventTimestamp: $root.details.timestamp
    }
    data: {
        numeric: $root.details.value
    }
}]

En appliquant le script Whistle précédent, l'analyseur générerait un enregistrement proto semblable à celui-ci :

[
  {
    "tagName": "vibration-sensor",
    "timestamps": {
      "eventTimestamp": "2023-06-26 12:19:20.046000 UTC"
    },
    "data": {
      "value": 0.24
    }
  }
]

Pour en savoir plus sur la syntaxe du langage Whistle et les fonctions disponibles, consultez la documentation Whistle.

Comportement des analyseurs lors de l'exécution

Lors de l'exécution, l'analyseur reçoit tous les messages de la classe de messages source à laquelle il est associé, applique le script Whistle configuré à chaque message et émet un ou plusieurs enregistrements proto du type configuré.

Les enregistrements proto émis doivent respecter la configuration du type. S'ils ne le font pas, ils sont placés dans la file d'attente de lettres mortes.

Règles d'association

Un analyseur ne peut être associé qu'à une seule classe de message et à un seul type de version. Toutefois, un analyseur peut émettre un ou plusieurs enregistrements à condition qu'ils soient du type de version auquel l'analyseur est associé. La sortie d'un analyseur est un tableau d'objets d'enregistrement proto.

parser-multiple-proto-records

L'émission de plusieurs enregistrements à partir d'un analyseur est utile dans les scénarios où un message source contient un tableau de lectures ou d'événements que vous souhaitez désagréger. Les analyseurs vous permettent de "diviser" le message source en plusieurs enregistrements proto afin que chaque lecture, par exemple, devienne une ligne dans une table d'enregistrements dans BigQuery.

Les enregistrements proto émis peuvent faire référence à n'importe quel nom de tag. Ce comportement est différent de celui des versions 1.1 et 1.2, dans lesquelles les noms de balises étaient limités au type. Après la version 1.3, les enregistrements proto MDE émis par n'importe quel analyseur peuvent

Schéma d'enregistrement proto

Le schéma JSON auquel les enregistrements proto doivent se conformer dépend des éléments suivants :

Archétype : archétype spécifique associé au type.
Configuration du type : paramètres de configuration définis pour le type.

L'archétype définit le schéma de base des enregistrements. Par exemple, un type de la famille d'archétypes discrete exige que les enregistrements proto contiennent des valeurs pour les attributs suivants :

tagName
timestamps.eventTimestamp
data.complex

Le type peut imposer des restrictions supplémentaires aux enregistrements proto. Par exemple, vous pouvez définir un schéma pour le champ data ou exiger que les enregistrements proto fournissent une référence à une instance de métadonnées.

Pour en savoir plus, consultez la documentation de référence sur les enregistrements proto.

Recherche de données de référence

MDE fournit une fonction Whistle personnalisée pour rechercher la valeur d'une clé fournie à partir d'un bucket de recherche.

Vous pouvez rechercher une instance de bucket de recherche par sa clé naturelle en appelant la fonction mde::lookupByKey dans un script Whistle. La fonction utilise lebucketName, lebucketVersion et lenaturalKey de l'instance comme arguments, et renvoie la dernière instance de métadonnées pour la clé naturelle fournie. Vous pouvez utiliser l'instance pour remplir les champs d'un enregistrement proto dans l'analyseur. Exemple :

"data" : {
  "complex" : {
    "VIN" : mde::lookupByKey("vin-lookup-bucket", input.vinKey, 1).VIN,
    "vin_registration_time" : mde::lookupByKey("vin-lookup-bucket", input.vinKey, 1).vin_registration_time,
    "ResultValue" : 163.0482614,
  }
}

Restrictions de dénomination pour les analyseurs

Un nom d'analyseur peut contenir les éléments suivants :

Lettres (majuscules et minuscules), chiffres et caractères spéciaux - et _.
Il peut comporter jusqu'à 255 caractères.

Vous pouvez utiliser l'expression régulière suivante pour la validation : ^[a-z][a-z0-9\\-_]{1,255}$.

Si vous essayez de créer une entité qui ne respecte pas les restrictions de nommage, vous obtiendrez un 400 error.

Vous pouvez utiliser la fonction mde::sanitizeTagName() pour vous assurer que votre nom respecte les restrictions d'attribution de noms. Pour en savoir plus, consultez Fonctions Whistle MDE.