O que o Weave verifica

Descrição

O Weave lê a configuração que o projeto já guardou e o registo de como os respetivos fluxos de trabalho foram executados nos últimos 30 dias, e comunica o que encontra: um passo cuja alocação não tem nada para alocar, um fluxo de trabalho cuja estrutura guardada lista o mesmo passo duas vezes, um fluxo de trabalho cuja última execução falhou, um passo cuja saída contém muito menos linhas do que o habitual. Limita-se a ler — nada do que comunica altera um passo, e nunca executa o fluxo de trabalho.

Não intervém nenhum modelo de IA. Cada verificação é uma regra fixa e cada frase é escrita antecipadamente, pelo que produzir um relatório não tem custo, por mais vezes que o peça.

Nota

As constatações estão acessíveis através da API da plataforma, e o separador Weave do projeto lista todas as constatações do projeto.

Três respostas, não duas

A maioria das verificações no PlaidCloud tem duas respostas: a configuração está correta ou é recusada. O Weave tem uma terceira, e é essa que vale a pena compreender.

Resposta	O que significa
O Weave detetou …	O Weave verificou isto e encontrou um problema.
(nada é dito)	O Weave verificou isto e não encontrou nada de errado.
O Weave não verificou …	O Weave não conseguiu avaliar isto de todo.

A terceira existe porque o silêncio é ambíguo. Quando cria um passo de alocação, o PlaidCloud permite guardá-lo antes de preencher o mapeamento de colunas — ainda o está a construir, e recusar a gravação impediria o seu trabalho. Um monitor que lesse esse mesmo mapeamento vazio poderia facilmente comunicar o passo como saudável. Não está saudável; está inacabado, e ninguém o analisou.

Por isso, o Weave di-lo. Um passo que não conseguiu avaliar é comunicado como não verificado, com o motivo, e nunca é contado, ordenado ou colorido como se tivesse sido aprovado.

Há uma quarta coisa que o Weave pode dizer, e não é de todo uma resposta sobre o passo: O Weave não tem regra para …. Significa que o Weave não tem nenhuma verificação para esse tipo de elemento e nunca o avaliou. Ao contrário de “não verificou”, nada do que fizer ao passo produzirá um veredicto, pelo que vale a pena distinguir os dois casos: conclua um passo não verificado e o Weave avalia-o; um passo para o qual não tem regra continua por avaliar, por mais que o altere.

Como é um relatório

Um relatório abre com um resumo que indica o seu próprio denominador, para que possa ver quanto do projeto abrange:

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.

Quando um projeto tem tabelas escritas segundo um agendamento ou com um limite de atualidade definido, a primeira linha conta-as em separado: O Weave verificou totalmente 31 dos 36 passos e fluxos de trabalho, e 3 das 4 tabelas que devem estar atualizadas, em “Finance”, e encontrou 2 problemas nas partes que conseguiu avaliar.

A fração na primeira linha é deliberada. Três passos verificados e sem problemas não são a mesma afirmação que um projeto sem problemas, e a linha de abertura contém a sua própria escala para que não possa ser citada sem ela. “Nas partes que conseguiu avaliar” está lá pelo mesmo motivo: quando algo foi avaliado apenas em parte, os problemas encontrados não podem ser atribuídos aos passos que a linha acabou de dar como verificados. A segunda linha indica aquilo para que o Weave não tem regra nenhuma e diz explicitamente que esses elementos não foram avaliados num sentido nem noutro — não que nenhuma verificação era necessária.

Como o Weave sabe

Cada constatação tem por baixo uma ligação Como o Weave sabe, que abre um painel que mostra como o Weave chegou a ela:

• A verificação — o que a regra testa, em palavras simples, com os limites que utiliza, como o número de execuções anteriores com que compara uma contagem.
• A evidência — os valores que a verificação utilizou. Para uma contagem de linhas que mudou, são a contagem mais recente, a média das execuções anteriores, quanto a contagem costuma variar de execução para execução e o intervalo fora do qual o Weave a comunica.
• De onde provém — a execução, o histórico de execuções, as definições guardadas do passo, o evento agendado ou a tabela de onde a evidência foi lida. Um elemento apresentado como ligação abre o local onde o consultaria, como o fluxo de trabalho ou o Explorador de tabelas.
• O que o Weave não verificou — o que a regra deixa de fora. Nunca está vazio: uma verificação de que uma tabela foi escrita a tempo, por exemplo, não analisa o que foi escrito.

Para uma constatação que o Weave não conseguiu verificar, o painel mostra a verificação e o motivo pelo qual não pôde ser executada, sem evidência.

O painel indica apenas o que pode ver. Um passo, fluxo de trabalho ou tabela que a sua função oculta é listado como um elemento que não pode abrir, nunca pelo nome, e quando a última execução de um fluxo de trabalho falhou em passos que não pode abrir, a evidência conta esses passos em vez de os nomear. Não intervém nenhuma IA na construção do painel.

O painel aparece no separador Weave e numa revisão. O resumo escrito por IA de uma revisão também tem um, que indica que foi escrito por IA, a partir de quantas constatações, e o que o Weave verificou antes de o mostrar. Uma revisão que um assistente de IA executa através do PlaidCloud MCP não inclui o painel.

O que o Weave verifica atualmente

Mapeamento de colunas de alocação. Para um passo Allocation with Dimension ou Allocation Split, que existe uma coluna numérica a alocar, um valor de indutor numérico pelo qual a alocar, uma hierarquia quando é necessária e — no caso de uma divisão — um numerador e um denominador que indica uma coluna que a tabela de origem efetivamente tem. São as mesmas verificações executadas quando guarda o passo, aplicadas ao que já foi guardado. A gravação verifica também a própria dimensão de atribuição — que existe e que tem exatamente uma propriedade de indutor — o que o Weave não faz, pelo que um passo que a gravação recusa por esse motivo não produz nenhuma constatação do Weave.

Expressões dos passos. Para qualquer passo que as contenha, que todas as expressões que escreveu — numa coluna de destino, na cláusula Subset ou na cláusula Secondary Filter — continuam a compilar. Uma constatação indica a coluna ou a cláusula, para que saiba qual abrir, e apresenta o erro, como Syntax error at line 1, position 280. A própria expressão encontra-se em Como o Weave sabe, para que uma expressão longa não esconda o erro. São as mesmas verificações executadas quando guarda o passo.

Dois casos que o Weave comunica como não verificados em vez de os avaliar:

• Uma expressão que lê uma variável. Um passo pode pertencer a mais do que um fluxo de trabalho, e cada fluxo de trabalho pode definir uma variável com um valor diferente — ou nem sequer a definir. A validação na gravação sabe a partir de que fluxo de trabalho está a guardar; uma análise não sabe. Em vez de escolher um e arriscar dar como avariada uma expressão que funciona, o Weave comunica o passo como não verificado quando a variável não está definida em todo o lado ou está definida com valores que não coincidem. Um fluxo de trabalho que a sua função não lhe mostra conta da mesma forma: o Weave também não consegue ler as respetivas variáveis, pelo que não afirmará que o passo é coerente. Quando todos os fluxos de trabalho coincidem, avalia o passo normalmente.
• Filtros e listas de colunas que esta verificação não lê. Alguns tipos de passo guardam um filtro ou uma segunda lista de colunas numa parte do formulário que a verificação de expressões nunca leu — as junções de duas tabelas e Lookup, as divisões de alocação, Generate Batch e SAP Post Journal Entry. A gravação desses passos sempre ignorou esses campos, pelo que o Weave não aprova o passo com base na metade que consegue ler: comunica-o como não verificado. Os passos Junção de várias tabelas e Delete são comunicados da mesma forma, porque a sua configuração não tem uma forma que esta verificação consiga compilar.

Algo listado duas vezes num fluxo de trabalho. Que nenhum passo e nenhum fluxo de trabalho aninhado aparece mais do que uma vez no mesmo fluxo de trabalho, e que não há duas pastas com o mesmo elemento principal que tenham o mesmo identificador.

Passos que podem ser executados antes de a tabela que leem ser escrita. Num fluxo de trabalho avançado, que cada passo que lê uma tabela é executado depois do passo do mesmo fluxo de trabalho que a escreve, através dos conectores na área de desenho. O Weave verifica isto quer o fluxo de trabalho tenha sido executado alguma vez, quer não. Uma constatação indica um desses passos e o passo depois do qual deve ser executado, e diz quantos passos são afetados; as tabelas são listadas em Como o Weave sabe. Um passo que a área de desenho já executa demasiado cedo é comunicado em separado. O Weave comunica o fluxo de trabalho como não verificado quando um passo executa outro fluxo de trabalho ou utiliza tabelas que não consegue seguir, e não avalia uma tabela que mais do que um passo, ou outro fluxo de trabalho, também escreve. Para rever e adicionar os conectores em falta, utilize Sincronizar dependências na área de desenho. Se um passo se destina a ler a saída da execução anterior, marque a constatação como esperada.

Como os fluxos de trabalho foram executados. O Weave lê as execuções de cada fluxo de trabalho dos últimos 30 dias — até às vinte execuções mais recentes de cada fluxo de trabalho — e avalia a mais recente em relação às anteriores. Para as comparações de fim de mês e de dia da semana descritas abaixo, lê também algumas execuções mais antigas dos últimos 180 dias. Cada comparação é feita com o histórico do próprio fluxo de trabalho, nunca com o de outro fluxo de trabalho.

• A última execução falhou. Um fluxo de trabalho cuja execução mais recente falhou é comunicado, com a data da falha e, quando as execuções anteriores também falharam, quantas seguidas e desde quando.

• Execução mais lenta do que o habitual. Uma execução que terminou, mas cujos passos demoraram mais tempo no seu conjunto do que as execuções terminadas anteriores do fluxo de trabalho permitem — mais de dois desvios-padrão acima da respetiva média e, no mínimo, 5% acima dela (nunca menos de um segundo, para que um fluxo de trabalho rápido não seja comunicado por alguns milissegundos). O tempo é a soma dos tempos dos passos, pelo que, num fluxo de trabalho que executa passos em paralelo, é superior ao que o relógio mostrou. Uma execução que terminou mais depressa não é comunicada.

• Passo mais lento do que o habitual. Um passo que demorou mais tempo na sua última execução concluída do que nas execuções concluídas anteriores nesse fluxo de trabalho, segundo a mesma medida aplicada a uma execução lenta. É assim que o Weave identifica o passo responsável por uma execução lenta. Um passo presente em vários fluxos de trabalho é avaliado separadamente em cada um. O tempo vai do início ao fim do passo: o Weave não separa o trabalho do próprio passo do tempo passado em espera, por exemplo, num data warehouse ocupado.

• As execuções tornaram-se mais lentas. Um abrandamento que se manteve. Quando as execuções mais lentas são a maioria das execuções anteriores com que uma execução é comparada, uma execução lenta deixa de parecer invulgar, pelo que esta verificação compara metades. O Weave lê as últimas 20 execuções do fluxo de trabalho dos últimos 30 dias, mantém as que foram concluídas e divide-as numa metade mais antiga e numa metade mais recente, consoante a hora de início. Comunica o fluxo de trabalho quando o tempo mediano da metade mais recente é, no mínimo, 25% e 30 segundos superior ao da metade mais antiga, e a execução mais recente demorou mais tempo em, pelo menos, 85% dos emparelhamentos de uma execução mais recente com uma mais antiga. O tempo é a soma dos tempos dos passos, tal como numa execução lenta. O Weave precisa de, pelo menos, 12 execuções concluídas distribuídas por, pelo menos, 14 dias, pelo que um fluxo de trabalho executado mais de cerca de 20 vezes em duas semanas não é verificado. As execuções falhadas e paradas não são contadas; uma execução que prosseguiu depois de um passo falhado é contada. A constatação indica até três passos que pode abrir cujo tempo mediano mais aumentou, e a sua frase mantém-se igual enquanto o abrandamento durar, para que não seja avisado novamente após cada execução.

• Linhas de destino diferentes das execuções anteriores. Um passo cujas tabelas de saída continham muitas mais ou muitas menos linhas após a última execução do que após as execuções anteriores nesse fluxo de trabalho, segundo a mesma medida (e com uma diferença de, pelo menos, uma linha). A contagem é o que as tabelas contêm, pelo que um passo que acrescenta linhas é avaliado pelo total crescente. Um passo presente em vários fluxos de trabalho é avaliado separadamente em cada um.

• A junção duplicou mais linhas do que o habitual. Uma junção interna, à esquerda ou à direita que escreveu mais linhas por cada linha da sua tabela principal do que após as execuções anteriores nesse fluxo de trabalho — mais de dois desvios-padrão acima da respetiva média e, no mínimo, 5% acima dela. A tabela principal é a Table A numa junção interna ou à esquerda e a Table B numa junção à direita. Mais do que uma linha escrita por cada linha da tabela principal significa que algumas das suas chaves de junção aparecem em mais do que uma linha da outra tabela, pelo que as linhas que as contêm foram escritas mais do que uma vez. O Weave só comunica um valor superior a 1,00, e apenas quando está acima do nível habitual da junção, pelo que uma junção que, por conceção, escreve várias linhas por linha só é comunicada se esse número aumentar. Numa junção interna, só são detetadas as chaves que se repetem na Table B. Uma junção com menos de quatro execuções anteriores que tenham registado as linhas da sua tabela principal é comunicada como não verificada.

  Uma junção que agrega, ou que utiliza Distinto, segmentação (Limit) ou um Secondary Filter, é comunicada como não verificada, porque cada uma destas opções altera, por si só, a contagem de linhas. O mesmo acontece com uma junção cuja tabela principal não tem uma contagem de linhas registada, como uma vista. As linhas da tabela principal são as registadas quando foi escrita pela última vez, antes do filtro que o passo lhe aplica. Um filtro que mantém uma proporção diferente das suas linhas em cada execução também faz variar o valor, e pode ser comunicado. Uma alteração feita à tabela principal de outra forma, ou por um passo executado ao mesmo tempo, não é detetada. As junções externas completas, cruzadas e de várias tabelas não são verificadas, e um Lookup não pode escrever uma linha mais do que uma vez.

• Valores vazios diferentes das execuções anteriores. Uma coluna da tabela de saída de um passo que ficou vazia numa proporção das suas linhas muito maior ou muito menor do que após as execuções anteriores do passo — mais de dois desvios-padrão em relação à proporção habitual e, no mínimo, a cinco pontos percentuais dela. Cada tabela que um passo escreve é avaliada em relação às suas próprias linhas.

• A importação não encontrou ficheiros. Um passo de importação cuja execução concluída mais recente não encontrou ficheiros no caminho a partir do qual lê. O passo termina com um aviso em vez de falhar, e cria a tabela de destino vazia ou não carrega nada, pelo que os passos seguintes não têm nada dele para ler. A constatação indica o fluxo de trabalho e o caminho, não precisa de execuções anteriores e desaparece quando uma execução encontra ficheiros. Um passo presente em vários fluxos de trabalho é avaliado separadamente em cada um, e num fluxo de trabalho que não pode abrir o caminho não é mostrado. O Weave não consegue distinguir uma pasta vazia de propósito de um ficheiro em falta: se uma pasta vazia for normal nesse local, um Arquiteto do projeto pode marcar a constatação como esperada, e o Weave deixa de a comunicar para esse passo nesse fluxo de trabalho, seja qual for o caminho. Uma execução registada antes de esta verificação existir não guarda o texto do aviso, pelo que o respetivo passo é comunicado como não verificado até voltar a ser executado.

Fins de mês e dias da semana. Para um fluxo de trabalho ou passo executado no máximo uma vez por dia, uma execução que estas verificações comunicariam é dispensada quando está em linha com, pelo menos, quatro execuções anteriores no mesmo tipo de dia, dos últimos 180 dias, que não variam mais, em proporção do seu tamanho, do que as suas execuções anteriores noutros dias. Os tipos de dia são o último dia de um mês, o primeiro dia de um mês e, nos restantes casos, o mesmo dia da semana. Assim, uma carga de fim de mês que é sempre pesada, ou uma carga que é sempre mais leve às segundas-feiras, não é comunicada quando essas execuções são mais estáveis, em proporção do seu tamanho, do que as dos outros dias. O calendário só dispensa execuções: nunca comunica uma que estas verificações aprovariam. Os dias são contados em UTC, e os feriados e calendários de dias úteis não são tidos em conta. Um fluxo de trabalho ou passo executado mais do que uma vez num dia, incluindo uma execução falhada e a respetiva repetição, é comparado com as suas execuções anteriores como antes.

Uma referência de base precisa de, pelo menos, quatro execuções anteriores. Com menos, o fluxo de trabalho é comunicado como não verificado quanto ao tempo de execução, e os seus passos como não verificados quanto às linhas e aos valores vazios, indicando cada um quantas execuções terminadas teve, em vez de ser avaliado com base em dados insuficientes. Um passo que escreve uma tabela, mas cujas execuções registadas não contêm contagens de valores vazios, também é comunicado como não verificado quanto a estes. Um passo que não escreve nenhuma tabela, como um que envia um e-mail ou exporta um ficheiro, não é verificado quanto a linhas nem a valores vazios. Um fluxo de trabalho que não foi executado nos últimos 30 dias é comunicado como não verificado, e o mesmo acontece com um cujo histórico de execuções não pôde ser lido — nenhum deles é comunicado como saudável. Num projeto com Acesso a linhas declarado, as verificações de linhas, junções, valores vazios e distribuição de valores não se aplicam a quem tem as leituras filtradas: cada uma é medida sobre a tabela inteira, pelo que uma constatação lhe daria informação sobre linhas fora da sua concessão. Consulte Contagens de linhas e tamanhos das tabelas.

O que a última execução de um passo alterou. Para cada tabela que a última execução de um passo escreveu, o Weave compara a tabela tal como a execução a deixou com a tabela tal como estava antes de a execução começar, pelo que não precisa de um histórico de execuções anteriores.

• Distribuição de valores diferente da anterior à última execução. Uma coluna cujos valores se distribuem ao longo do seu intervalo de forma muito diferente depois da execução em relação a antes. A constatação apresenta uma pontuação de desvio: 0 significa que a distribuição não mudou, e 0,25 ou mais é uma alteração grande, que é quando o Weave a comunica. Só são comparadas colunas com números decimais. As colunas de números inteiros são normalmente códigos, períodos ou indicadores binários, como um número de conta ou um mês, e a sua distribuição muda sempre que são carregados novos períodos. Os valores vazios não fazem parte da distribuição; a verificação de valores vazios acima abrange-os.

“Antes da execução” é a última versão da tabela que continha linhas. Uma versão deixada vazia por uma execução que falhou a meio é ignorada, pelo que a primeira execução bem-sucedida após uma falha é comparada com os últimos dados válidos.

A execução de um passo é comunicada como não verificada, com o motivo, quando uma tabela que escreveu:

• tem Acesso a linhas declarado nas suas colunas;
• continha mais de 5 000 000 de linhas antes ou depois da execução;
• demorou mais de 10 segundos a comparar;
• já não guarda a sua versão anterior à execução — alguns lakehouses guardam as versões anteriores de uma tabela durante 7 dias, pelo que uma tabela reescrita com uma frequência inferior a semanal não tem nada com que comparar; ou
• foi preenchida pela primeira vez por essa execução.

Um projeto cujo lakehouse não guarda histórico de versões não é avaliado de todo nesta verificação.

Valores deixados vazios por uma conversão de tipo. Cada coluna que um passo Extract escreve tem um tipo, como texto, inteiro ou data, e o passo converte cada valor para esse tipo. Num lakehouse StarRocks, um valor que não pode ser convertido, como N/A numa coluna de inteiros, é guardado vazio, e a execução termina sem erro. Depois de um passo Extract ser executado no StarRocks, o Weave conta, para cada coluna cuja conversão possa perder valores, os valores de entrada que não estavam já vazios e quantos deles ficaram vazios, e comunica cada coluna em que isso aconteceu. A constatação apresenta a contagem e o tipo da coluna. Avalia a última execução concluída do passo em cada fluxo de trabalho, pelo que não precisa de execuções anteriores.

• Os valores que já estavam vazios à entrada não são contados. O texto em branco é, porque é guardado vazio numa coluna de número ou de data.
• Uma coluna cuja conversão não pode perder um valor, como números inteiros a entrar numa coluna decimal, não é contada, nem uma coluna sem valores vazios após a execução.
• Se a contagem demorar mais de 30 segundos, ou se as linhas que o Weave conta não corresponderem às linhas que o passo escreveu, a execução é comunicada como não verificada, e o Weave volta a contar na próxima vez que o passo for executado.
• Só são verificados passos Extract no StarRocks. Um passo que utiliza um Secondary Filter ou agrupa por uma expressão é comunicado como não verificado, e o mesmo acontece com um que utiliza Distinto ou segmentação (Limit) quando uma coluna pode perder valores, porque o Weave não consegue voltar a contar as linhas sem a conversão.
• Se o passo se destinar a deixar esses valores vazios, um Arquiteto do projeto pode marcar a constatação como esperada.
• Tal como as verificações de linhas e de valores vazios, não se aplica a quem tem as leituras filtradas pelo Acesso a linhas.

Eventos agendados. Para um fluxo de trabalho com eventos agendados, o Weave compara cada evento com as execuções que iniciou e com a tarefa no cluster que o dispara. Cada hora é considerada no fuso horário do próprio evento, e um disparo é avaliado 15 minutos depois da hora prevista, para dar tempo à respetiva tarefa para iniciar.

• Calendário do evento agendado inválido. Um evento ativado cujo agendamento não pode ser lido.
• A execução agendada não foi iniciada. Um evento ativado que chegou à hora prevista sem iniciar uma execução — desde a última vez que iniciou uma, ou desde que foi guardado, se nunca iniciou nenhuma. Quando o cluster o permite saber, o Weave acrescenta se o cluster nunca disparou o evento ou se a tarefa que disparou falhou. A constatação indica a última execução que o evento iniciou, ou a hora a que foi guardado, para que continue a ser uma única constatação enquanto o evento continuar avariado da mesma forma. Um evento guardado depois de o disparo ter chegado à hora prevista não é avaliado nesse disparo.
• O evento agendado chegou à hora prevista durante uma execução. Um evento que chegou à hora prevista enquanto o fluxo de trabalho ainda estava a ser executado, pelo que nenhuma execução foi iniciada nesse momento. Um evento agendado nunca inicia uma segunda execução de um fluxo de trabalho que já está a ser executado; isto é comunicado uma vez, para que um agendamento mais apertado do que as execuções do fluxo de trabalho não perca disparos sem que ninguém dê por isso.
• Evento agendado dessincronizado do cluster. Um evento e a respetiva tarefa no cluster que não coincidem: um evento ativado sem tarefa, ou com a tarefa em pausa; um evento desativado cuja tarefa não está em pausa; ou uma tarefa configurada com um agendamento ou fuso horário diferente do que o evento mostra. Quando o cluster não pode ser lido, o fluxo de trabalho é comunicado como não verificado quanto aos seus eventos agendados.

Um evento que deixou de iniciar execuções não tem nenhum fim de execução que o possa avisar, pelo que aparece no separador Weave em vez de numa mensagem.

Tabelas escritas segundo um agendamento. Para uma tabela que um fluxo de trabalho com um evento agendado ativado escreve, o Weave verifica se a tabela foi escrita desde a última hora prevista do agendamento. Uma tabela conta como escrita quando um passo que a escreve termina. O Weave não analisa os dados da tabela, pelo que não deteta uma carga feita fora dos passos do projeto. Tal como nas verificações de eventos agendados, cada agendamento é lido no fuso horário do respetivo evento e avaliado 15 minutos depois da hora prevista. O Weave verifica apenas as tabelas que a sua função lhe permite ver; sem a função analyze.table.read não verifica nenhuma tabela, e a primeira linha conta apenas passos e fluxos de trabalho.

• Tabela não escrita segundo o agendamento. Uma tabela que nenhum passo escreveu desde que um fluxo de trabalho que a escreve chegou à hora prevista do seu agendamento. Uma escrita feita por qualquer passo conta, incluindo uma num outro fluxo de trabalho ou numa execução que iniciou manualmente. A constatação apresenta a hora da última escrita em vez de há quanto tempo foi. Uma execução que falhou conta como não escrita, pelo que as tabelas de um fluxo de trabalho agendado que está a falhar são comunicadas aqui, bem como em A última execução falhou.

O Weave comunica uma tabela como não verificada, com o motivo, em vez de não escrita, quando:

• um fluxo de trabalho que a escreve está a ser executado, está em fila de espera ou acabou de terminar e os respetivos resultados ainda não estão registados;
• um passo que a escreve foi ignorado numa execução desde a hora prevista do agendamento, seja pelas suas próprias condições, seja por não ter encontrado nada para fazer, como uma importação cujos ficheiros não tinham mudado;
• um passo que a escreve pode ser ignorado sem registo de que o foi: está num fluxo de trabalho Standard com uma condição que salta para outro passo, ou num fluxo de trabalho Standard Serial com um passo que vai para outro passo quando falha, ou encontra-se num contentor com condições ou num ciclo que pode ser executado zero vezes;
• o fluxo de trabalho terminou uma execução desde a hora prevista, mas o registo do passo de escrita dessa execução está em falta;
• um passo em qualquer parte do projeto escolhe a tabela que escreve com uma variável cujo valor o Weave não consegue determinar, pelo que pode escrever esta tabela;
• o agendamento é executado com uma frequência inferior a uma vez a cada 180 dias, que é o limite do histórico de execuções do Weave; ou
• o agendamento de um fluxo de trabalho não é válido, ou o histórico de execuções não pode ser lido.

Uma tabela não é de todo verificada quando:

• não tem limite de atualidade (abaixo) e nenhum fluxo de trabalho com um evento agendado ativado próprio a escreve. Um fluxo de trabalho que outro fluxo de trabalho executa, através de um passo Executar fluxo de trabalho ou Macro, ou como fluxo de trabalho colocado dentro dele, conta apenas através do seu próprio agendamento;
• os únicos passos que a escrevem estão desativados, encontram-se num contentor desativado ou encontram-se num ponto de interrupção ou depois dele; ou
• é uma vista.

O segundo destes casos não se aplica dentro de um ciclo que é executado: um ciclo executa todos os passos que contém, mesmo um que esteja desativado, num contentor desativado ou num ponto de interrupção ou depois dele.

Um evento agendado guardado depois da última hora prevista só é avaliado quando voltar a chegar à hora prevista.

Um fluxo de trabalho cujas execuções demoram mais do que o intervalo do seu agendamento ignora os disparos que chegam à hora prevista enquanto está a ser executado, pelo que, entre execuções, as suas tabelas podem ser comunicadas como não escritas; O evento agendado chegou à hora prevista durante uma execução comunica a causa.

Quando o passo que escreveu uma tabela pela última vez é um a que não tem acesso, a constatação diz “um passo a que não tem acesso” e indica na mesma a hora da escrita. “180 dias” numa constatação é o limite do histórico de execuções do Weave, não um facto sobre a tabela.

Tabelas com um limite de atualidade. Um limite de atualidade é o número máximo de horas que pode decorrer entre escritas de uma tabela, de 1 a 4320 (180 dias). Uma tabela com um limite é avaliada em relação a ele em vez de em relação aos agendamentos dos fluxos de trabalho que a escrevem. Isto permite definir um limite mais largo ou mais apertado do que um agendamento dá, e verificar uma tabela que nenhum fluxo de trabalho agendado escreve. Tal como nos agendamentos, uma tabela conta como escrita quando um passo que a escreve termina.

• Tabela não escrita dentro do tempo definido. Nenhum passo escreveu a tabela durante mais tempo do que o seu limite. A constatação apresenta a hora da última escrita e o limite.

O Weave comunica uma tabela com limite como não verificada, com o motivo, em vez de não escrita, quando:

• um fluxo de trabalho que a escreve está a ser executado, está em fila de espera ou acabou de terminar e os respetivos resultados ainda não estão registados;
• um fluxo de trabalho que a escreve iniciou uma execução depois de o limite ter sido ultrapassado e terminou-a, mas o registo do passo de escrita dessa execução está em falta;
• um passo em qualquer parte do projeto escolhe a tabela que escreve com uma variável cujo valor o Weave não consegue determinar, pelo que pode escrever esta tabela;
• nenhum passo do projeto a escreve, como uma tabela que carrega manualmente, pelo que o Weave não tem nenhuma escrita a partir da qual medir; ou
• o histórico de execuções não pode ser lido.

Um passo ignorado não torna não verificada uma tabela com limite: a tabela continua sem ser escrita durante mais tempo do que o seu limite. Uma vista não pode ter limite, e transformar uma tabela numa vista remove o seu limite. Uma cópia de uma tabela, ou uma tabela criada a partir de um dos seus instantâneos, começa sem limite.

Para definir um limite, selecione a tabela na lista Tabelas do projeto e escolha Ver/editar detalhes da tabela. Em Atualidade, selecione Warn if this table isn’t written for more than, introduza o número de horas e clique em Update. Desmarque a caixa de verificação para remover o limite. Enquanto não estiver definido nenhum limite, a caixa indica os fluxos de trabalho agendados em cujos agendamentos a tabela é avaliada, ou diz que nenhum fluxo de trabalho que possa abrir a escreve segundo um agendamento. Atualidade não aparece para uma vista nem para uma tabela que está a criar, nem sem a função analyze.workflow.read, e alterá-la requer analyze.table.write.

Também pode pedir a um assistente de IA ligado através do PlaidCloud MCP que defina o limite de atualidade da tabela (a ferramenta é table_upsert, com freshness_max_age_hours), ou chamar a API da plataforma:

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

Envie null em vez do número para o remover, e a tabela volta a ser avaliada segundo os agendamentos dos fluxos de trabalho que a escrevem. GET /rest/v1/analyze/weave/freshness?project_id=<project>&table_id=<table> devolve o limite e scheduled_writers, os fluxos de trabalho agendados em cujos agendamentos a tabela é avaliada quando não tem limite. Ler um limite requer as funções analyze.table.read e analyze.workflow.read, e defini-lo requer analyze.table.write e analyze.workflow.read. Só pode definir um limite numa tabela que a sua função lhe permite ver, e não enquanto o projeto estiver bloqueado.

Tabelas que um fluxo de trabalho lê, escritas entretanto. Para um fluxo de trabalho que lê uma tabela que outro fluxo de trabalho escreve, o Weave verifica que nenhum outro fluxo de trabalho escreveu na tabela desde a última vez que o fluxo de trabalho a leu. Uma tabela conta como lida ou escrita por um passo que a indica como entrada ou saída e que terminou numa execução. O Weave lê o que o histórico de execuções regista, não os dados da tabela.

• Lê uma tabela escrita desde a última leitura. Um fluxo de trabalho leu uma tabela pela última vez numa das suas execuções, e um fluxo de trabalho diferente escreveu nessa tabela desde então, pelo que os seus resultados podem estar desatualizados. A constatação indica a execução que leu a tabela pela última vez e os fluxos de trabalho que escreveram nela. Um fluxo de trabalho com um evento agendado ativado, ou um que outro fluxo de trabalho com um evento desses executa, só é comunicado depois de um agendamento que o executa ter chegado à hora prevista após a escrita; um fluxo de trabalho que nada executa segundo um agendamento é comunicado de imediato.

Estes casos não contam como escrita entretanto:

• uma escrita feita pelo próprio fluxo de trabalho, incluindo uma feita durante a sua execução por um fluxo de trabalho que executa através de um passo Fluxo de trabalho: Executar, Fluxo de trabalho: Ciclo ou Fluxo de trabalho: Execução condicional;
• uma tabela que o fluxo de trabalho escreve numa execução antes de qualquer passo dessa execução a ler, como uma tabela de preparação, a menos que a escrita tenha sido feita por um passo Tabela: Acrescentar ou Tabela: Upsert, ou por um passo Tabela: Eliminação no local com um filtro, que mantêm as restantes linhas da tabela; e
• uma escrita feita antes da última gravação do passo que a fez, uma vez que o passo pode ter escrito numa tabela diferente nessa altura.

O Weave comunica o fluxo de trabalho como não verificado, com o motivo, em vez de desatualizado, quando:

• está a ser executado, ou acabou de terminar e os respetivos resultados ainda não estão registados;
• um passo que lê a tabela foi ignorado numa execução posterior à escrita;
• o agendamento que o executa não é válido;
• nenhuma das suas execuções recentes terminou a leitura da tabela, enquanto outro fluxo de trabalho escreveu nela ou pode ter escrito;
• um passo que lê a tabela foi guardado depois do início da sua última execução bem-sucedida, pelo que o Weave não consegue saber se essa execução a leu. Qualquer gravação conta, mesmo uma que não altere nada do que o passo lê;
• um dos seus passos lê tabelas que o Weave não consegue determinar a partir das definições do passo, como um passo IA: Passo LLM, um passo Report, um passo Executar: Python remoto, ou um passo que lê várias tabelas e encontra uma delas por pesquisa, como pode fazer um passo Tabela: União distinta ou Tabela: União total; escolhe uma tabela com uma variável; indica uma tabela por um nome que mais do que uma tabela tem; lê uma vista; ou lê uma tabela de outro projeto;
• uma tabela que lê também é escrita por uma macro, cujas execuções o Weave não vê, ou por um passo de outro fluxo de trabalho que foi executado entretanto e que escolhe a tabela que escreve com uma variável, a indica por um nome que mais do que uma tabela tem, ou escreve tabelas que o Weave não consegue determinar; ou
• o seu histórico de execuções não pode ser lido.

Um fluxo de trabalho sem execuções nos últimos 30 dias não é verificado desta forma.

O que esta verificação não deteta:

• leituras e escritas mais antigas do que o histórico de execuções que o Weave lê, que corresponde aos últimos 30 dias e, para cada fluxo de trabalho, às suas últimas 20 execuções;
• a condição de um passo que verifica uma tabela, que não conta como leitura dessa tabela;
• uma escrita feita por outro fluxo de trabalho numa tabela à qual o fluxo de trabalho acrescenta linhas e que depois lê na mesma execução, a menos que as acrescente com um passo Tabela: Acrescentar ou Tabela: Upsert;
• uma leitura anterior feita por um passo quando outro passo do fluxo de trabalho leu a mesma tabela mais recentemente;
• uma escrita dentro de uma macro feita por um passo que escolhe a sua tabela com uma variável ou escreve tabelas que o Weave não consegue determinar; e
• escritas feitas antes da última gravação do passo de escrita, mesmo quando a gravação não alterou nada do que escreve, até o respetivo fluxo de trabalho voltar a ser executado.

Sem a função analyze.table.read, nenhum fluxo de trabalho é verificado desta forma. Quando um fluxo de trabalho ou uma tabela que escreveu ou foi lida é um a que não tem acesso, a constatação diz “um fluxo de trabalho a que não tem acesso” ou “uma tabela a que não tem acesso”, sem dizer quantos.

Um passo cujo tipo não tem regra no Weave é comunicado como não abrangido, e não como sem problemas.

Tabelas que dependem de uma execução falhada. Quando a última execução de um fluxo de trabalho falhou antes de terminar um passo que escreve uma tabela, essa tabela continua a conter os dados anteriores, ou apenas parte dos novos dados. O Weave segue a tabela através dos passos que a leem e das tabelas que estes escrevem, ao longo dos fluxos de trabalho do projeto, e comunica o que depende dela:

• Lê uma tabela que uma execução falhada não terminou. Um fluxo de trabalho lê a tabela, ou uma tabela construída a partir dela, por mais passos que os separem. A constatação indica a tabela que lê, a tabela que a execução falhada não terminou e o fluxo de trabalho que falhou, com a hora de início dessa execução.
• Mostra uma tabela que uma execução falhada não terminou. Um painel de controlo tem um gráfico sobre uma tabela publicada que é essa tabela, ou é construída a partir dela, ou sobre um conjunto de dados SQL que lê uma tabela dessas. O Weave lê a lógica de modelo de um conjunto de dados SQL sem as etiquetas, pelo que uma tabela num ramo que nunca é seguido pode contar. A constatação diz respeito ao painel de controlo e é listada no separador Weave de cada projeto cujas tabelas os seus gráficos mostram.

O Weave detetou o painel de controlo “Board Pack”: mostra a tabela “Margin”, construída a partir da tabela “Sales”, que o fluxo de trabalho “Import Sales” não terminou de escrever na sua última execução, a 27 Oct 09:15 UTC, pelo que os seus gráficos podem mostrar dados antigos ou incompletos

Cada fluxo de trabalho falhado é uma constatação própria, que desaparece quando a última execução desse fluxo de trabalho deixa de falhar. O fluxo de trabalho que falhou não é avisado aqui sobre a sua própria execução; a respetiva constatação A última execução falhou trata disso.

Estes casos não contam como uma tabela que a execução falhada não terminou:

• uma tabela cujo passo foi ignorado de propósito, como um passo cuja condição não foi cumprida, um passo desativado ou uma importação que ignorou um ficheiro que já tinha carregado;
• uma tabela cujo passo uma execução pode saltar. Num fluxo de trabalho que não é avançado, o salto de uma condição, ou o salto de um passo com falha num fluxo de trabalho em série, abrange todos os passos. Num fluxo de trabalho avançado, abrange um passo dentro ou depois de um contentor de execução que verifica condições, e um passo num ciclo;
• uma tabela que outro fluxo de trabalho substituiu na totalidade depois do início da execução falhada, em vez de lhe acrescentar linhas; e
• para um fluxo de trabalho, uma tabela que ele próprio substituiu antes de a ler, na sua última execução que a leu.

Um fluxo de trabalho que está a ser executado só é avaliado quando a execução terminar. Quando o histórico de execuções não pode ser lido, o Weave comunica estes casos como não verificados em vez de sem problemas.

O que esta verificação não deteta:

• uma execução que terminou sem nenhum passo registar uma falha, como uma cujo servidor parou, e uma execução que alguém parou;
• uma tabela que um passo escolhe com uma variável, indica por um nome que mais do que uma tabela tem, lê através de uma vista ou lê de outro projeto;
• um gráfico de painel de controlo sobre uma consulta guardada, ou sobre um conjunto de dados SQL cujo SQL o Weave não consegue ler depois de retirada a lógica de modelo;
• uma tabela cujo nome é construído por um modelo;
• uma tabela que um conjunto de dados SQL indica sem esquema, a menos que o esquema do próprio conjunto de dados seja o esquema de relatórios do projeto;
• qualquer conjunto de dados SQL num projeto num data warehouse Snowflake ou Databricks;
• uma tabela que não está publicada, e Aplicações Panel; e
• execuções mais antigas do que o histórico de execuções que o Weave lê, que corresponde aos últimos 30 dias e, para cada fluxo de trabalho, às suas últimas 20 execuções.

Só vê a constatação de um painel de controlo se for um painel que pode abrir. Sem a função analyze.table.read, nenhuma das verificações é executada.

Totais de indicadores invulgares. Todos os dias, o Weave lê os indicadores do projeto e comunica um cujo último período terminado ficou longe do habitual, indicando o elemento, como um cliente ou uma fábrica, responsável pela alteração. Consulte Totais de indicadores invulgares.

Rever um fluxo de trabalho

Uma revisão verifica um fluxo de trabalho antes de confiar nele. Executa as verificações do Weave sobre o fluxo de trabalho e os seus passos, incluindo os passos de qualquer fluxo de trabalho que execute, e mais três que o Weave executa apenas numa revisão, porque leem mais do que o separador Weave pode ler sempre que é aberto:

• Uma alocação que alimenta as suas próprias entradas. Para cada passo de alocação que o fluxo de trabalho executa, se aquilo que escreve regressa — através de quaisquer passos, em qualquer fluxo de trabalho — à tabela que aloca ou à sua tabela de indutores. Quando isso acontece, quanto o passo aloca, ou como o distribui, depende do que alocou numa execução anterior. O Weave indica os passos pelos quais o ciclo passa e pede-lhe que verifique se o ciclo é intencional. Um ciclo que não passa por nenhum passo de alocação, como uma carga incremental que lê a tabela à qual acrescenta linhas, não é comunicado.
• Tabelas e colunas de indutores de alocação. Se a tabela de indutores que um passo de alocação utiliza existe e tem todas as colunas que o passo lê dela. Uma coluna de indutor que o passo preenche com uma constante ou uma expressão não é procurada. Uma tabela de indutores construída noutro local é verificada tal como está agora; quando um passo deste fluxo de trabalho a constrói, as suas colunas só são conhecidas depois de esse passo ser executado, pelo que o Weave comunica a alocação como não verificada em vez de aprovada. Também comunica a alocação como não verificada quando o passo escolhe a sua tabela de indutores com uma variável ou um caminho de pasta, quando o fluxo de trabalho é uma macro e quando a sua função não consegue ver a tabela.
• Segurança ao nível da linha numa coluna com o nome alterado. Para cada tabela que o fluxo de trabalho escreve, se tem uma coluna etiquetada com a dimensão que um atributo de segurança ao nível da linha utiliza, mas sem o nome desse atributo. A segurança ao nível da linha só filtra colunas com o nome dos seus atributos, pelo que não filtra essa coluna. Esta verificação requer a função Arquiteto no projeto; para qualquer outra pessoa, a revisão indica que não foi verificada, e o mesmo acontece para uma tabela que o fluxo de trabalho indica com uma variável ou um caminho de pasta.

Uma revisão abre dizendo o que encontrou e sobre que parte do fluxo de trabalho, e nunca termina com um atestado de boa saúde:

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.

Os passos que a sua função não consegue ver contam para o total, e a revisão indica que não os verificou.

Uma revisão lista o que não verifica. Não executa as verificações do Weave sobre tabelas — se uma tabela escrita segundo um agendamento está atrasada e se uma tabela que o fluxo de trabalho lê foi escrita entretanto — que leem o projeto inteiro e são executadas no separador Weave. Para um fluxo de trabalho com passos de alocação, não verifica se cada montante a alocar encontra uma linha de indutor ou um membro de dimensão correspondente, se as tabelas de origem e de indutores contêm valores ao mesmo nível de detalhe, nem ciclos que passam por um passo que indica a sua tabela dentro de SQL ou com uma variável.

Para rever um fluxo de trabalho, abra-o na respetiva área de desenho ou na grelha Passos e escolha Verificar. O botão está disponível para quem pode editar o fluxo de trabalho e ler as tabelas do projeto. A janela Verificação Weave mostra, por esta ordem:

• as linhas de abertura da revisão;
• Resumo (escrito por IA), quando a revisão tem um resumo;
• os Problemas da revisão e, depois, o que Não foi possível verificar. Um problema para o qual o resumo aponta é marcado com No resumo, e Ir para junto à constatação de um passo seleciona esse passo onde escolheu Verificar;
• O que esta verificação não abrange, sempre em último lugar.

Escolher Verificar novamente executa uma nova revisão na mesma janela.

Também pode pedir a um assistente de IA ligado através do PlaidCloud MCP que reveja um fluxo de trabalho — a ferramenta é workflow_review — ou chamar a API da plataforma. Uma revisão requer acesso de leitura aos passos, fluxos de trabalho e tabelas do projeto. As três verificações acima não aparecem no separador Weave; o Weave executa-as apenas numa revisão.

Na janela Verificação Weave e através da API da plataforma, uma revisão que encontra problemas inclui também um resumo de uma ou duas frases escrito pela IA integrada do PlaidCloud, e até três dos seus problemas a analisar primeiro. À IA são mostrados apenas os problemas da revisão. Antes de o resumo ser devolvido, os problemas para os quais aponta têm de ser os da própria revisão, qualquer nome que cite e qualquer algarismo que escreva têm de aparecer nesses problemas, e não pode utilizar uma expressão como “nenhum outro problema”. Um resumo que não cumpra estas condições é descartado, e a revisão é devolvida sem resumo. Uma revisão sem problemas não tem resumo. Através de um assistente de IA, a revisão não tem resumo; o próprio assistente lê as constatações.

Ser avisado quando uma execução termina

Quando a execução de um fluxo de trabalho termina, o Weave analisa esse fluxo de trabalho e avisa o responsável de cada problema — consulte Atribuir um responsável a uma constatação — sobre os problemas que regista contra esse fluxo de trabalho, as suas execuções e a configuração guardada dos seus passos, sem distinção, que ainda não leu no separador Weave do projeto, através de uma mensagem na aplicação. Um problema sem responsável, ou cujo responsável já não o consegue ver, vai para a pessoa a quem a execução pertence: a pessoa que a iniciou ou, no caso de uma execução agendada, a pessoa que guardou o agendamento pela última vez. Cada problema é mencionado uma vez. Enquanto não o tiver lido no separador Weave, as execuções seguintes não o voltam a mencionar, pelo que um Workflow Loop que executa muitos fluxos de trabalho não lhe enche o ecrã de repetições. A contagem no botão Weave mantém-no até o ler.

A mensagem fica no ecrã durante 30 segundos e tem uma ligação Abrir Weave, que abre o separador Weave do projeto nas constatações sobre o fluxo de trabalho que foi executado. Clique em qualquer outro ponto da mensagem para a fechar.

Enquanto estiver no ecrã uma mensagem do Weave sobre um projeto, uma nova sobre o mesmo projeto junta-se a ela em vez de aparecer por baixo. A mensagem mostra a frase mais recente, seguida de uma linha como Mais 2 neste projeto., e fica no ecrã durante 30 segundos a contar da mais recente. Quando as mensagens dizem respeito a fluxos de trabalho diferentes, Abrir Weave abre o separador Weave completo. Assim, fluxos de trabalho que falham com momentos de diferença dão-lhe uma mensagem em vez de uma por cada um. Um lembrete de prontidão aparece sempre isolado.

Depois de ler um problema, este só volta a ser mencionado quando aquilo que diz mudar. Uma constatação de execução descreve a execução de onde provém — a data, a hora, as contagens — pelo que um fluxo de trabalho que falha todas as noites é mencionado novamente na falha seguinte depois de ter lido a última. Um problema de configuração diz a mesma coisa de execução para execução, pelo que, depois de o ter lido, não é repetido a cada execução.

Uma execução parada não envia nada, seja quem for que a tenha parado. Um fluxo de trabalho executado por um passo Macro Run ou Macro Concurrent não envia nada por si, e essa chamada não é contada entre as suas execuções; um fluxo de trabalho iniciado por um passo Executar fluxo de trabalho ou Workflow Loop é uma execução desse fluxo de trabalho como qualquer outra. Os elementos que o Weave não conseguiu verificar nunca são enviados desta forma, nem as constatações sobre tabelas escritas segundo um agendamento ou sobre tabelas de um fluxo de trabalho escritas desde que as leu: o Weave avisa sobre essas entre execuções. Consulte Ser avisado entre execuções.

Ser avisado não é o mesmo que ter lido: um alerta não marca a constatação como lida no separador Weave, e seguir a ligação Abrir Weave também não.

Cada problema sobre o qual uma mensagem o avisa é adicionado à contagem no botão Weave do cabeçalho. Consulte O botão Weave no cabeçalho.

Ser avisado entre execuções

Alguns problemas surgem sem nada em execução: uma tabela que não foi escrita segundo o seu agendamento ou dentro do seu limite de atualidade; uma execução agendada que não foi iniciada, ou que chegou à hora prevista enquanto o fluxo de trabalho ainda estava a ser executado; um fluxo de trabalho cujas tabelas outro fluxo de trabalho escreveu desde a última vez que as leu; e um fluxo de trabalho ou painel de controlo que depende de uma tabela que uma execução falhada não terminou. Nenhum fim de execução o pode avisar sobre estes, pelo que, uma vez por hora, o Weave verifica cada projeto à procura deles e avisa o responsável de cada problema — consulte Atribuir um responsável a uma constatação — através de uma mensagem na aplicação.

A verificação horária avisa-o sobre cada um destes problemas uma vez, por mais verificações que o encontrem, e a sua primeira verificação de um projeto avisa-o sobre os que já lá estão, por mais tempo que lá estejam. Só o volta a avisar depois de o problema ter desaparecido e voltado, ou depois de o ter lido e aquilo que diz ter mudado, como uma execução agendada posterior que também não foi iniciada. Um problema de agendamento faz também parte das verificações do próprio fluxo de trabalho, mas, depois de a verificação horária o ter avisado sobre ele, a mensagem quando a próxima execução do fluxo de trabalho terminar não o repete até o ter lido — consulte Ser avisado quando uma execução termina. Vários problemas num projeto chegam numa única mensagem, que os conta e cita o primeiro:

O Weave detetou 3 problemas no projeto “Finance Close”, a começar pela tabela “Sales Daily”: o passo “Load Sales” escreveu-a pela última vez a 14 Oct 06:00 UTC, e o fluxo de trabalho “Nightly Load” deveria ter sido executado segundo o seu agendamento desde então

Uma tabela que mais do que um fluxo de trabalho escreve não tem responsável até alguém o atribuir. Quando não foi escrita segundo o agendamento, o Weave avisa o responsável de cada fluxo de trabalho que a deveria ter escrito e não o fez. Qualquer outro problema sem responsável não é enviado; é listado no separador Weave do projeto.

A verificação é executada como cada responsável, pelo que uma mensagem indica apenas o que a sua função lhe permite ver. Só é avisado como membro ativo do projeto cuja função lhe permite ver os respetivos passos e fluxos de trabalho, e sobre tabelas apenas se puder ler tabelas.

A mensagem fica no ecrã durante 30 segundos e tem uma ligação Abrir Weave, que abre o separador Weave do projeto, no fluxo de trabalho quando todos os problemas da mensagem dizem respeito ao mesmo. Uma mensagem só é mostrada enquanto tiver sessão iniciada, mas cada problema sobre o qual avisa é adicionado à contagem no botão Weave do cabeçalho, pelo que um que não tenha visto continua a ser contado aí. Ser avisado não marca uma constatação como lida.

Marcar uma constatação como lida

Cada constatação tem um id, e pode marcá-la como lida para que deixe de aparecer como nova — no separador Weave do projeto, clique em Marcar como lido no respetivo cartão (consulte Marcar constatações como lidas). O id é derivado da própria constatação, pelo que uma constatação que dispensou volta a aparecer como nova se o problema subjacente mudar — um passo que marcou como lido depois de corrigir uma coluna volta a aparecer se, mais tarde, outra coluna deixar de funcionar.

O estado de leitura é apenas seu. Marcar uma constatação como lida não a marca como lida para mais ninguém no projeto.

Enquanto estiver a ser executado um fluxo de trabalho que escreve uma tabela atrasada, o Weave comunica a tabela como não verificada. Se marcar qualquer constatação como lida durante esse período e a execução terminar sem escrever a tabela, a respetiva constatação volta a aparecer como nova.

Dois passos diferentes listados duas vezes num fluxo de trabalho são duas constatações, pelo que marcar uma como lida deixa a outra por ler. Um fluxo de trabalho sem nome aparece como “fluxo de trabalho sem nome”, e uma verificação que não pôde ser executada é indicada pelo seu título, como “A última execução falhou”.

Um resumo periódico

Um resumo periódico é o mesmo relatório reduzido ao que ainda não leu, na mesma voz. Pode pedir um a qualquer momento e pode recebê-lo como notificação na aplicação, com uma ligação Abrir Weave para o separador Weave do projeto.

As constatações que o Weave não conseguiu verificar fazem parte de um resumo periódico como quaisquer outras. Um resumo periódico que as omitisse silenciosamente seria exatamente o silêncio tranquilizador que a terceira resposta existe para evitar.