Ce que Weave vérifie

Description

Weave lit la configuration que votre projet a déjà enregistrée, ainsi que l’historique d’exécution de ses workflows sur les 30 derniers jours, et signale ce qu’il trouve : une étape dont l’allocation n’a rien à allouer, un workflow dont la structure enregistrée liste deux fois la même étape, un workflow dont la dernière exécution a échoué, une étape dont la sortie contient beaucoup moins de lignes que d’habitude. Il ne fait que lire — rien de ce qu’il signale ne modifie une étape, et il n’exécute jamais votre workflow.

Aucun modèle d’IA n’intervient. Chaque contrôle est une règle fixe et chaque phrase est écrite à l’avance, si bien qu’un rapport ne coûte rien à produire, quelle que soit la fréquence à laquelle vous en demandez un.

Note

Les constats sont accessibles via l’API de la plateforme, et l’onglet Weave du projet liste tous les constats du projet.

Trois réponses, pas deux

La plupart des contrôles de PlaidCloud ont deux réponses : votre configuration est correcte, ou elle est refusée. Weave en a une troisième, et c’est celle qu’il vaut la peine de comprendre.

Réponse	Signification
Weave noticed …	Weave a contrôlé ce point et a trouvé un problème.
(rien n’est dit)	Weave a contrôlé ce point et n’a rien trouvé d’anormal.
Weave hasn’t checked …	Weave n’a pas pu juger ce point du tout.

La troisième existe parce que le silence est ambigu. Lorsque vous créez une étape d’allocation, PlaidCloud vous laisse l’enregistrer avant d’avoir renseigné son mappage de colonnes — vous êtes encore en train de la construire, et refuser l’enregistrement vous empêcherait de travailler. Un outil de surveillance qui lirait ce même mappage vide pourrait très bien déclarer l’étape saine. Elle ne l’est pas ; elle est inachevée, et personne ne l’a examinée.

Weave le dit donc. Une étape qu’il n’a pas pu juger est signalée comme non vérifiée, avec la raison, et elle n’est jamais comptée, triée ni colorée comme si elle avait réussi.

Weave peut dire une quatrième chose, qui n’est pas du tout une réponse sur votre étape : Weave has no rule for …. Cela signifie que Weave n’a aucun contrôle pour ce type d’élément et ne l’a jamais jugé. Contrairement à « n’a pas vérifié », rien de ce que vous faites sur l’étape ne produira de verdict ; il vaut donc la peine de distinguer les deux : terminez une étape non vérifiée et Weave la jugera ; une étape pour laquelle il n’a aucune règle reste non jugée, quelles que soient vos modifications.

À quoi ressemble un rapport

Un rapport s’ouvre sur un résumé qui nomme son propre dénominateur, afin que vous voyiez quelle part du projet il couvre :

Weave fully checked 3 of the 417 steps and workflows in "Cost Model", and found 1
problem in the parts it could judge. 1 more it hasn't fully checked.
Weave has no rule for 412 steps and 1 workflow it looked at, so they have not been
judged either way.

Weave noticed the step "Spread Overheads": No driver split value column found. One
driver column must have the role "Split Value".
Weave hasn't checked the step "Regional Split" — its column mapping is empty.

Lorsqu’un projet contient des tables écrites selon une planification ou dotées d’un seuil de fraîcheur, la première ligne les compte séparément : Weave a entièrement vérifié 31 des 36 étapes et workflows, et 3 des 4 tables censées être tenues à jour, dans « Finance », et a trouvé 2 problèmes dans les parties qu’il pouvait juger.

La fraction de la première ligne est voulue. Trois étapes vérifiées et jugées saines ne disent pas la même chose qu’un projet sain, et la ligne d’ouverture porte sa propre échelle afin de ne pas pouvoir être citée sans elle. « Dans les parties qu’il pouvait juger » s’y trouve pour la même raison : lorsqu’un élément n’a été jugé qu’en partie, les problèmes trouvés ne peuvent pas être imputés aux étapes que la ligne vient de déclarer vérifiées. La deuxième ligne nomme ce pour quoi Weave n’a aucune règle, et dit clairement que ces éléments n’ont été jugés ni dans un sens ni dans l’autre — et non qu’aucun contrôle n’était nécessaire.

Comment Weave le sait

Chaque constat comporte en dessous un lien Comment Weave le sait, qui ouvre un panneau montrant comment Weave y est parvenu :

• La vérification — ce que la règle teste, en termes simples, avec les limites qu’elle utilise, par exemple le nombre d’exécutions antérieures auxquelles elle compare un décompte.
• Les preuves — les valeurs utilisées par le contrôle. Pour un nombre de lignes qui a changé, il s’agit du dernier décompte, de la moyenne des exécutions antérieures, de l’ampleur habituelle des variations du décompte d’une exécution à l’autre, et de la plage en dehors de laquelle Weave le signale.
• D’où cela provient — l’exécution, l’historique d’exécution, les paramètres enregistrés de l’étape, l’événement planifié ou la table dont les preuves ont été lues. Un élément affiché sous forme de lien ouvre l’endroit où vous iriez le consulter, par exemple le workflow ou l’Explorateur de tables.
• Ce que Weave n’a pas vérifié — ce que la règle laisse de côté. Cette rubrique n’est jamais vide : un contrôle vérifiant qu’une table a été écrite à temps, par exemple, ne regarde pas ce qui a été écrit.

Pour un constat que Weave n’a pas pu vérifier, le panneau montre le contrôle et la raison pour laquelle il n’a pas pu s’exécuter, et aucune preuve.

Le panneau ne nomme que ce que vous pouvez voir. Une étape, un workflow ou une table que votre rôle masque est listé comme un élément que vous ne pouvez pas ouvrir, jamais par son nom, et lorsque la dernière exécution d’un workflow a échoué dans des étapes que vous ne pouvez pas ouvrir, les preuves comptent ces étapes au lieu de les nommer. Aucune IA n’intervient dans la construction du panneau.

Le panneau apparaît dans l’onglet Weave et dans une revue. Le résumé rédigé par l’IA d’une revue en comporte aussi un, qui indique qu’il a été rédigé par l’IA, à partir de combien de constats, et ce que Weave a vérifié avant de l’afficher. Une revue qu’un assistant IA exécute via PlaidCloud MCP omet le panneau.

Ce que Weave vérifie aujourd’hui

Mappage de colonnes d’allocation. Pour une étape Allocation with Dimension ou Allocation Split, qu’il existe une colonne numérique à allouer, une valeur d’inducteur numérique selon laquelle l’allouer, une hiérarchie lorsqu’il en faut une, et — pour une répartition — un numérateur et un dénominateur qui nomme une colonne que la table source possède réellement. Ce sont les mêmes contrôles que ceux exécutés lorsque vous enregistrez l’étape, appliqués à ce qui a déjà été enregistré. L’enregistrement vérifie aussi la dimension d’affectation elle-même — qu’elle existe et qu’elle a exactement une propriété d’inducteur — ce que Weave ne fait pas ; une étape que l’enregistrement refuse pour cette raison ne produit donc aucun constat Weave.

Expressions d’étape. Pour toute étape qui en comporte, que chaque expression que vous avez écrite — sur une colonne cible, dans la clause Subset ou dans la clause Secondary Filter — se compile toujours. Un constat nomme la colonne ou la clause afin que vous sachiez laquelle ouvrir, et donne l’erreur, par exemple Syntax error at line 1, position 280. L’expression elle-même se trouve sous Comment Weave le sait, afin qu’une expression longue n’enfouisse pas l’erreur. Ce sont les mêmes contrôles que ceux exécutés lorsque vous enregistrez l’étape.

Weave signale deux cas comme non vérifiés au lieu de les juger :

• Une expression qui lit une variable. Une étape peut appartenir à plusieurs workflows, et chaque workflow peut attribuer à une variable une valeur différente — ou ne pas la définir du tout. Le contrôle à l’enregistrement sait depuis quel workflow vous enregistrez ; une analyse, non. Plutôt que d’en choisir un et de risquer de déclarer cassée une expression qui fonctionne, Weave signale l’étape comme non vérifiée lorsque la variable n’est pas définie partout, ou qu’elle est définie avec des valeurs divergentes. Un workflow que votre rôle ne vous montre pas compte de la même façon : Weave ne peut pas non plus lire ses variables, il ne prétendra donc pas que l’étape concorde. Lorsque tous les workflows concordent, il juge l’étape normalement.
• Les filtres et listes de colonnes que ce contrôle ne lit pas. Certains types d’étape conservent un filtre ou une seconde liste de colonnes dans une partie du formulaire que le contrôle des expressions n’a jamais lue — les jointures à deux tables et Lookup, les répartitions d’allocation, Generate Batch et SAP Post Journal Entry. L’enregistrement de ces étapes a toujours ignoré ces champs ; Weave ne valide donc pas l’étape sur la moitié qu’il peut lire : il la signale comme non vérifiée. Les étapes Jointure multi-tables et Delete sont signalées de la même façon, car leur configuration n’a pas une forme que ce contrôle peut compiler.

Un élément listé deux fois dans un workflow. Qu’aucune étape ni aucun workflow imbriqué n’apparaisse plus d’une fois dans le même workflow, et que deux dossiers partageant un parent ne portent pas le même identifiant.

Étapes qui peuvent s’exécuter avant l’écriture de la table qu’elles lisent. Dans un workflow avancé, que chaque étape qui lit une table s’exécute après l’étape du même workflow qui l’écrit, via les connecteurs du canevas. Weave le vérifie, que le workflow se soit déjà exécuté ou non. Un constat nomme une de ces étapes et l’étape après laquelle elle devrait s’exécuter, et indique combien d’étapes sont concernées ; les tables sont listées sous Comment Weave le sait. Une étape que le canevas exécute déjà trop tôt est signalée séparément. Weave signale le workflow comme non vérifié lorsqu’une étape exécute un autre workflow ou utilise des tables qu’il ne peut pas suivre, et ne juge pas une table qu’écrivent aussi plusieurs étapes ou un autre workflow. Pour examiner et ajouter les connecteurs manquants, utilisez Synchroniser les dépendances sur le canevas. Si une étape est censée lire la sortie de l’exécution précédente, marquez le constat comme attendu.

Comment vos workflows se sont exécutés. Weave lit les exécutions de chaque workflow sur les 30 derniers jours — jusqu’aux vingt exécutions les plus récentes de chaque workflow — et juge la dernière par rapport à celles qui la précèdent. Pour les comparaisons de fin de mois et de jour de la semaine ci-dessous, il lit aussi quelques exécutions plus anciennes sur les 180 derniers jours. Chaque comparaison se fait par rapport à l’historique du workflow lui-même, jamais à celui d’un autre workflow.

• Échec de la dernière exécution. Un workflow dont l’exécution la plus récente a échoué est signalé, avec la date de l’échec et, lorsque les exécutions précédentes ont aussi échoué, combien de fois de suite et depuis quand.

• Exécution plus lente que d’habitude. Une exécution qui s’est terminée, mais dont les étapes ont pris, ensemble, plus de temps que ne l’admettent les exécutions terminées précédentes du workflow — plus de deux écarts types au-dessus de leur moyenne, et au moins 5 % au-dessus de celle-ci (jamais moins d’une seconde, afin qu’un workflow rapide ne soit pas signalé pour quelques millisecondes). Le temps est celui des étapes additionnées ; pour un workflow qui exécute des étapes en parallèle, il dépasse donc ce que l’horloge a indiqué. Une exécution qui s’est terminée plus vite n’est pas signalée.

• Étape plus lente que d’habitude. Une étape qui a pris plus de temps lors de sa dernière exécution terminée que lors de ses exécutions terminées antérieures dans ce workflow, selon la même mesure que pour une exécution lente. C’est ainsi que Weave nomme l’étape à l’origine d’une exécution lente. Une étape présente dans plusieurs workflows est jugée séparément dans chacun. Le temps court du début de l’étape à sa fin : Weave ne sépare pas le travail propre de l’étape du temps passé à attendre, par exemple un entrepôt occupé.

• Les exécutions ont ralenti. Un ralentissement qui dure. Une fois que les exécutions plus lentes forment la majorité des exécutions antérieures auxquelles une exécution est comparée, une exécution lente cesse de paraître inhabituelle ; ce contrôle compare donc plutôt des moitiés. Weave lit les 20 dernières exécutions du workflow sur les 30 derniers jours, conserve celles qui se sont terminées, et les répartit en une moitié plus ancienne et une moitié plus récente selon leur heure de début. Il signale le workflow lorsque le temps médian de la moitié plus récente dépasse d’au moins 25 % et d’au moins 30 secondes celui de la moitié plus ancienne, et que l’exécution plus récente a pris plus de temps dans au moins 85 % des appariements d’une exécution récente avec une exécution plus ancienne. Le temps est celui des étapes additionnées, comme pour une exécution lente. Weave a besoin d’au moins 12 exécutions terminées réparties sur au moins 14 jours ; un workflow qui s’exécute plus d’environ 20 fois en deux semaines n’est donc pas vérifié. Les exécutions en échec et les exécutions arrêtées ne sont pas comptées ; une exécution qui a continué après une étape en échec l’est. Le constat nomme jusqu’à trois étapes que vous pouvez ouvrir dont le temps médian a le plus augmenté, et sa phrase reste identique tant que le ralentissement dure, de sorte que vous n’êtes pas prévenu de nouveau après chaque exécution.

• Lignes cibles différentes des exécutions précédentes. Une étape dont les tables de sortie contenaient beaucoup plus ou beaucoup moins de lignes après sa dernière exécution qu’après ses exécutions précédentes dans ce workflow, selon la même mesure (et d’au moins une ligne). Le décompte correspond à ce que contiennent les tables ; une étape qui ajoute des lignes est donc jugée sur le total croissant. Une étape présente dans plusieurs workflows est jugée séparément dans chacun.

• Jointure ayant dupliqué plus de lignes que d’habitude. Une jointure interne, gauche ou droite qui a écrit plus de lignes pour chaque ligne de sa table principale qu’après ses exécutions antérieures dans ce workflow — plus de deux écarts types au-dessus de leur moyenne, et d’au moins 5 % de celle-ci. La table principale est la Table A pour une jointure interne ou gauche et la Table B pour une jointure droite. Plus d’une ligne écrite par ligne de la table principale signifie que certaines de ses clés de jointure apparaissent sur plus d’une ligne de l’autre table, si bien que les lignes qui les portent ont été écrites plusieurs fois. Weave ne signale qu’une valeur supérieure à 1,00, et seulement lorsqu’elle dépasse le niveau habituel de la jointure ; une jointure qui écrit volontairement plusieurs lignes par ligne n’est donc signalée que si ce nombre augmente. Pour une jointure interne, seules les clés qui se répètent dans la Table B sont vues. Une jointure ayant moins de quatre exécutions antérieures qui ont enregistré les lignes de sa table principale est signalée comme non vérifiée.

  Une jointure qui agrège, ou qui utilise Distinct, un découpage (Limit) ou un Secondary Filter, est signalée comme non vérifiée, car chacun modifie lui-même le nombre de lignes. Il en va de même d’une jointure dont la table principale n’a aucun nombre de lignes enregistré, comme une vue. Les lignes de la table principale sont celles enregistrées lors de sa dernière écriture, avant que le filtre de l’étape ne s’y applique. Un filtre qui conserve une part différente de ses lignes à chaque exécution fait aussi bouger la valeur, et peut être signalé. Une modification apportée à la table principale d’une autre manière, ou par une étape qui s’exécute en même temps, n’est pas vue. Les jointures externes complètes, croisées et multi-tables ne sont pas vérifiées, et un Lookup ne peut pas écrire une ligne plus d’une fois.

• Valeurs vides différentes des exécutions précédentes. Une colonne de la table de sortie d’une étape qui s’est retrouvée vide dans une part de ses lignes beaucoup plus grande ou plus petite qu’après les exécutions précédentes de l’étape — à plus de deux écarts types de la part habituelle, et à au moins cinq points de pourcentage de celle-ci. Chaque table qu’une étape écrit est jugée sur ses propres lignes.

• L’importation n’a trouvé aucun fichier. Une étape d’importation dont l’exécution terminée la plus récente n’a trouvé aucun fichier au chemin qu’elle lit. L’étape se termine par un avertissement au lieu d’échouer, et crée sa table cible vide ou ne charge rien, si bien que les étapes suivantes n’ont rien à lire en provenance de celle-ci. Le constat nomme le workflow et le chemin, ne requiert aucune exécution antérieure, et disparaît dès qu’une exécution trouve des fichiers. Une étape présente dans plusieurs workflows est jugée séparément dans chacun, et dans un workflow que vous ne pouvez pas ouvrir, le chemin n’est pas affiché. Weave ne peut pas distinguer un dossier vide à dessein d’un fichier manquant : si un dossier vide est normal à cet endroit, un Architecte du projet peut marquer le constat comme attendu, et Weave cesse de le signaler pour cette étape dans ce workflow, quel que soit le chemin. Une exécution enregistrée avant l’existence de ce contrôle ne conserve pas la formulation de l’avertissement ; son étape est donc signalée comme non vérifiée jusqu’à sa prochaine exécution.

Fins de mois et jours de la semaine. Pour un workflow ou une étape qui s’exécute au plus une fois par jour, une exécution que ces contrôles signaleraient est dispensée lorsqu’elle est conforme à au moins quatre exécutions antérieures du même type de jour, sur les 180 derniers jours, qui ne varient pas davantage, compte tenu de leur taille, que ses exécutions antérieures des autres jours. Les types de jour sont le dernier jour d’un mois, le premier jour d’un mois, et sinon le même jour de la semaine. Ainsi, un chargement de fin de mois toujours volumineux, ou un chargement toujours léger le lundi, n’est pas signalé lorsque ces exécutions sont plus régulières, compte tenu de leur taille, que celles des autres jours. Le calendrier ne fait jamais que dispenser une exécution : il n’en signale jamais une que ces contrôles accepteraient. Les jours sont comptés en UTC, et les jours fériés et calendriers de jours ouvrés ne sont pas pris en compte. Un workflow ou une étape qui s’exécute plus d’une fois dans une journée, une exécution en échec et sa réexécution comprises, est comparé à ses exécutions antérieures comme auparavant.

Une base de référence requiert au moins quatre exécutions précédentes. Avec moins, le workflow est signalé comme non vérifié pour sa durée d’exécution, et ses étapes comme non vérifiées pour leurs lignes et leurs valeurs vides, chacun indiquant combien d’exécutions terminées il a eues, au lieu d’être jugé sur trop peu de données. Une étape qui écrit une table mais dont les exécutions enregistrées ne portent aucun décompte de valeurs vides est elle aussi signalée comme non vérifiée pour celles-ci. Une étape qui n’écrit aucune table, comme une étape qui envoie un e-mail ou exporte un fichier, n’est pas vérifiée pour ses lignes ni pour ses valeurs vides. Un workflow qui ne s’est pas exécuté au cours des 30 derniers jours est signalé comme non vérifié, tout comme celui dont l’historique d’exécution n’a pas pu être lu — aucun des deux n’est déclaré sain. Dans un projet où l’Accès aux lignes est déclaré, les contrôles des lignes, des jointures, des valeurs vides et de la répartition des valeurs ne s’appliquent pas à une personne dont les lectures sont filtrées : chacun est mesuré sur la table entière, si bien qu’un constat lui apprendrait des choses sur des lignes situées au-delà de son droit d’accès. Consultez Nombres de lignes et tailles des tables.

Ce que la dernière exécution d’une étape a modifié. Pour chaque table écrite par la dernière exécution d’une étape, Weave compare la table telle que l’exécution l’a laissée avec la table telle qu’elle était avant le début de l’exécution ; il n’a donc besoin d’aucun historique d’exécutions antérieures.

• Values spread unlike before the last run. Une colonne dont les valeurs se répartissent sur leur plage de façon très différente après l’exécution et avant celle-ci. Le constat donne un score de décalage : 0 signifie que la répartition n’a pas changé, et 0,25 ou plus est un changement important, seuil à partir duquel Weave le signale. Seules les colonnes contenant des nombres décimaux sont comparées. Les colonnes d’entiers sont généralement des codes, des périodes ou des indicateurs, comme un numéro de compte ou un mois, et leur répartition change chaque fois que de nouvelles périodes sont chargées. Les valeurs vides ne font pas partie de la répartition ; le contrôle des valeurs vides ci-dessus les couvre.

« Avant l’exécution » désigne la dernière version de la table qui contenait des lignes. Une version laissée vide par une exécution qui a échoué en cours de route est ignorée, si bien que la première bonne exécution après un échec est comparée aux dernières bonnes données.

L’exécution d’une étape est signalée comme non vérifiée, avec la raison, lorsqu’une table qu’elle a écrite :

• a l’Accès aux lignes déclaré sur ses colonnes ;
• contenait plus de 5 000 000 de lignes avant ou après l’exécution ;
• a pris plus de 10 secondes à comparer ;
• ne conserve plus sa version d’avant l’exécution — certains lakehouses conservent les versions antérieures d’une table pendant 7 jours, de sorte qu’une table réécrite moins d’une fois par semaine n’a rien à quoi se comparer ; ou
• a été remplie pour la première fois par cette exécution.

Un projet dont le lakehouse ne conserve aucun historique de versions n’est pas du tout jugé sur ce contrôle.

Valeurs laissées vides par une conversion de type. Chaque colonne qu’écrit une étape Extract a un type, tel que texte, entier ou date, et l’étape convertit chaque valeur dans ce type. Sur un lakehouse StarRocks, une valeur qui ne peut pas être convertie, comme N/A placé dans une colonne d’entiers, est stockée vide, et l’exécution se termine sans erreur. Après l’exécution d’une étape Extract sur StarRocks, Weave compte, pour chaque colonne dont la conversion pourrait perdre des valeurs, les valeurs entrantes qui n’étaient pas déjà vides et combien d’entre elles sont ressorties vides, et signale chaque colonne où c’est le cas. Le constat donne le décompte et le type de la colonne. Il juge la dernière exécution terminée de l’étape dans chaque workflow, et n’a donc besoin d’aucune exécution antérieure.

• Les valeurs qui étaient déjà vides en entrée ne sont pas comptées. Le texte vide l’est, car il est stocké vide dans une colonne numérique ou de date.
• Une colonne dont la conversion ne peut perdre aucune valeur, comme des entiers placés dans une colonne décimale, n’est pas comptée, pas plus qu’une colonne sans valeur vide après l’exécution.
• Si le décompte prend plus de 30 secondes, ou si les lignes que Weave compte ne correspondent pas aux lignes écrites par l’étape, l’exécution est signalée comme non vérifiée, et Weave recompte lors de la prochaine exécution de l’étape.
• Seules les étapes Extract sur StarRocks sont vérifiées. Une étape qui utilise un Secondary Filter ou qui regroupe selon une expression est signalée comme non vérifiée, tout comme celle qui utilise Distinct ou un découpage (Limit) lorsqu’une colonne pourrait perdre des valeurs, car Weave ne peut pas recompter ses lignes sans la conversion.
• Si l’étape est censée laisser ces valeurs vides, un Architecte du projet peut marquer le constat comme attendu.
• Comme les contrôles des lignes et des valeurs vides, il ne s’applique pas à une personne dont les lectures sont filtrées par l’Accès aux lignes.

Événements planifiés. Pour un workflow doté d’événements planifiés, Weave compare chaque événement aux exécutions qu’il a démarrées et au job du cluster qui le déclenche. Chaque heure est prise dans le fuseau horaire propre à l’événement, et un déclenchement est jugé 15 minutes après son échéance, pour laisser à son job le temps de démarrer.

• Scheduled event timetable not valid. Un événement activé dont la planification ne peut pas être lue.
• Scheduled run did not start. Un événement activé qui est arrivé à échéance sans démarrer d’exécution — depuis qu’il en a démarré une pour la dernière fois, ou depuis son enregistrement s’il n’en a jamais démarré. Lorsque le cluster permet de le savoir, Weave précise si le cluster n’a jamais déclenché l’événement ou si le job qu’il a déclenché a échoué. Le constat nomme la dernière exécution démarrée par l’événement, ou l’heure de son enregistrement, de sorte qu’il reste un seul constat tant que l’événement reste défaillant de la même façon. Un événement enregistré depuis l’échéance de son déclenchement n’est pas jugé sur ce déclenchement.
• Scheduled event came due during a run. Un événement arrivé à échéance alors que le workflow était encore en cours d’exécution, si bien qu’aucune exécution n’a démarré à ce moment-là. Un événement planifié ne démarre jamais une seconde exécution d’un workflow déjà en cours d’exécution ; ce cas est signalé une fois, afin qu’une planification plus serrée que les exécutions du workflow ne perde pas de déclenchements à l’insu de tous.
• Scheduled event out of step with the cluster. Un événement et son job dans le cluster qui ne concordent pas : un événement activé sans job, ou dont le job est suspendu ; un événement désactivé dont le job n’est pas suspendu ; ou un job réglé sur une planification ou un fuseau horaire différents de ceux que montre l’événement. Lorsque le cluster ne peut pas être lu, le workflow est signalé comme non vérifié pour ses événements planifiés.

Un événement qui a cessé de démarrer des exécutions n’a aucune fin d’exécution pour vous le signaler ; il apparaît donc dans l’onglet Weave plutôt que sous forme de message.

Tables écrites selon une planification. Pour une table qu’écrit un workflow doté d’un événement planifié activé, Weave vérifie que la table a été écrite depuis la dernière échéance de la planification. Une table est considérée comme écrite lorsqu’une étape qui l’écrit se termine. Weave ne regarde pas les données de la table ; il ne voit donc pas un chargement effectué en dehors des étapes du projet. Comme pour les contrôles des événements planifiés, chaque planification est lue dans le fuseau horaire de son événement et jugée 15 minutes après son échéance. Weave ne vérifie que les tables que votre rôle vous permet de voir ; sans le rôle analyze.table.read, il ne vérifie aucune table, et sa première ligne ne compte que les étapes et les workflows.

• Table not written on schedule. Une table qu’aucune étape n’a écrite depuis qu’un workflow qui l’écrit est arrivé à échéance selon sa planification. Une écriture par n’importe quelle étape compte, y compris dans un autre workflow ou lors d’une exécution que vous avez lancée vous-même. Le constat donne l’heure de la dernière écriture plutôt que son ancienneté. Une exécution en échec compte comme une absence d’écriture ; les tables d’un workflow planifié en échec sont donc signalées ici aussi bien que sous Échec de la dernière exécution.

Weave signale une table comme non vérifiée, avec la raison, plutôt que comme non écrite, lorsque :

• un workflow qui l’écrit est en cours d’exécution, en file d’attente, ou vient de se terminer et ses résultats ne sont pas encore enregistrés ;
• une étape qui l’écrit a été ignorée lors d’une exécution depuis l’échéance de la planification, soit par ses propres conditions, soit parce qu’elle n’avait rien à faire, comme une importation dont les fichiers n’avaient pas changé ;
• une étape qui l’écrit peut être ignorée sans que cela soit consigné : elle se trouve dans un workflow Standard avec une condition qui saute vers une autre étape, ou dans un workflow Standard série avec une étape qui passe à une autre étape en cas d’échec, ou elle se trouve dans un conteneur doté de conditions ou dans une boucle qui peut s’exécuter zéro fois ;
• le workflow a terminé une exécution depuis son échéance, mais l’enregistrement de l’étape d’écriture de cette exécution est manquant ;
• une étape quelque part dans le projet choisit la table qu’elle écrit avec une variable dont Weave ne peut pas déterminer la valeur, de sorte qu’elle pourrait écrire cette table ;
• la planification s’exécute moins souvent que tous les 180 jours, soit la limite de l’historique d’exécution de Weave ; ou
• la planification d’un workflow n’est pas valide, ou l’historique d’exécution ne peut pas être lu.

Une table n’est pas du tout vérifiée lorsque :

• elle n’a pas de seuil de fraîcheur (voir ci-dessous) et qu’aucun workflow doté de son propre événement planifié activé ne l’écrit. Un workflow qu’un autre workflow exécute, via une étape Exécuter le workflow ou Macro ou en tant que workflow placé à l’intérieur de celui-ci, ne compte que par sa propre planification ;
• les seules étapes qui l’écrivent sont désactivées, se trouvent dans un conteneur désactivé, ou se trouvent à un point d’arrêt ou après celui-ci ; ou
• c’est une vue.

Le deuxième cas ne s’applique pas à l’intérieur d’une boucle qui s’exécute : une boucle exécute chaque étape qu’elle contient, même désactivée, située dans un conteneur désactivé, ou à un point d’arrêt ou après celui-ci.

Un événement planifié enregistré après sa dernière échéance n’est pas jugé avant sa prochaine échéance.

Un workflow dont les exécutions durent plus longtemps que l’intervalle de sa planification ignore les déclenchements qui arrivent à échéance pendant qu’il s’exécute ; entre deux exécutions, ses tables peuvent donc être signalées comme non écrites ; Scheduled event came due during a run en signale la cause.

Lorsque l’étape qui a écrit une table en dernier est une étape à laquelle vous n’avez pas accès, le constat indique « a step you don’t have access to » et donne tout de même l’heure de l’écriture. « 180 days » dans un constat correspond à la profondeur de l’historique d’exécution de Weave, et non à un fait concernant la table.

Tables dotées d’un seuil de fraîcheur. Un seuil de fraîcheur est le nombre maximal d’heures pouvant s’écouler entre deux écritures d’une table, de 1 à 4 320 (180 jours). Une table dotée d’un seuil est jugée par rapport à celui-ci plutôt que par rapport aux planifications des workflows qui l’écrivent. Cela vous permet de définir une borne plus souple ou plus stricte que celle d’une planification, et de contrôler une table qu’aucun workflow planifié n’écrit. Comme pour les planifications, une table est considérée comme écrite lorsqu’une étape qui l’écrit se termine.

• Table not written within its set time. Aucune étape n’a écrit la table depuis plus longtemps que son seuil. Le constat donne l’heure de la dernière écriture et le seuil.

Weave signale une table dotée d’un seuil comme non vérifiée, avec la raison, plutôt que comme non écrite, lorsque :

• un workflow qui l’écrit est en cours d’exécution, en file d’attente, ou vient de se terminer et ses résultats ne sont pas encore enregistrés ;
• un workflow qui l’écrit a démarré une exécution après le dépassement du seuil et l’a terminée, mais l’enregistrement de l’étape d’écriture de cette exécution est manquant ;
• une étape quelque part dans le projet choisit la table qu’elle écrit avec une variable dont Weave ne peut pas déterminer la valeur, de sorte qu’elle pourrait écrire cette table ;
• aucune étape du projet ne l’écrit, comme une table que vous chargez à la main, si bien que Weave n’a aucune écriture à partir de laquelle mesurer ; ou
• l’historique d’exécution ne peut pas être lu.

Une étape ignorée ne rend pas non vérifiée une table dotée d’un seuil : la table n’a toujours pas été écrite depuis plus longtemps que son seuil. Une vue ne peut pas avoir de seuil, et transformer une table en vue supprime son seuil. Une copie d’une table, ou une table créée à partir d’un de ses instantanés, démarre sans seuil.

Pour définir un seuil, sélectionnez la table dans la liste Tables du projet et choisissez Afficher/modifier les détails de la table. Sous Fraîcheur, sélectionnez Warn if this table isn’t written for more than, saisissez le nombre d’heures, puis cliquez sur Update. Décochez la case pour supprimer le seuil. Tant qu’aucun seuil n’est défini, la case nomme les workflows planifiés dont les planifications servent à juger la table, ou indique qu’aucun workflow que vous pouvez ouvrir ne l’écrit selon une planification. Fraîcheur n’apparaît pas pour une vue ni pour une table en cours de création, ni sans le rôle analyze.workflow.read, et sa modification requiert analyze.table.write.

Vous pouvez aussi demander à un assistant IA connecté via PlaidCloud MCP de définir le seuil de fraîcheur de la table (son outil est table_upsert, avec freshness_max_age_hours), ou appeler l’API de la plateforme :

PUT /rest/v1/analyze/weave/freshness
{"project_id": "<project>", "table_id": "<table>", "freshness_max_age_hours": 24}

Envoyez null à la place du nombre pour l’effacer ; la table est alors de nouveau jugée sur les planifications des workflows qui l’écrivent. GET /rest/v1/analyze/weave/freshness?project_id=<project>&table_id=<table> renvoie le seuil et scheduled_writers, les workflows planifiés dont les planifications servent à juger la table lorsqu’elle n’a pas de seuil. La lecture d’un seuil requiert les rôles analyze.table.read et analyze.workflow.read, et sa définition requiert analyze.table.write et analyze.workflow.read. Vous ne pouvez définir un seuil que sur une table que votre rôle vous permet de voir, et pas tant que le projet est verrouillé.

Tables lues par un workflow, écrites depuis. Pour un workflow qui lit une table qu’écrit un autre workflow, Weave vérifie qu’aucun autre workflow n’a écrit dans la table depuis la dernière lecture du workflow. Une table est considérée comme lue ou écrite par une étape qui la nomme comme entrée ou sortie et qui s’est terminée lors d’une exécution. Weave lit ce qu’enregistre l’historique d’exécution, pas les données de la table.

• Reads a table written to since its last read. Un workflow a lu une table pour la dernière fois lors d’une de ses exécutions, et un autre workflow a écrit dans cette table depuis, de sorte que ses résultats peuvent être périmés. Le constat nomme l’exécution qui a lu la table en dernier et les workflows qui y ont écrit. Un workflow doté d’un événement planifié activé, ou qu’exécute un autre workflow qui en a un, n’est signalé qu’une fois qu’une planification qui l’exécute est arrivée à échéance après l’écriture ; un workflow qu’aucune planification n’exécute est signalé immédiatement.

Ne sont pas comptées comme des écritures depuis la lecture :

• une écriture par le workflow lui-même, y compris une écriture effectuée pendant son exécution par un workflow qu’il exécute via une étape Workflow : exécuter, Workflow : boucle ou Workflow : exécution conditionnelle ;
• une table que le workflow écrit lors d’une exécution avant qu’une étape de cette exécution la lise, comme une table de transit, sauf si l’écriture provient d’une étape Table : ajouter ou Table : upsert, ou d’une étape Table : suppression sur place avec un filtre, qui conservent les autres lignes de la table ; et
• une écriture effectuée avant le dernier enregistrement de l’étape qui l’a réalisée, car l’étape a pu écrire alors dans une autre table.

Weave signale le workflow comme non vérifié, avec la raison, plutôt que comme en retard, lorsque :

• il est en cours d’exécution, ou vient de se terminer et ses résultats ne sont pas encore enregistrés ;
• une étape qui lit la table a été ignorée lors d’une exécution postérieure à l’écriture ;
• la planification qui l’exécute n’est pas valide ;
• aucune de ses exécutions récentes n’a fini de lire la table, alors qu’un autre workflow y a écrit ou a pu y écrire ;
• une étape qui lit la table a été enregistrée depuis le début de sa dernière exécution réussie, si bien que Weave ne peut pas savoir si cette exécution l’a lue. Tout enregistrement compte, même s’il ne change rien à ce que lit l’étape ;
• l’une de ses étapes lit des tables que Weave ne peut pas déterminer à partir des paramètres de l’étape, comme une étape IA : étape LLM, une étape Report, une étape Exécution : Python à distance, ou une étape qui lit plusieurs tables et en trouve une par recherche, comme peut le faire une étape Table : union distincte ou Table : union complète ; choisit une table avec une variable ; désigne une table par un nom que porte plus d’une table ; lit une vue ; ou lit une table d’un autre projet ;
• une table qu’il lit est aussi écrite par une macro, dont Weave ne voit pas les exécutions, ou par une étape d’un autre workflow qui s’est exécutée depuis et qui choisit la table qu’elle écrit avec une variable, la désigne par un nom que porte plus d’une table, ou écrit des tables que Weave ne peut pas déterminer ; ou
• son historique d’exécution ne peut pas être lu.

Un workflow sans exécution au cours des 30 derniers jours n’est pas vérifié de cette façon.

Ce que ce contrôle ne voit pas :

• les lectures et écritures plus anciennes que l’historique d’exécution que lit Weave, soit les 30 derniers jours et, pour chaque workflow, ses 20 dernières exécutions ;
• la condition d’une étape qui contrôle une table, ce qui ne compte pas comme une lecture ;
• une écriture par un autre workflow dans une table à laquelle le workflow ajoute des lignes puis qu’il lit lors de la même exécution, sauf s’il les ajoute avec une étape Table : ajouter ou Table : upsert ;
• une lecture antérieure par une étape lorsqu’une autre étape du workflow a lu la même table plus récemment ;
• une écriture à l’intérieur d’une macro par une étape qui choisit sa table avec une variable ou écrit des tables que Weave ne peut pas déterminer ; et
• les écritures effectuées avant le dernier enregistrement de l’étape d’écriture, même lorsque l’enregistrement n’a rien changé à ce qu’elle écrit, jusqu’à la prochaine exécution de son workflow.

Sans le rôle analyze.table.read, aucun workflow n’est vérifié de cette façon. Lorsqu’un workflow ou une table qui a écrit ou a été lu est un élément auquel vous n’avez pas accès, le constat indique « a workflow you don’t have access to » ou « a table you don’t have access to », sans préciser combien.

Une étape dont le type n’a aucune règle dans Weave est signalée comme non couverte, et non comme saine.

Tables reposant sur une exécution en échec. Lorsque la dernière exécution d’un workflow a échoué avant la fin d’une étape qui écrit une table, cette table contient toujours ses données antérieures, ou seulement une partie des nouvelles données. Weave suit la table à travers les étapes qui la lisent et les tables qu’elles écrivent, dans tous les workflows du projet, et signale ce qui repose sur elle :

• Reads a table a failed run didn’t finish. Un workflow lit la table, ou une table construite à partir d’elle, quel que soit le nombre d’étapes intermédiaires. Le constat nomme la table qu’il lit, la table que l’exécution en échec n’a pas terminée, et le workflow qui a échoué, avec l’heure de début de cette exécution.
• Shows a table a failed run didn’t finish. Un tableau de bord comporte un graphique sur une table publiée qui est cette table, ou qui est construite à partir d’elle, ou sur un jeu de données SQL qui lit une telle table. Weave lit la logique de modèle d’un jeu de données SQL après en avoir retiré les balises ; une table située dans une branche qui n’est jamais empruntée peut donc compter. Le constat concerne le tableau de bord, et il est listé dans l’onglet Weave de chaque projet dont ses graphiques montrent les tables.

Weave a remarqué le tableau de bord « Board Pack » : il montre la table « Margin », construite à partir de la table « Sales », que le workflow « Import Sales » n’a pas fini d’écrire lors de sa dernière exécution, le 27 oct. à 09:15 UTC, si bien que ses graphiques peuvent afficher des données anciennes ou incomplètes

Chaque workflow en échec fait l’objet de son propre constat, qui disparaît dès que la dernière exécution de ce workflow n’échoue plus. Le workflow qui a échoué n’est pas informé ici de sa propre exécution ; son constat Échec de la dernière exécution s’en charge.

Ne sont pas comptées comme une table que l’exécution en échec n’a pas terminée :

• une table dont l’étape a été ignorée volontairement, comme une étape dont la condition n’était pas remplie, une étape désactivée, ou une importation qui a ignoré un fichier déjà chargé ;
• une table dont une exécution peut sauter l’étape. Dans un workflow qui n’est pas avancé, le goto d’une condition, ou le goto d’une étape en échec dans un workflow série, couvre chaque étape. Dans un workflow avancé, il couvre une étape située dans un conteneur d’exécution qui vérifie des conditions ou après celui-ci, ainsi qu’une étape dans une boucle ;
• une table qu’un autre workflow a remplacée en totalité après le début de l’exécution en échec, plutôt que d’y ajouter des lignes ; et
• pour un workflow, une table qu’il a lui-même remplacée avant de la lire, lors de sa dernière exécution qui l’a lue.

Un workflow en cours d’exécution n’est pas jugé tant que son exécution n’est pas terminée. Lorsque l’historique d’exécution ne peut pas être lu, Weave signale ces cas comme non vérifiés plutôt que sains.

Ce que ce contrôle ne voit pas :

• une exécution qui s’est terminée sans qu’aucune étape enregistre d’échec, comme celle dont le serveur s’est arrêté, et une exécution que quelqu’un a arrêtée ;
• une table qu’une étape choisit avec une variable, désigne par un nom que porte plus d’une table, lit via une vue ou lit depuis un autre projet ;
• un graphique de tableau de bord sur une requête enregistrée, ou sur un jeu de données SQL dont Weave ne peut pas lire le SQL une fois sa logique de modèle retirée ;
• une table dont le nom est construit par un modèle ;
• une table qu’un jeu de données SQL désigne sans schéma, sauf si le schéma propre au jeu de données est le schéma de reporting du projet ;
• tout jeu de données SQL d’un projet sur un entrepôt de données Snowflake ou Databricks ;
• une table qui n’est pas publiée, et les applications Panel ; et
• les exécutions plus anciennes que l’historique d’exécution que lit Weave, soit les 30 derniers jours et, pour chaque workflow, ses 20 dernières exécutions.

Vous ne voyez le constat d’un tableau de bord que pour un tableau de bord que vous pouvez ouvrir. Sans le rôle analyze.table.read, aucun des deux contrôles ne s’exécute.

Totaux de métriques inhabituels. Chaque jour, Weave lit les métriques de votre projet et signale celle dont la dernière période terminée s’est fortement écartée de la normale, en nommant l’élément, tel qu’un client ou une usine, à l’origine du changement. Consultez Totaux de métriques inhabituels.

Revue d’un workflow

Une revue contrôle un workflow avant que vous vous y fiiez. Elle exécute les contrôles de Weave sur le workflow et ses étapes, y compris les étapes de tout workflow qu’il exécute, ainsi que trois contrôles supplémentaires que Weave n’exécute que lors d’une revue, car ils lisent davantage que ce que l’onglet Weave peut se permettre de lire à chaque ouverture :

• Une allocation qui alimente ses propres entrées. Pour chaque étape d’allocation que le workflow exécute, si ce qu’elle écrit revient — à travers n’importe quelles étapes, dans n’importe quel workflow — dans la table qu’elle alloue ou dans sa table d’inducteurs. Lorsque c’est le cas, le montant que l’étape alloue, ou la façon dont elle le répartit, dépend de ce qu’elle a alloué lors d’une exécution antérieure. Weave nomme les étapes que la boucle traverse et vous demande de vérifier si la boucle est voulue. Une boucle qui ne traverse aucune étape d’allocation, comme un chargement incrémental qui lit la table à laquelle il ajoute des lignes, n’est pas signalée.
• Tables et colonnes d’inducteurs d’allocation. Si la table d’inducteurs qu’utilise une étape d’allocation existe et possède chaque colonne que l’étape y lit. Une colonne d’inducteur que l’étape remplit avec une constante ou une expression n’est pas recherchée. Une table d’inducteurs construite ailleurs est vérifiée telle qu’elle est actuellement ; lorsqu’une étape de ce workflow la construit, ses colonnes ne sont pas connues avant l’exécution de cette étape, si bien que Weave signale l’allocation comme non vérifiée plutôt que réussie. Il la signale aussi comme non vérifiée lorsque l’étape choisit sa table d’inducteurs avec une variable ou un chemin de dossier, lorsque le workflow est une macro, et lorsque votre rôle ne peut pas voir la table.
• Sécurité au niveau des lignes sur une colonne renommée. Pour chaque table que le workflow écrit, si elle possède une colonne marquée avec la dimension qu’utilise un attribut de sécurité au niveau des lignes mais qui ne porte pas le nom de cet attribut. La sécurité au niveau des lignes ne filtre que sur les colonnes nommées d’après ses attributs ; elle ne filtre donc pas sur cette colonne. Ce contrôle requiert le rôle Architecte sur le projet ; pour tout autre utilisateur, la revue indique qu’il n’a pas été effectué, et il en va de même pour une table que le workflow désigne avec une variable ou un chemin de dossier.

Une revue s’ouvre en disant ce qu’elle a trouvé et sur quelle part du workflow, et ne se termine jamais sur un certificat de bonne santé :

Weave found 2 problems in the workflow "Q3 Close". It couldn't finish checking 1
of its 8 steps (listed below), so it may have missed problems in those. See below
for what these checks don't cover.

Weave noticed the step "Allocate rent": it uses the column "sq_ft" from its driver
table "Floor space", which doesn't have that column. Pick a column the table has,
or add "sq_ft" to it.
Weave noticed the step "Allocate IT cost": its output flows back into its driver
table "IT driver" through "Build IT driver", so how it spreads what it allocates
depends on what it allocated on an earlier run. Check whether that loop is
intended.
Weave hasn't checked the step "Allocate IT cost" — whether its driver table
"IT driver" has the columns it uses: the step "Build IT driver" builds that
table, so its columns aren't known until that step runs.

Les étapes que votre rôle ne peut pas voir comptent dans le total, et la revue indique qu’elle ne les a pas vérifiées.

Une revue liste ce qu’elle ne vérifie pas. Elle n’exécute pas les contrôles de Weave sur les tables — si une table écrite selon une planification est en retard, et si une table que lit le workflow a été écrite depuis — qui lisent l’ensemble du projet et s’exécutent dans l’onglet Weave. Pour un workflow comportant des étapes d’allocation, elle ne vérifie pas si chaque montant alloué trouve une ligne d’inducteur ou un membre de dimension correspondant, si les tables source et d’inducteurs contiennent des chiffres au même niveau de détail, ni les boucles qui traversent une étape désignant sa table dans du SQL ou avec une variable.

Pour passer un workflow en revue, ouvrez-le sur son canevas ou dans sa grille Étapes et choisissez Vérifier. Le bouton est disponible pour les personnes qui peuvent modifier le workflow et lire les tables du projet. La fenêtre Vérification Weave affiche, dans l’ordre :

• les lignes d’ouverture de la revue ;
• Résumé (rédigé par l’IA), lorsque la revue a un résumé ;
• les Problèmes de la revue, puis ce qu’elle indique sous Vérification impossible. Un problème auquel le résumé renvoie est marqué Dans le résumé, et Aller à à côté du constat d’une étape sélectionne cette étape là où vous avez choisi Vérifier ;
• Ce que cette vérification ne couvre pas, toujours en dernier.

Choisir de nouveau Vérifier lance une nouvelle revue dans la même fenêtre.

Vous pouvez aussi demander à un assistant IA connecté via PlaidCloud MCP de passer un workflow en revue — son outil est workflow_review — ou appeler l’API de la plateforme. Une revue requiert un accès en lecture aux étapes, workflows et tables du projet. Les trois contrôles ci-dessus n’apparaissent pas dans l’onglet Weave ; Weave ne les exécute que lors d’une revue.

Dans la fenêtre Vérification Weave et via l’API de la plateforme, une revue qui trouve des problèmes comporte aussi un résumé d’une ou deux phrases rédigé par l’IA intégrée de PlaidCloud, ainsi que jusqu’à trois de ses problèmes à examiner en premier. L’IA ne voit que les problèmes de la revue. Avant que le résumé soit renvoyé, les problèmes auxquels il renvoie doivent être ceux de la revue, tout nom qu’il cite et tout chiffre qu’il écrit doivent figurer dans ces problèmes, et il ne peut pas employer une formule telle que « aucun autre problème ». Un résumé qui échoue à ces contrôles est écarté, et la revue revient sans résumé. Une revue sans problème n’a pas de résumé. Via un assistant IA, la revue n’a pas de résumé ; l’assistant lit lui-même les constats.

Être prévenu à la fin d’une exécution

Lorsque l’exécution d’un workflow se termine, Weave examine ce workflow et prévient le responsable de chaque problème — consultez Affecter un responsable à un constat — des problèmes qu’il relève pour ce workflow, qu’ils concernent ses exécutions ou la configuration enregistrée de ses étapes, et que ce responsable n’a pas encore lus dans l’onglet Weave du projet, par un message dans l’application. Un problème sans responsable, ou dont le responsable ne peut plus le voir, est adressé à la personne à qui appartient l’exécution : celle qui l’a démarrée ou, pour une exécution planifiée, celle qui a enregistré la planification en dernier. Chaque problème n’est mentionné qu’une fois. Tant que vous ne l’avez pas lu dans l’onglet Weave, les exécutions suivantes ne le mentionnent pas de nouveau, si bien qu’un Workflow Loop qui exécute de nombreux workflows ne remplit pas votre écran de répétitions. Le compteur du bouton Weave le conserve jusqu’à ce que vous l’ayez lu.

Le message reste affiché 30 secondes et comporte un lien Ouvrir Weave, qui ouvre l’onglet Weave du projet sur les constats concernant le workflow qui s’est exécuté. Cliquez n’importe où ailleurs sur le message pour le fermer.

Tant qu’un message Weave concernant un projet est affiché, un nouveau message sur le même projet s’y joint au lieu d’apparaître en dessous. Le message affiche la phrase la plus récente, suivie d’une ligne telle que Plus 2 more in this project., et reste affiché 30 secondes à partir du plus récent. Lorsque les messages concernent des workflows différents, Ouvrir Weave ouvre l’ensemble de l’onglet Weave. Ainsi, des workflows qui échouent à quelques instants d’intervalle vous donnent un seul message plutôt qu’un message chacun. Un rappel de préparation apparaît toujours seul.

Une fois que vous avez lu un problème, il n’est mentionné de nouveau que lorsque ce qu’il dit change. Un constat d’exécution décrit l’exécution dont il provient — sa date, sa durée, ses décomptes — si bien qu’un workflow qui échoue chaque nuit est mentionné de nouveau au premier échec qui suit votre lecture du précédent. Un problème de configuration dit la même chose d’une exécution à l’autre ; une fois que vous l’avez lu, il n’est donc pas répété à chaque exécution.

Une exécution arrêtée n’envoie rien, quelle que soit la personne qui l’a arrêtée. Un workflow exécuté par une étape Macro Run ou Macro Concurrent n’envoie rien de lui-même, et cet appel n’est pas compté parmi ses exécutions ; un workflow démarré par une étape Exécuter le workflow ou Workflow Loop est une exécution de ce workflow comme n’importe quelle autre. Ce que Weave n’a pas pu vérifier n’est jamais envoyé de cette façon, pas plus que les constats sur les tables écrites selon une planification ou sur les tables d’un workflow écrites depuis sa lecture : Weave vous en informe entre les exécutions. Consultez Être prévenu entre les exécutions.

Être prévenu n’est pas la même chose qu’avoir lu : une alerte ne marque pas le constat comme lu dans l’onglet Weave, pas plus que le fait de suivre son lien Ouvrir Weave.

Chaque problème dont un message vous informe est ajouté au compteur du bouton Weave dans l’en-tête. Consultez Le bouton Weave dans l’en-tête.

Être prévenu entre les exécutions

Certains problèmes apparaissent alors que rien ne s’exécute : une table qui n’a pas été écrite selon sa planification ou dans son seuil de fraîcheur ; une exécution planifiée qui n’a pas démarré, ou qui est arrivée à échéance alors que le workflow était encore en cours d’exécution ; un workflow dont les tables ont été écrites par un autre workflow depuis sa dernière lecture ; et un workflow ou un tableau de bord qui repose sur une table qu’une exécution en échec n’a pas terminée. Aucune fin d’exécution ne peut vous en informer ; une fois par heure, Weave contrôle donc chaque projet à leur recherche et prévient le responsable de chaque problème — consultez Affecter un responsable à un constat — par un message dans l’application.

Le contrôle horaire vous informe une seule fois de chacun de ces problèmes, quel que soit le nombre de contrôles qui le trouvent, et son premier contrôle d’un projet vous informe de ceux qui existent déjà, depuis aussi longtemps qu’ils soient là. Il ne vous en informe de nouveau qu’après la disparition puis le retour du problème, ou après que vous l’avez lu et que ce qu’il dit a changé, par exemple une exécution planifiée ultérieure qui n’a pas démarré non plus. Un problème de planification fait aussi partie des contrôles propres d’un workflow, mais une fois que le contrôle horaire vous en a informé, le message de fin de la prochaine exécution du workflow ne le répète pas tant que vous ne l’avez pas lu — consultez Être prévenu à la fin d’une exécution. Plusieurs problèmes dans un même projet arrivent sous la forme d’un seul message, qui les compte et cite le premier :

Weave a remarqué 3 problèmes dans le projet « Finance Close », à commencer par la table « Sales Daily » : l’étape « Load Sales » l’a écrite pour la dernière fois le 14 oct. à 06:00 UTC, et le workflow « Nightly Load » aurait dû s’exécuter selon sa planification depuis lors

Une table qu’écrit plus d’un workflow n’a pas de responsable tant que personne ne lui en affecte un. Lorsqu’elle n’a pas été écrite selon la planification, Weave prévient le responsable de chaque workflow qui devait l’écrire et ne l’a pas fait. Tout autre problème sans responsable n’est pas envoyé ; il est listé dans l’onglet Weave du projet.

Le contrôle s’exécute sous l’identité de chaque responsable ; un message ne nomme donc que ce que votre rôle vous permet de voir. Vous n’êtes prévenu qu’en tant que membre actif du projet dont le rôle vous permet de voir ses étapes et ses workflows, et pour les tables seulement si vous pouvez lire les tables.

Le message reste affiché 30 secondes et comporte un lien Ouvrir Weave, qui ouvre l’onglet Weave du projet, sur le workflow lorsque tous les problèmes du message concernent le même. Un message n’est affiché que pendant que vous êtes connecté, mais chaque problème dont il vous informe est ajouté au compteur du bouton Weave dans l’en-tête ; un problème que vous avez manqué y est donc tout de même compté. Être prévenu ne marque pas un constat comme lu.

Marquer un constat comme lu

Chaque constat porte un identifiant, et vous pouvez le marquer comme lu pour qu’il cesse d’apparaître comme nouveau — dans l’onglet Weave du projet, cliquez sur Marquer comme lu sur sa carte (consultez Marquer les constats comme lus). L’identifiant est dérivé du constat lui-même, si bien qu’un constat que vous avez écarté revient comme nouveau si le problème sous-jacent change — une étape que vous avez marquée comme lue après avoir corrigé une colonne réapparaît si une autre colonne pose problème par la suite.

L’état de lecture vous est propre. Marquer un constat comme lu ne le marque pas comme lu pour les autres membres du projet.

Tant qu’un workflow qui écrit une table en retard est en cours d’exécution, Weave signale plutôt la table comme non vérifiée. Si vous marquez un constat comme lu pendant ce temps et que l’exécution se termine sans écrire la table, son constat revient comme nouveau.

Deux étapes différentes listées deux fois dans un même workflow font deux constats ; en marquer un comme lu laisse donc l’autre non lu. Un workflow sans nom apparaît comme « unnamed workflow », et un contrôle qui n’a pas pu s’exécuter est nommé par son titre, tel que « Échec de la dernière exécution ».

Un résumé périodique

Un résumé périodique est le même rapport réduit à ce que vous n’avez pas encore lu, sur le même ton. Vous pouvez en demander un à tout moment, et vous pouvez le recevoir sous forme de notification dans l’application, avec un lien Ouvrir Weave vers l’onglet Weave du projet.

Les constats que Weave n’a pas pu vérifier font partie d’un résumé périodique comme les autres. Un résumé qui les écarterait discrètement serait exactement le silence rassurant que la troisième réponse existe pour empêcher.