Aller au contenu

Vérifier la préparation avant une clôture

Les jours qui comptent le plus — fin de mois, remise d’une prévision, dossier de conseil d’administration — la question n’est pas « qu’est-ce que Weave a remarqué ? » mais « sommes-nous prêts ? ». Un ensemble de préparation nomme les workflows dont dépend une échéance, et sélectionner l’ensemble répond à cette question pour tous à la fois, dans une seule liste de contrôle qui s’ouvre sur son propre décompte :

11 sur 13 prêts ; 1 pas prêt ; 1 vérification impossible.

Chaque workflow de l’ensemble reçoit l’une de trois réponses, la plus défavorable de ses lignes. Il est Pas prêt dès qu’un contrôle a trouvé un problème ; le problème est listé en dessous, avec les mêmes boutons Corriger, Aller à et Comment Weave le sait que dans l’onglet Weave. Sinon, il est Vérification impossible lorsqu’un contrôle n’avait aucun moyen de le juger, et la raison est écrite en toutes lettres. Il n’est Prêt que si tous les contrôles que Weave a pu exécuter sur lui ont réussi. Rien de ce que Weave n’a pas jugé n’est jamais présenté comme prêt, à une exception près : une dernière exécution disposant de trop peu d’historique antérieur pour être comparée est considérée comme habituelle, comme décrit plus bas.

Un problème que quelqu’un a marqué comme attendu rend tout de même sa ligne Pas prêt, et la ligne précise qu’il a été marqué comme attendu. L’onglet Weave cesse de signaler un tel problème ; la liste de contrôle dit toujours ce qui est vrai.

Les contrôles sont les règles que Weave exécute déjà — sans aucune IA — si bien qu’une liste de contrôle ne coûte rien, quelle que soit la fréquence à laquelle vous la demandez. Pour savoir ce que ces règles lisent et ce que signifient leurs réponses, consultez Ce que Weave vérifie.

  1. Ouvrez l’onglet Weave du projet et cliquez sur Préparation dans la barre d’outils de Constatations.
  2. Cliquez sur Nouveau. Donnez un nom à l’ensemble, par exemple « Clôture de fin de mois », et déplacez les workflows dont il dépend de Workflows du projet vers Workflows de cet ensemble.
  3. Si vous le souhaitez, cochez A une échéance et indiquez l’échéance de l’ensemble, sous forme d’expression cron et du fuseau horaire dans lequel elle est écrite — les mêmes choix que pour un événement planifié. 0 9 5 * * correspond à 09:00 le 5 de chaque mois, et 0 8 * * 1 à 08:00 chaque lundi, dans ce fuseau horaire. Les décalages sont interprétés comme le fait un événement planifié : UTC +0 correspond à l’heure de Londres, heure d’été britannique comprise, et certains autres décalages suivent l’heure d’été d’un lieu situé à ce décalage, tandis que les autres sont fixes. La page Planificateur d’événements indique comment chaque décalage est interprété.
  4. Pour un ensemble avec échéance, sous Tell the owner this many hours before it is due, indiquez combien de temps avant l’échéance Weave doit envoyer son message, de 1 à 168 heures. La valeur par défaut est 24.
  5. Cliquez sur Enregistrer.

Un ensemble appartient au projet, et toute personne disposant de Constatations dans l’onglet Weave du projet peut le vérifier. Seul un Architecte du projet peut créer, modifier ou supprimer un ensemble, et chaque workflow d’un ensemble doit appartenir à ce projet. La dernière personne ayant enregistré un ensemble en est le propriétaire. Deux personnes qui modifient le même ensemble en même temps sont tenues à l’écart l’une de l’autre : le second enregistrement est refusé, l’ensemble est relu, et le formulaire affiche la copie plus récente avec la raison.

Weave ne peut juger qu’une table d’entrée est à jour que si quelque chose indique quand elle aurait dû être écrite : une planification sur le workflow qui l’écrit, ou un seuil de fraîcheur sur la table. Définissez-les d’abord, sinon la première ligne de la plupart des workflows indiquera Vérification impossible.

Sélectionnez un ensemble à gauche. Weave lit l’ensemble du projet — la même lecture que celle de l’onglet Weave — et juge chaque workflow de l’ensemble. Cliquez sur Revérifier après avoir corrigé quelque chose.

Chaque élément affiche le nom du workflow, son verdict et une ligne par contrôle qui s’y applique. Lorsqu’une ligne indique Vérification impossible, la raison est écrite à côté ; voici les raisons que vous rencontrerez le plus probablement :

Ligne Ce que Weave compare Raisons courantes d’un « contrôle impossible »
Inputs are fresh Chaque table lue par le workflow, par rapport aux planifications des workflows qui l’écrivent, ou au seuil de fraîcheur propre à la table. Votre rôle ne peut pas lire les tables ; Weave n’a pas pu déterminer quelles tables le workflow lit, ou il n’en lit aucune que Weave puisse suivre ; une table lue vous est masquée ; une étape lit une table que Weave ne peut pas déterminer, par exemple une table choisie avec une variable ; une table lue n’a ni écriture planifiée ni seuil de fraîcheur, donc rien n’indique quand elle aurait dû être écrite ; le workflow qui l’écrit est en cours d’exécution, en file d’attente ou vient tout juste de se terminer.
Last run succeeded L’exécution la plus récente du workflow, qui doit être terminée. Une exécution en échec est Pas prêt. Il n’a aucune exécution enregistrée, son historique d’exécutions n’a pas pu être lu, ou sa dernière exécution a été arrêtée ou est toujours en cours.
Last run looked usual La durée de la dernière exécution, ainsi que le nombre de lignes que ses tables contenaient ensuite, le nombre de valeurs vides qu’elles contenaient et la répartition de leurs valeurs, par rapport aux exécutions précédentes. La dernière exécution a échoué, a été arrêtée ou est toujours en cours, donc il n’y a rien d’habituel à comparer ; un accès aux lignes s’applique à une table qu’elle a écrite, donc les valeurs de cette table ne sont pas comparées ; l’exécution comprend des étapes que votre rôle ne peut pas voir.
Inputs unchanged since it last ran Si une table qu’il lit a été modifiée par un autre workflow après sa dernière lecture. Votre rôle ne peut pas lire les tables ; Weave ne peut pas suivre ce que le workflow lit ; ou le workflow n’a aucune exécution à comparer.
Schedule is healthy Ses événements planifiés : planifications valides, synchronisées avec le planificateur, aucune exécution due manquée, aucune échéance perdue à cause d’une exécution encore en cours. Le planificateur n’a pas pu être lu.
Reconciliations tie out Chaque rapprochement lié au workflow, dans sa version approuvée, exécuté sous votre identité. L’un d’eux n’a pas encore été approuvé ; votre rôle ne peut pas lire les données des tables ; l’accès aux lignes ne vous montre qu’une partie des lignes d’un côté ; une table ou une colonne qu’il utilise a changé ; la liste de contrôle a manqué de temps pour les traiter.

Un workflow sans événement planifié n’a pas de ligne Schedule is healthy, et l’élément indique qu’il n’est pas planifié. Un workflow sans rapprochement lié n’a pas de ligne Reconciliations tie out. C’est un fait concernant le workflow, et non quelque chose que Weave n’a pas réussi à vérifier.

Un workflow supprimé du projet depuis la création de l’ensemble, ou que votre rôle ne peut pas voir, est tout de même compté. Il apparaît comme Vérification impossible avec la raison, de sorte que le décompte ne diminue jamais discrètement.

Une exécution ne peut paraître inhabituelle que par rapport à des exécutions antérieures. Lorsque Weave dispose de trop peu d’historique antérieur pour comparer, Last run looked usual considère l’exécution comme habituelle et le précise. Cela couvre un workflow ou une étape nouveau, un workflow qui s’exécute trop rarement pour avoir assez d’exécutions au cours des 30 derniers jours, comme un workflow hebdomadaire, et une exécution qui a été la première à remplir une table :

Weave dispose de trop peu d’historique antérieur pour comparer sa dernière exécution ; elle est donc considérée comme habituelle.

Lorsqu’une partie de l’exécution a pu être comparée, la ligne nomme ce qui se situait dans sa plage habituelle et ajoute « Lorsque Weave dispose de trop peu d’historique antérieur pour comparer, l’exécution est considérée comme habituelle. » L’onglet Weave les liste toujours parmi les contrôles que Weave n’a pas pu effectuer. Un workflow qui ne s’est jamais exécuté reste Vérification impossible sur ses deux lignes Last run succeeded et Last run looked usual, tout comme un workflow dont la dernière exécution a été arrêtée ou est toujours en cours.

Pour un ensemble avec échéance, Weave exécute le contrôle de lui-même à l’approche de l’échéance et prévient le propriétaire de l’ensemble — la dernière personne à l’avoir enregistré — une fois pour chaque échéance de l’ensemble, par un message dans l’application :

« Clôture de fin de mois » arrive à échéance dans 3 jours (31 oct. 17:00 UTC) : 11 de ses 13 workflows prêts, 1 pas prêt, 1 que Weave n’a pas pu vérifier.

Cliquez sur Ouvrir Weave dans le message pour ouvrir l’onglet Weave du projet et la liste de contrôle de cet ensemble. Le message ne contient que des décomptes ; les noms et les raisons figurent dans la liste de contrôle. Il reste affiché 30 secondes et n’apparaît que si le propriétaire est connecté à ce moment-là ; il n’est pas renvoyé pour la même échéance, mais la liste de contrôle est toujours disponible dans la fenêtre. Si le propriétaire ne peut plus ouvrir le projet, rien n’est envoyé.

Weave effectue un contrôle toutes les heures, si bien que le message arrive dans l’heure qui suit le moment de notification : avec un préavis de 24 heures, dans l’heure qui suit les 24 heures précédant l’échéance. Un ensemble enregistré après le dépassement de son moment de notification est signalé au contrôle suivant. Si un contrôle démarre en retard et que l’échéance passe avant son exécution, ce contrôle prévient quand même le propriétaire, par « était due il y a 20 minutes », sauf si l’ensemble a été enregistré après l’échéance. Le contrôle s’exécute sous l’identité du propriétaire et ne lit les tables que si le propriétaire pouvait les lire lors du dernier enregistrement de l’ensemble.

Les ensembles de préparation sont disponibles via l’API de la plateforme sous /analyze/weave/readiness : GET /sets liste les ensembles d’un projet, GET /set, POST /set, PUT /set et DELETE /set lisent, créent, remplacent et suppriment un ensemble, et GET /check renvoie la liste de contrôle telle que la fenêtre l’affiche, avec les constatations de chaque ligne. Un ensemble lu via l’API porte un etag ; renvoyez-le comme if_match sur PUT pour faire refuser une modification qui écraserait un enregistrement plus récent. Sans lui, la dernière écriture l’emporte.