Utilisation du service QueryPropertyHistory
Le service QueryPropertyHistory interroge le flux de valeurs de chaque valeur de propriété (qui doit être une propriété consignée) de l'objet source donné dans une plage horaire spécifique. Le service appelle ValueStream.queryValueStreamEntriespour chaque propriété, puis consolide les valeurs dans un jeu de résultats.
QueryPropertyHistory renvoie un jeu de données créé en interrogeant chaque propriété consignée d'un objet, puis en combinant les différents jeux de données dans un jeu de données global. Une "ligne" est créée par horodatage dans les jeux de données individuels. S'il existe une valeur consignée avec cet horodatage, celle-ci est entrée dans la ligne du jeu de données. S'il n'existe aucune valeur consignée, la dernière valeur consignée pour cette propriété est utilisée. S'il n'existe aucune propriété consignée, l'entrée est laissée vide. Ce processus de consolidation supprime les doublons pour une propriété donnée en fonction de l'horodatage.
Pour obtenir les valeurs consignées réelles pour une propriété donnée, vous devez utiliser les services QueryPropertyHistory (par exemple, QueryIntegerPropertyHistory). Ces services permettent de confirmer la purge des données. Pour comprendre le fonctionnement de ce service, plusieurs scénarios d'exemple sont indiqués ci-dessous.
Scénarios d'exemple
Scénario 1 : Je spécifie trois lignes, mais QueryPropertyHistory en renvoie neuf
Un flux de valeurs est utilisé pour consigner trois propriétés. Pour chaque propriété, trois entrées distinctes sont déjà disponibles. Par conséquent, neuf points de données sont entrés.
Si QueryPropertyHistory est appelé dans ce flux de valeurs tandis que le paramètre maxItems est défini sur trois, neuf lignes de données seront renvoyées. QueryPropertyHistory a interrogé à trois reprises chaque propriété individuelle car maxItems était défini sur trois. Etant donné qu'il existait trois entrées de données pour chaque propriété, il était possible de renvoyer le nombre maximal d'éléments, à savoir neuf.
Scénario 2 : Je sais que des données sont associées à cet horodatage, mais je reçois une table d'informations vide
Vous pouvez consigner votre propre horodatage personnalisé depuis un périphérique Edge si vous ne souhaitez pas utiliser celui généré automatiquement par ThingWorx lorsqu'une valeur est entrée dans le flux de valeurs. Cependant, les comportements suivants doivent être pris en compte.
Que peut-il se produire si j'essaie d'interroger cette colonne personnalisée d'horodatage au lieu d'utiliser setPropertyVTQ ?
Le service QueryPropertyHistory passe au flux de valeurs utilisé par l'objet, puis collecte un jeu de résultats initial en fonction des paramètres startDate, endDate, oldestFirst et maxRows.
Si les paramètres startDate et endDate sont vides, cela signifie que la requête ne porte pas sur la propriété d'horodatage automatiquement générée. La requête collecte alors le nombre maximal de lignes défini pour maxRows (500, par exemple) parmi les valeurs de propriété les plus récentes ou les plus anciennes dans le flux de valeurs. Le paramètre booléen oldestFirst permet de définir cet état de fait. Si oldestFirst est défini sur Faux, le jeu de résultats renvoyé contient les 500 valeurs de propriété les plus récentes pour chaque propriété. Ainsi, avec trois propriétés consignées avec plus de 500 valeurs chacune, le jeu de données initial contiendra 1 500 lignes.
Que se passe-t-il lors du post-traitement ?
Un paramètre n'a pas encore été utilisé : query. Ce paramètre est appliqué lors du post-traitement. Une fois la requête initiale sur le flux de valeurs exécutée, le jeu de résultats initial obtenu se voit ainsi appliquer le paramètre query afin de filtrer et de ne renvoyer que les données souhaitées.
Problème ?
Si vous avez décidé d'interroger la propriété personnalisée d'horodatage créée, mais que le premier jeu de résultats renvoyé ne contient pas les données d'horodatage recherchées, aucune donnée ne sera trouvée et une table d'informations vide sera renvoyée.
Solution
Pour éviter ce problème, utilisez le service setPropertyVTQ pour entrer votre propre valeur d'horodatage dans le flux de valeurs. Cela remplace les valeurs d'horodatage générées automatiquement qui indiquent l'heure exacte à laquelle une valeur a été entrée dans le flux de valeurs. Les paramètres startDate et endDate peuvent alors être utilisés à la place du paramètre query pour lancer une requête sur les dates. Vous ne risquerez ainsi pas de perdre des données suite à une requête lancée sur un horodatage.