HTTP

Référence du pilote HTTP : scruter des points de terminaison HTTP et HTTPS comme des tags, les identifiants, la correspondance des chemins, l'analyse du corps, les écritures PUT et les types.

Afficher en Markdown

Le pilote HTTP scrute des points de terminaison HTTP génériques comme des tags : un capteur du réseau local avec un petit serveur web, une passerelle qui publie ses relevés à des URL fixes, un service à vous. C'est le pilote en mode client le plus simple du produit : Ganter Lab se connecte à l'équipement par de simples requêtes GET et lit chaque corps de réponse comme une valeur.

Deux propriétés tracent la limite de ce à quoi il sert :

Le transport est celui que l'adresse nomme. Un équipement dont l'hôte s'écrit https://host atteint son service par TLS; un hôte écrit tout seul est du HTTP simple. Dans les deux cas, le pilote envoie l'identifiant de l'équipement à chaque requête, soit un nom d'utilisateur et un mot de passe en HTTP Basic, soit un jeton porteur. Ce que les pilotes AVEVA PI et Redfish ajoutent encore pour ces deux services, c'est leur vocabulaire : chemins PI et WebIds, arbres de ressources Redfish, dont ce pilote ne sait rien.
Le corps entier de la réponse est la valeur. Le pilote n'est pas un extracteur de champ JSON : un tag numérique attend que le corps soit le nombre nu.

Champs de connexion

Champ	Ce que c'est	Format	Par défaut
Hôte	Le nom d'hôte ou l'adresse IP du point de terminaison. Écrit `https://host`, il est atteint par TLS, ce qui tient un identifiant hors du fil; un hôte écrit tout seul est du HTTP simple.	Nom d'hôte, IP, ou l'un ou l'autre précédé de `http://` ou de `https://`	vide
Port	Le port TCP. Zéro veut dire le port sur lequel le transport répond : 80 en simple, 443 en HTTPS.	numéro de port	0
Chemin de ressource	Un préfixe de chemin facultatif placé devant le chemin de chaque tag, par exemple `api/v2`. Vide ne préfixe rien.	texte de chemin	vide
Nom d'utilisateur	Le compte pour l'authentification HTTP Basic, employé seulement quand aucun jeton porteur n'est posé. Vide (et sans jeton) laisse les requêtes anonymes.	Texte libre	vide
Mot de passe	Le mot de passe associé au nom d'utilisateur. Protégé au repos par utilisateur Windows; un secret saisi sous un autre compte Windows paraît illisible et doit être saisi de nouveau.	Texte libre	vide
Jeton porteur	Un jeton envoyé comme `Authorization: Bearer …` à chaque requête. Quand il est posé, il l'emporte sur la paire nom d'utilisateur et mot de passe. Protégé au repos de la même façon.	Texte du jeton	vide

À la connexion, le pilote vérifie le point de terminaison par une requête HEAD vers l'adresse configurée, l'hôte suivi du chemin de ressource, en retombant sur GET quand HEAD n'est pas implémenté; une adresse qui répond correctement à l'une ou à l'autre compte comme joignable. Un service dont la racine répond 404 alors que son API répond normalement est donc en ligne, tant que le chemin de ressource pointe vers l'API. En HTTPS, le certificat TLS du service doit passer la validation de certificat habituelle de Windows. Un identifiant sur une adresse qui ne nomme aucun TLS part en clair, et la station l'inscrit au journal du connecteur quand l'équipement se connecte. Chaque requête reçoit dix secondes : un point de terminaison qui accepte la connexion puis ne dit rien coûte une lecture, pas tout l'équipement, parce que les autres tags de l'équipement sont lus dans la même passe. L'intervalle de scrutation est configurable : la valeur de l'équipement (1000 ms) s'applique à chaque tag qui n'énonce pas la sienne.

Adressage d'un tag

Le champ Chemin du tag est le chemin d'URL relatif au chemin de ressource de l'équipement :

Champ	Ce qu'il fait	Valeurs	Par défaut
Chemin	Le chemin demandé pour ce tag. L'URL complète est `<transport>://<hôte>:<port>/<chemin de ressource>/<chemin>`.	Texte libre (obligatoire)	vide

Exemple : l'hôte 192.168.0.40, le chemin de ressource api et le chemin de tag sensors/temp scrutent http://192.168.0.40/api/sensors/temp.

Lectures

Chaque scrutation fait un GET sur l'URL du tag et analyse le corps entier de la réponse selon le type de donnée déclaré du tag :

Type	Corps accepté
Float	Un nombre au format invariant (`21.5`, point décimal, sans séparateur de milliers)
Int32	Un entier (`42`)
Boolean	`true` ou `false`
String	N'importe quoi; le corps est la valeur telle quelle (un document JSON arrive comme son texte brut)

Un corps que le type déclaré ne peut pas analyser, ou un code de statut hors succès, se lit comme une lecture en échec : le tag passe en mauvaise qualité et sa politique d'échec de lecture décide de ce qui est présenté, comme décrit sur la page Connector.

Écritures

Les tags dont le mode d'accès est inscriptible écrivent par PUT vers la même URL : le corps est la valeur en JSON, envoyée avec le type de contenu application/json. Un nombre part comme littéral nu (42.5), un booléen comme true ou false, et le texte part entre guillemets ("automatic"). Le point de terminaison décide de ce qu'il en fait; un statut hors succès se lit comme une écriture en échec. Comme partout ailleurs, la zone d'écriture prend la valeur physique et les étapes de conversion du tag sont remontées avant que la valeur brute ne parte sur le bus, comme décrit sur la page Connector.

Types de donnée pris en charge

Boolean, Int32, Float et String.

Commandes

Un tag lit une valeur; une commande demande au service de faire quelque chose. Déclarez chacune sur l'équipement, dans la carte Commandes de sa page : un nom, le chemin auquel elle est envoyée par POST (sous l'adresse propre de l'équipement, exactement comme le chemin d'un tag), et au besoin le nom de l'unique valeur qu'elle prend. Le verbe Exécuter de la ligne l'envoie et rapporte ce que le service a répondu, et la commande devient aussi une méthode sur l'équipement dans l'espace d'adressage OPC UA propre à cette station, si bien que tout ce qui sait appeler une méthode peut la lancer. La valeur que vous tapez est envoyée comme corps de la requête, telle quelle.

Ce que le service répond est le résultat de la commande. Un statut que le service renvoie hors de la plage de succès est le service qui refuse la commande, non la connexion qui échoue : le refus nomme le statut et cite ce que le service a dit avec lui (« HTTP 500 : le brûleur est en verrouillage »), et rien d'autre sur l'équipement n'en est dérangé.

Découverte

Le pilote n'a pas de balayage de découverte. Ajoutez chaque point de terminaison par son hôte et chaque valeur par son chemin; l'ajout d'un équipement est décrit sur la page Connector.