Qué comprueba Weave
Descripción
Sección titulada «Descripción»Weave lee la configuración que su proyecto ya tiene guardada y el registro de cómo se han ejecutado sus flujos de trabajo durante los últimos 30 días, e informa de lo que encuentra: un paso cuya asignación no tiene nada que asignar, un flujo de trabajo cuya estructura guardada incluye el mismo paso dos veces, un flujo de trabajo cuya última ejecución falló, un paso cuya salida contiene muchas menos filas de lo habitual. Solo lee: nada de lo que informa modifica un paso, y nunca ejecuta su flujo de trabajo.
No interviene ningún modelo de IA. Cada comprobación es una regla fija y cada frase está escrita de antemano, de modo que generar un informe no cuesta nada, sin importar con qué frecuencia lo solicite.
Tres respuestas, no dos
Sección titulada «Tres respuestas, no dos»La mayoría de las comprobaciones de PlaidCloud tienen dos respuestas: su configuración es correcta o se rechaza. Weave tiene una tercera, y es la que conviene entender.
| Respuesta | Qué significa |
|---|---|
| Weave detectó … | Weave comprobó esto y encontró un problema. |
| (no dice nada) | Weave comprobó esto y no encontró nada incorrecto. |
| Weave no ha comprobado … | Weave no pudo evaluar esto en absoluto. |
La tercera existe porque el silencio es ambiguo. Cuando crea un paso de asignación, PlaidCloud le permite guardarlo antes de haber completado su asignación de columnas: todavía lo está construyendo, y rechazar el guardado le impediría trabajar. Un monitor que leyera esa misma asignación vacía podría informar fácilmente de que el paso está en buen estado. No lo está; está sin terminar, y nadie lo ha revisado.
Por eso Weave lo dice. Un paso que no pudo evaluar se informa como sin comprobar, con el motivo, y nunca se cuenta, se ordena ni se colorea como si hubiera pasado la comprobación.
Weave puede decir además una cuarta cosa, que no es una respuesta sobre su paso en absoluto: Weave no tiene ninguna regla para …. Significa que Weave no tiene ninguna comprobación para ese tipo de elemento y nunca lo evaluó. A diferencia de “no ha comprobado”, nada de lo que haga con el paso producirá un veredicto, así que conviene distinguirlos: si termina un paso sin comprobar, Weave lo evaluará; un paso para el que no tiene ninguna regla seguirá sin evaluarse por mucho que lo cambie.
Cómo es un informe
Sección titulada «Cómo es un informe»Un informe comienza con un resumen que indica su propio denominador, de modo que pueda ver qué parte del proyecto abarca:
Weave fully checked 3 of the 417 steps and workflows in "Cost Model", and found 1problem 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 beenjudged either way.
Weave noticed the step "Spread Overheads": No driver split value column found. Onedriver column must have the role "Split Value".Weave hasn't checked the step "Regional Split" — its column mapping is empty.Cuando un proyecto tiene tablas que se escriben según una programación o a las que se les ha dado un umbral de actualización, la primera línea las cuenta por separado: Weave comprobó por completo 31 de los 36 pasos y flujos de trabajo, y 3 de las 4 tablas que deben mantenerse al día, en “Finance”, y encontró 2 problemas en las partes que pudo evaluar.
La fracción de la primera línea es deliberada. Tres pasos comprobados y sin problemas no equivalen a un proyecto sin problemas, y la línea inicial lleva su propia escala para que no pueda citarse sin ella. “En las partes que pudo evaluar” está ahí por la misma razón: cuando algo se evaluó solo en parte, los problemas encontrados no pueden atribuirse a los pasos que la línea acaba de llamar comprobados. La segunda línea nombra aquello para lo que Weave no tiene ninguna regla y dice en voz alta que tampoco se ha evaluado en un sentido ni en otro, no que no hiciera falta una comprobación.
Cómo lo sabe Weave
Sección titulada «Cómo lo sabe Weave»Cada hallazgo tiene debajo un vínculo Cómo lo sabe Weave, que abre un panel que muestra cómo llegó Weave a él:
- La comprobación: lo que prueba la regla, en palabras sencillas, con los límites que utiliza, como con cuántas ejecuciones anteriores compara un recuento.
- La evidencia: los valores que usó la comprobación. Para un recuento de filas que cambió, son el último recuento, el promedio de las ejecuciones anteriores, cuánto suele variar el recuento de una ejecución a otra y el intervalo fuera del cual Weave lo informa.
- De dónde proviene: la ejecución, el historial de ejecuciones, la configuración guardada del paso, el evento programado o la tabla de la que se leyó la evidencia. Si se muestra como vínculo, abre el lugar donde la vería, como el flujo de trabajo o el Explorador de tablas.
- Lo que Weave no comprobó: lo que la regla deja fuera. Nunca está vacío: una comprobación de que una tabla se escribió a tiempo, por ejemplo, no examina lo que se escribió.
Para un hallazgo que Weave no pudo comprobar, el panel muestra la comprobación y el motivo por el que no pudo ejecutarse, y ninguna evidencia.
El panel nombra solo lo que usted puede ver. Un paso, flujo de trabajo o tabla que su rol oculta aparece como uno que no puede abrir, nunca por su nombre, y cuando la última ejecución de un flujo de trabajo falló en pasos que no puede abrir, la evidencia cuenta esos pasos en lugar de nombrarlos. En la construcción del panel no interviene ninguna IA.
El panel aparece en la pestaña Weave y en una revisión. El resumen de una revisión redactado por IA también lo tiene, e indica que fue redactado por IA, a partir de cuántos hallazgos y qué comprobó Weave antes de mostrarlo. Una revisión que ejecuta un asistente de IA a través de PlaidCloud MCP omite el panel.
Qué comprueba Weave hoy
Sección titulada «Qué comprueba Weave hoy»Asignación de columnas de una asignación. Para un paso Allocation with Dimension o Allocation Split, que haya una columna numérica que asignar, un valor numérico de inductor por el que asignarla, una jerarquía cuando se necesite una y, para una división, un numerador y un denominador que nombre una columna que la tabla de origen realmente tenga. Son las mismas comprobaciones que se ejecutan al guardar el paso, aplicadas a lo que ya estaba guardado. Al guardar también se comprueba la propia dimensión de asignación, es decir, que exista y que tenga exactamente una propiedad de inductor, algo que Weave no hace, por lo que un paso que el guardado rechaza por ese motivo no produce ningún hallazgo de Weave.
Expresiones de los pasos. Para cualquier paso que las tenga, que todas las expresiones que haya escrito (en una columna de destino, en la cláusula de subconjunto o en la cláusula de filtro secundario) sigan compilando. Un hallazgo nombra la columna o la cláusula para que sepa cuál abrir, y da el error, como Syntax error at line 1, position 280. La expresión en sí está en Cómo lo sabe Weave, para que una expresión larga no oculte el error. Son las mismas comprobaciones que se ejecutan al guardar el paso.
Hay dos casos que Weave informa como sin comprobar en lugar de evaluarlos:
- Una expresión que lee una variable. Un paso puede pertenecer a más de un flujo de trabajo, y cada flujo de trabajo puede asignar a una variable un valor distinto, o no asignarla en absoluto. La puerta de guardado sabe desde qué flujo de trabajo está guardando; un análisis no. En lugar de elegir uno y arriesgarse a calificar de rota una expresión que funciona, Weave informa del paso como sin comprobar cuando la variable no está asignada en todos los flujos de trabajo o está asignada con valores que no coinciden. Un flujo de trabajo que su rol no le muestra cuenta igual: Weave tampoco puede leer sus variables, así que no afirmará que el paso concuerda. Cuando todos los flujos de trabajo coinciden, evalúa el paso con normalidad.
- Filtros y listas de columnas que esta comprobación no lee. Algunos tipos de paso guardan un filtro o una segunda lista de columnas en una parte del formulario que la comprobación de expresiones nunca ha leído: las combinaciones de dos tablas y Lookup, las divisiones de asignación, Generate Batch y SAP Post Journal Entry. Al guardar esos pasos siempre se han omitido esos campos, así que Weave no da por bueno el paso por la mitad que sí puede leer: lo informa como sin comprobar. Los pasos Combinación de varias tablas y Delete se informan de la misma manera, porque su configuración no tiene una forma que esta comprobación pueda compilar.
Algo que aparece dos veces en un flujo de trabajo. Que ningún paso ni ningún flujo de trabajo anidado aparezca más de una vez en el mismo flujo de trabajo, y que dos carpetas que comparten el mismo elemento superior no lleven el mismo identificador.
Pasos que pueden ejecutarse antes de que se escriba la tabla que leen. En un flujo de trabajo avanzado, que todo paso que lee una tabla se ejecute después del paso del mismo flujo de trabajo que la escribe, a través de los conectores del lienzo. Weave lo comprueba tanto si el flujo de trabajo se ha ejecutado alguna vez como si no. Un hallazgo nombra uno de esos pasos y el paso después del cual debería ejecutarse, e indica cuántos pasos están afectados; las tablas se enumeran en Cómo lo sabe Weave. Un paso que el lienzo ya ejecuta demasiado pronto se informa por separado. Weave informa del flujo de trabajo como sin comprobar cuando un paso ejecuta otro flujo de trabajo o usa tablas que no puede seguir, y no evalúa una tabla que escriba más de un paso u otro flujo de trabajo. Para revisar y agregar los conectores que faltan, use Sincronizar dependencias en el lienzo. Si un paso debe leer la salida de la ejecución anterior, marque el hallazgo como esperado.
Cómo se ejecutaron sus flujos de trabajo. Weave lee las ejecuciones de cada flujo de trabajo de los últimos 30 días (hasta las veinte ejecuciones más recientes de cada uno) y juzga la última frente a las anteriores. Para las comparaciones de fin de mes y de día de la semana que se describen más abajo, también lee algunas ejecuciones más antiguas de los últimos 180 días. Toda comparación se hace con el propio historial del flujo de trabajo, nunca con el de otro.
-
Error en la última ejecución. Se informa de un flujo de trabajo cuya ejecución más reciente falló, con la fecha del error y, si las ejecuciones anteriores también fallaron, cuántas seguidas y desde cuándo.
-
Ejecución más lenta de lo habitual. Una ejecución que terminó, pero cuyos pasos tardaron, en conjunto, más de lo que permiten las ejecuciones terminadas anteriores del flujo de trabajo: más de dos desviaciones estándar por encima de su promedio y al menos un 5 % por encima de él (nunca menos de un segundo, para que un flujo de trabajo rápido no se informe por unos pocos milisegundos). El tiempo es el de los pasos sumados, por lo que en un flujo de trabajo que ejecuta pasos en paralelo es mayor que lo que marcó el reloj. Una ejecución que terminó más rápido no se informa.
-
Paso más lento de lo habitual. Un paso que tardó más en su última ejecución completada que en sus ejecuciones completadas anteriores en ese flujo de trabajo, con la misma medida que una ejecución lenta. Así nombra Weave el paso que está detrás de una ejecución lenta. Un paso que está en varios flujos de trabajo se evalúa por separado en cada uno. El tiempo va desde el inicio del paso hasta su fin: Weave no separa el trabajo propio del paso del tiempo de espera, por ejemplo por un almacén de datos ocupado.
-
Las ejecuciones se han vuelto más lentas. Una ralentización que se ha mantenido. Cuando las ejecuciones lentas son la mayoría de las ejecuciones anteriores con las que se compara una ejecución, una ejecución lenta deja de parecer inusual, por lo que esta comprobación compara mitades. Weave lee las últimas 20 ejecuciones del flujo de trabajo de los últimos 30 días, conserva las que se completaron y las divide en una mitad más antigua y una mitad más reciente según cuándo empezaron. Informa del flujo de trabajo cuando la mediana del tiempo de la mitad más reciente es al menos un 25 % y al menos 30 segundos mayor que la de la mitad más antigua, y la ejecución más reciente tardó más en al menos el 85 % de los emparejamientos de una ejecución más reciente con una más antigua. El tiempo es el de los pasos sumados, igual que en una ejecución lenta. Weave necesita al menos 12 ejecuciones completadas repartidas en al menos 14 días, por lo que no se comprueba un flujo de trabajo que se ejecuta más de unas 20 veces en dos semanas. Las ejecuciones fallidas y detenidas no se cuentan; una ejecución que continuó tras un paso fallido sí. El hallazgo nombra hasta tres pasos que usted puede abrir y cuyo tiempo mediano creció más, y su frase no cambia mientras dure la ralentización, para que no se le avise de nuevo después de cada ejecución.
-
Filas de destino distintas de las ejecuciones anteriores. Un paso cuyas tablas de salida contenían muchas más o muchas menos filas tras su última ejecución que tras sus ejecuciones anteriores en ese flujo de trabajo, con la misma medida (y en al menos una fila). El recuento es lo que contienen las tablas, por lo que un paso que anexa se juzga según el total creciente. Un paso que está en varios flujos de trabajo se evalúa por separado en cada uno.
-
Una combinación duplicó más filas de lo habitual. Una combinación interna, izquierda o derecha que escribió más filas por cada fila de su tabla principal que tras sus ejecuciones anteriores en ese flujo de trabajo: más de dos desviaciones estándar por encima de su promedio y al menos un 5 % de este. La tabla principal es la tabla A en una combinación interna o izquierda y la tabla B en una combinación derecha. Que se escriba más de una fila por cada fila de la tabla principal significa que algunas de sus claves de combinación aparecen en más de una fila de la otra tabla, por lo que las filas que las contienen se escribieron más de una vez. Weave informa solo de una cifra superior a 1,00, y solo cuando supera el nivel habitual de la combinación, de modo que una combinación que escribe varias filas por fila por diseño se informa únicamente si ese número aumenta. En una combinación interna, solo se ven las claves que se repiten en la tabla B. Una combinación con menos de cuatro ejecuciones anteriores que registraron las filas de su tabla principal se informa como sin comprobar.
Una combinación que agrega, o que usa Distinto, segmentación (Limit) o un filtro secundario, se informa como sin comprobar, porque cada una de esas opciones cambia por sí misma el recuento de filas. También se informa así una combinación cuya tabla principal no tiene un recuento de filas registrado, como una vista. Las filas de la tabla principal son las registradas cuando se escribió por última vez, antes del filtro del paso sobre ella. Un filtro que conserva una proporción distinta de sus filas en cada ejecución también mueve la cifra y puede ser informado. No se ve un cambio hecho en la tabla principal de otra forma, ni por un paso que se ejecute al mismo tiempo. Las combinaciones externas completas, cruzadas y de varias tablas no se comprueban, y un paso Lookup no puede escribir una fila más de una vez.
-
Valores vacíos distintos de las ejecuciones anteriores. Una columna de la tabla de salida de un paso que quedó vacía en una proporción de sus filas mucho mayor o menor que tras las ejecuciones anteriores del paso: a más de dos desviaciones estándar de la proporción habitual y a al menos cinco puntos porcentuales de ella. Cada tabla que escribe un paso se juzga sobre sus propias filas.
-
La importación no encontró archivos. Un paso de importación cuya ejecución completada más reciente no encontró archivos en la ruta de la que lee. El paso termina con una advertencia en lugar de fallar, y crea su tabla de destino vacía o no carga nada, por lo que los pasos posteriores no tienen nada que leer de él. El hallazgo nombra el flujo de trabajo y la ruta, no necesita ejecuciones anteriores y desaparece cuando una ejecución encuentra archivos. Un paso que está en varios flujos de trabajo se evalúa por separado en cada uno, y en un flujo de trabajo que usted no puede abrir no se muestra la ruta. Weave no puede distinguir una carpeta vacía a propósito de un archivo que falta: si una carpeta vacía es lo normal en ese lugar, un Arquitecto del proyecto puede marcar el hallazgo como esperado, y Weave deja de informar de él para ese paso en ese flujo de trabajo, sea cual sea la ruta. Una ejecución registrada antes de que existiera esta comprobación no conserva la redacción de la advertencia, por lo que su paso se informa como sin comprobar hasta que se ejecute de nuevo.
Fines de mes y días de la semana. Para un flujo de trabajo o paso que se ejecuta como máximo una vez al día, una ejecución que estas comprobaciones informarían se exime cuando concuerda con al menos cuatro ejecuciones anteriores en el mismo tipo de día, de los últimos 180 días, que no varían más, para su tamaño, que sus ejecuciones anteriores en otros días. Los tipos de día son el último día de un mes, el primer día de un mes y, en los demás casos, el mismo día de la semana. Así, una carga de fin de mes que siempre es pesada, o una carga que siempre es ligera los lunes, no se informa cuando esas ejecuciones son más estables para su tamaño que las de los demás días. El calendario solo exime a una ejecución: nunca informa de una que estas comprobaciones aprobarían. Los días se cuentan en UTC, y no se tienen en cuenta los días festivos ni los calendarios de días laborables. Un flujo de trabajo o paso que se ejecuta más de una vez en un día, incluida una ejecución fallida y su repetición, se compara con sus ejecuciones anteriores como antes.
Una línea base necesita al menos cuatro ejecuciones anteriores. Con menos, el flujo de trabajo se informa como sin comprobar en cuanto a su tiempo de ejecución, y sus pasos como sin comprobar en cuanto a sus filas y valores vacíos, cada uno indicando cuántas ejecuciones terminadas ha tenido, en lugar de juzgarse con muy pocos datos. Un paso que escribe una tabla pero cuyas ejecuciones registradas no llevan recuentos de valores vacíos también se informa como sin comprobar en ese aspecto. Un paso que no escribe ninguna tabla, como uno que envía un correo electrónico o exporta un archivo, no se comprueba en cuanto a filas ni valores vacíos. Un flujo de trabajo que no se ha ejecutado en los últimos 30 días se informa como sin comprobar, igual que uno cuyo historial de ejecuciones no se pudo leer; ninguno se informa como en buen estado. En un proyecto con Acceso a filas declarado, las comprobaciones de filas, combinación, valores vacíos y dispersión de valores no se aplican a quien tenga las lecturas filtradas: cada una se mide sobre la tabla completa, por lo que un hallazgo le informaría de filas que están fuera de su concesión. Consulte Recuentos de filas y tamaños de tablas.
Qué cambió la última ejecución de un paso. Para cada tabla que escribió la última ejecución de un paso, Weave compara la tabla tal como la dejó la ejecución con la tabla tal como estaba antes de que la ejecución empezara, por lo que no necesita el historial de ejecuciones anteriores.
- Valores dispersos de forma distinta a la de antes de la última ejecución. Una columna cuyos valores se dispersan por su intervalo de forma muy distinta después de la ejecución que antes. El hallazgo da una puntuación de cambio: 0 significa que la dispersión no cambió, y 0,25 o más es un cambio grande, que es cuando Weave lo informa. Solo se comparan las columnas que contienen números decimales. Las columnas de números enteros suelen ser códigos, períodos o indicadores, como un número de cuenta o un mes, y su dispersión cambia cada vez que se cargan períodos nuevos. Los valores vacíos no forman parte de la dispersión; los cubre la comprobación de valores vacíos anterior.
“Antes de la ejecución” es la última versión de la tabla que contenía filas. Una versión que dejó vacía una ejecución que falló a medias se omite, de modo que la primera ejecución correcta tras un fallo se compara con los últimos datos correctos.
La ejecución de un paso se informa como sin comprobar, con el motivo, cuando una tabla que escribió:
- tiene Acceso a filas declarado en sus columnas;
- contenía más de 5.000.000 de filas antes o después de la ejecución;
- tardó más de 10 segundos en compararse;
- ya no conserva su versión anterior a la ejecución: algunos lakehouses conservan versiones anteriores de una tabla durante 7 días, por lo que una tabla que se reescribe con menos frecuencia que una vez por semana no tiene nada con lo que compararse; o
- se llenó por primera vez en esa ejecución.
Un proyecto cuyo lakehouse no conserva historial de versiones no se juzga en absoluto con esta comprobación.
Valores que quedan vacíos por una conversión de tipo. Cada columna que escribe
un paso Extract tiene un tipo, como texto, entero o fecha, y el paso convierte
cada valor a ese tipo. En un lakehouse StarRocks, un valor que no se puede
convertir, como N/A al pasar a una columna de enteros, se almacena vacío, y la
ejecución termina sin error. Después de que un paso Extract se ejecuta en
StarRocks, Weave cuenta, para cada columna cuya conversión podría perder valores,
los valores de entrada que no estaban ya vacíos y cuántos de ellos salieron vacíos,
e informa de cada columna donde alguno lo hizo. El hallazgo da el recuento y el
tipo de la columna. Juzga la última ejecución completada del paso en cada flujo de
trabajo, por lo que no necesita ejecuciones anteriores.
- Los valores que ya estaban vacíos al entrar no se cuentan. El texto en blanco sí, porque se almacena vacío en una columna numérica o de fecha.
- Una columna cuya conversión no puede perder un valor, como números enteros que pasan a una columna decimal, no se cuenta, ni tampoco una columna sin valores vacíos después de la ejecución.
- Si el recuento tarda más de 30 segundos, o las filas que Weave cuenta no coinciden con las filas que escribió el paso, la ejecución se informa como sin comprobar, y Weave vuelve a contar la próxima vez que se ejecute el paso.
- Solo se comprueban los pasos Extract en StarRocks. Un paso que usa un filtro secundario o agrupa por una expresión se informa como sin comprobar, y también uno que usa Distinto o segmentación (Limit) cuando una columna podría perder valores, porque Weave no puede volver a contar sus filas sin la conversión.
- Si el paso debe dejar esos valores vacíos, un Arquitecto del proyecto puede marcar el hallazgo como esperado.
- Igual que las comprobaciones de filas y de valores vacíos, no se aplica a quien tenga las lecturas filtradas por Acceso a filas.
Eventos programados. Para un flujo de trabajo con eventos programados, Weave compara cada evento con las ejecuciones que ha iniciado y con el trabajo del clúster que lo activa. Cada hora se toma en la zona horaria del propio evento, y una activación se juzga 15 minutos después de su vencimiento, para dar tiempo a que su trabajo se inicie.
- Horario del evento programado no válido. Un evento habilitado cuya programación no se puede leer.
- La ejecución programada no se inició. Un evento habilitado que ha vencido sin iniciar una ejecución, desde la última vez que inició una o desde que se guardó, si nunca lo ha hecho. Cuando el clúster puede indicarlo, Weave añade si el clúster nunca activó el evento o si el trabajo que activó falló. El hallazgo nombra la última ejecución que inició el evento, o la hora en que se guardó, de modo que sigue siendo un solo hallazgo mientras el evento permanezca roto de la misma manera. Un evento guardado después de que venciera su activación no se juzga por esa activación.
- El evento programado venció durante una ejecución. Un evento que venció mientras el flujo de trabajo seguía ejecutándose, por lo que entonces no se inició ninguna ejecución. Un evento programado nunca inicia una segunda ejecución de un flujo de trabajo que ya se está ejecutando; esto se informa una vez para que una programación más ajustada que las ejecuciones del flujo de trabajo no pierda activaciones sin que se vean.
- Evento programado desincronizado con el clúster. Un evento y su trabajo en el clúster que no coinciden: un evento habilitado sin trabajo, o con su trabajo en pausa; un evento deshabilitado cuyo trabajo no está en pausa; o un trabajo con una programación o zona horaria distinta de la que muestra el evento. Cuando no se puede leer el clúster, el flujo de trabajo se informa como sin comprobar en cuanto a sus eventos programados.
Un evento que ha dejado de iniciar ejecuciones no tiene el final de una ejecución que se lo diga, por lo que aparece en la pestaña Weave y no como un mensaje.
Tablas escritas según una programación. Para una tabla que escribe un flujo de
trabajo con un evento programado habilitado, Weave comprueba que la tabla se haya
escrito desde la última vez que venció la programación. Una tabla cuenta como
escrita cuando termina un paso que la escribe. Weave no examina los datos de la
tabla, por lo que no ve una carga hecha fuera de los pasos del proyecto. Igual que
en las comprobaciones de eventos programados, cada programación se lee en la zona
horaria de su evento y se juzga 15 minutos después de su vencimiento. Weave
comprueba solo las tablas que su rol le permite ver; sin el rol analyze.table.read
no comprueba ninguna tabla, y su primera línea cuenta solo pasos y flujos de
trabajo.
- Tabla no escrita según la programación. Una tabla que ningún paso ha escrito desde que venció, según su programación, un flujo de trabajo que la escribe. Cuenta la escritura de cualquier paso, incluida la de otro flujo de trabajo o la de una ejecución que usted mismo inició. El hallazgo da la hora de la última escritura en lugar de cuánto tiempo hace de ella. Una ejecución que falló cuenta como no escrita, por lo que las tablas de un flujo de trabajo programado que falla se informan aquí además de en Error en la última ejecución.
Weave informa de una tabla como sin comprobar, con el motivo, en lugar de como no escrita, cuando:
- un flujo de trabajo que la escribe se está ejecutando, está en cola o acaba de terminar y sus resultados todavía no se han registrado;
- un paso que la escribe se omitió en una ejecución desde que venció la programación, ya sea por sus propias condiciones o porque no encontró nada que hacer, como una importación cuyos archivos no habían cambiado;
- un paso que la escribe puede omitirse sin que quede registro de la omisión: está en un flujo de trabajo estándar con una condición que salta a otro paso, o en un flujo de trabajo Estándar en serie con un paso que pasa a otro paso cuando falla, o está en un contenedor con condiciones o en un bucle que puede ejecutarse cero veces;
- el flujo de trabajo terminó una ejecución desde que venció, pero falta el registro del paso que escribe de esa ejecución;
- un paso, en cualquier parte del proyecto, elige con una variable la tabla que escribe y Weave no puede determinar el valor de esta, por lo que podría escribir esta tabla;
- la programación se ejecuta con menos frecuencia que cada 180 días, que es hasta donde llega el historial de ejecuciones de Weave; o
- la programación de un flujo de trabajo no es válida, o el historial de ejecuciones no se puede leer.
Una tabla no se comprueba en absoluto cuando:
- no tiene umbral de actualización (más adelante) y ningún flujo de trabajo con un evento programado habilitado propio la escribe. Un flujo de trabajo al que ejecuta otro flujo de trabajo, mediante un paso Ejecutar flujo de trabajo o Macro, o como flujo de trabajo colocado dentro de él, cuenta solo a través de su propia programación;
- los únicos pasos que la escriben están deshabilitados, están en un contenedor deshabilitado o están en un punto de interrupción o después de él; o
- es una vista.
El segundo de estos casos no se aplica dentro de un bucle que se ejecuta: un bucle ejecuta todos los pasos que contiene, incluso uno deshabilitado, en un contenedor deshabilitado o en un punto de interrupción o después de él.
Un evento programado guardado después de la última vez que venció no se juzga hasta que vuelva a vencer.
Un flujo de trabajo cuyas ejecuciones tardan más que el intervalo de su programación omite las activaciones que vencen mientras se está ejecutando, por lo que entre ejecuciones sus tablas pueden informarse como no escritas; El evento programado venció durante una ejecución informa de la causa.
Cuando el paso que escribió por última vez una tabla es uno al que usted no tiene acceso, el hallazgo dice “un paso al que no tiene acceso” y aun así da la hora de la escritura. “180 días” en un hallazgo es hasta dónde llega el historial de ejecuciones de Weave, no un dato sobre la tabla.
Tablas con un umbral de actualización. Un umbral de actualización es el máximo de horas que pueden pasar entre escrituras de una tabla, de 1 a 4320 (180 días). Una tabla con umbral se juzga según este en lugar de según las programaciones de los flujos de trabajo que la escriben. Eso le permite fijar un límite más laxo o más estricto que el que da una programación, y comprobar una tabla que no escribe ningún flujo de trabajo programado. Igual que con las programaciones, una tabla cuenta como escrita cuando termina un paso que la escribe.
- Tabla no escrita dentro de su plazo. Ningún paso ha escrito la tabla durante más tiempo que su umbral. El hallazgo da la hora de la última escritura y el umbral.
Weave informa de una tabla con umbral como sin comprobar, con el motivo, en lugar de como no escrita, cuando:
- un flujo de trabajo que la escribe se está ejecutando, está en cola o acaba de terminar y sus resultados todavía no se han registrado;
- un flujo de trabajo que la escribe inició una ejecución después de que pasara el umbral y la terminó, pero falta el registro del paso que escribe de esa ejecución;
- un paso, en cualquier parte del proyecto, elige con una variable la tabla que escribe y Weave no puede determinar el valor de esta, por lo que podría escribir esta tabla;
- ningún paso del proyecto la escribe, como una tabla que usted carga a mano, por lo que Weave no tiene ninguna escritura desde la cual medir; o
- el historial de ejecuciones no se puede leer.
Un paso omitido no hace que una tabla con umbral quede sin comprobar: la tabla sigue sin escribirse desde hace más que su umbral. Una vista no puede tener umbral, y convertir una tabla en vista elimina su umbral. Una copia de una tabla, o una tabla creada a partir de una de sus instantáneas, empieza sin umbral.
Para fijar un umbral, seleccione la tabla en la lista Tablas del proyecto y
elija Ver/Editar detalles de la tabla. En Actualización, seleccione Warn if this table
isn’t written for more than, escriba el número de horas y haga clic en Update.
Desactive la casilla para quitar el umbral. Mientras no haya ningún umbral fijado,
el cuadro nombra los flujos de trabajo programados según cuyas programaciones se
juzga la tabla, o indica que ningún flujo de trabajo que usted pueda abrir la
escribe según una programación. Actualización no aparece para una vista ni para una tabla
que está creando, ni sin el rol analyze.workflow.read, y cambiarla
requiere analyze.table.write.
También puede pedir a un asistente de IA conectado a través de PlaidCloud MCP que
fije el umbral de actualización de la tabla (su herramienta es table_upsert, con
freshness_max_age_hours), o llamar a la API de la plataforma:
PUT /rest/v1/analyze/weave/freshness{"project_id": "<project>", "table_id": "<table>", "freshness_max_age_hours": 24}Envíe null en lugar del número para quitarlo, y la tabla vuelve a juzgarse según
las programaciones de los flujos de trabajo que la escriben. GET /rest/v1/analyze/weave/freshness?project_id=<project>&table_id=<table> devuelve
el umbral y scheduled_writers, los flujos de trabajo programados según cuyas
programaciones se juzga la tabla cuando no tiene umbral. Leer un umbral requiere
los roles analyze.table.read y analyze.workflow.read, y fijar uno requiere
analyze.table.write y analyze.workflow.read. Solo puede fijar un umbral en una
tabla que su rol le permita ver, y no mientras el proyecto esté bloqueado.
Tablas que un flujo de trabajo lee, escritas desde entonces. Para un flujo de trabajo que lee una tabla que escribe otro flujo de trabajo, Weave comprueba que ningún otro flujo de trabajo haya escrito en la tabla desde la última vez que el flujo de trabajo la leyó. Una tabla cuenta como leída o escrita por un paso que la nombra como entrada o como salida y que terminó en una ejecución. Weave lee lo que registra el historial de ejecuciones, no los datos de la tabla.
- Lee una tabla escrita desde su última lectura. Un flujo de trabajo leyó una tabla por última vez en una de sus ejecuciones, y un flujo de trabajo distinto ha escrito en esa tabla desde entonces, por lo que sus resultados pueden estar desactualizados. El hallazgo nombra la ejecución que leyó la tabla por última vez y los flujos de trabajo que escribieron en ella. De un flujo de trabajo con un evento programado habilitado, o que ejecuta otro flujo de trabajo que lo tiene, solo se informa cuando una programación que lo ejecuta ha vencido después de la escritura; de un flujo de trabajo que nada ejecuta según una programación se informa de inmediato.
Estos casos no se cuentan como escritos desde entonces:
- una escritura del propio flujo de trabajo, incluida la que haga durante su ejecución un flujo de trabajo que ejecuta mediante un paso Flujo de trabajo: ejecutar, Flujo de trabajo: bucle o Flujo de trabajo: ejecución condicional;
- una tabla que el flujo de trabajo escribe en una ejecución antes de que ningún paso de esa ejecución la lea, como una tabla de preparación, a menos que la escritura fuera de un paso Tabla: anexar o Tabla: upsert, o de un paso Tabla: eliminación in situ con un filtro, que conservan las demás filas de la tabla; y
- una escritura hecha antes de que se guardara por última vez el paso que la hizo, ya que entonces el paso pudo haber escrito en una tabla distinta.
Weave informa del flujo de trabajo como sin comprobar, con el motivo, en lugar de como desactualizado, cuando:
- se está ejecutando, o acaba de terminar y sus resultados todavía no se han registrado;
- un paso que lee la tabla se omitió en una ejecución posterior a la escritura;
- la programación que lo ejecuta no es válida;
- ninguna de sus ejecuciones recientes terminó de leer la tabla, mientras que otro flujo de trabajo escribió en ella o pudo haberlo hecho;
- un paso que lee la tabla se ha guardado desde que empezó su última ejecución correcta, por lo que Weave no puede saber si esa ejecución la leyó. Cualquier guardado cuenta, incluso uno que no cambie nada de lo que lee el paso;
- uno de sus pasos lee tablas que Weave no puede determinar a partir de la configuración del paso, como un paso IA: paso LLM, un paso Report, un paso Ejecutar: Python remoto, o un paso que lee varias tablas y encuentra una de ellas mediante una búsqueda, como puede hacer un paso Tabla: unión distinta o Tabla: unión de todo; elige una tabla con una variable; nombra una tabla con un nombre que tiene más de una tabla; lee una vista; o lee una tabla de otro proyecto;
- una tabla que lee también la escribe una macro, cuyas ejecuciones Weave no ve, o un paso de otro flujo de trabajo que se ha ejecutado desde entonces y elige con una variable la tabla que escribe, la nombra con un nombre que tiene más de una tabla, o escribe tablas que Weave no puede determinar; o
- su historial de ejecuciones no se puede leer.
Un flujo de trabajo sin ejecuciones en los últimos 30 días no se comprueba de esta manera.
Lo que esta comprobación no ve:
- las lecturas y escrituras anteriores al historial de ejecuciones que lee Weave, que son los últimos 30 días y, para cada flujo de trabajo, sus últimas 20 ejecuciones;
- la condición de un paso que comprueba una tabla, que no cuenta como leerla;
- una escritura de otro flujo de trabajo en una tabla a la que el flujo de trabajo agrega filas y luego lee en la misma ejecución, a menos que las agregue con un paso Tabla: anexar o Tabla: upsert;
- una lectura anterior de un paso cuando otro paso del flujo de trabajo leyó la misma tabla más recientemente;
- una escritura dentro de una macro por un paso que elige su tabla con una variable o escribe tablas que Weave no puede determinar; y
- las escrituras hechas antes de que se guardara por última vez el paso que escribe, aunque el guardado no cambiara nada de lo que escribe, hasta que su flujo de trabajo se ejecute de nuevo.
Sin el rol analyze.table.read no se comprueba ningún flujo de trabajo de esta
manera. Cuando un flujo de trabajo o una tabla que escribió o fue leída es uno al
que usted no tiene acceso, el hallazgo dice “un flujo de trabajo al que no tiene
acceso” o “una tabla a la que no tiene acceso”, sin indicar cuántos.
Un paso de un tipo para el que Weave no tiene ninguna regla se informa como no cubierto, no como correcto.
Tablas que dependen de una ejecución fallida. Cuando la última ejecución de un flujo de trabajo falló antes de que terminara un paso que escribe una tabla, esa tabla sigue conteniendo sus datos anteriores, o solo parte de los nuevos. Weave sigue la tabla a través de los pasos que la leen y de las tablas que estos escriben, en todos los flujos de trabajo del proyecto, e informa de lo que depende de ella:
- Lee una tabla que una ejecución fallida no terminó. Un flujo de trabajo lee la tabla, o una tabla construida a partir de ella, por muchos pasos que haya de por medio. El hallazgo nombra la tabla que lee, la tabla que la ejecución fallida no terminó y el flujo de trabajo que falló, con la hora en que empezó esa ejecución.
- Muestra una tabla que una ejecución fallida no terminó. Un panel de control tiene un gráfico sobre una tabla publicada que es esa tabla o que se construye a partir de ella, o sobre un conjunto de datos SQL que lee una tabla así. Weave lee la lógica de plantilla de un conjunto de datos SQL sin las etiquetas, por lo que puede contar una tabla que está en una rama que nunca se toma. El hallazgo trata del panel de control y aparece en la pestaña Weave de cada proyecto cuyas tablas muestran sus gráficos.
Weave detectó el panel de control “Board Pack”: muestra la tabla “Margin”, construida a partir de la tabla “Sales”, que el flujo de trabajo “Import Sales” no terminó de escribir en su última ejecución, el 27 oct 09:15 UTC, por lo que sus gráficos pueden mostrar datos antiguos o incompletos
Cada flujo de trabajo fallido es un hallazgo propio, y desaparece cuando la última ejecución de ese flujo de trabajo deja de fallar. Al flujo de trabajo que falló no se le informa aquí de su propia ejecución; de eso se encarga su hallazgo Error en la última ejecución.
Estos casos no se cuentan como una tabla que la ejecución fallida no terminó:
- una tabla cuyo paso se omitió a propósito, como un paso cuya condición no se cumplió, un paso deshabilitado o una importación que omitió un archivo que ya había cargado;
- una tabla cuyo paso puede saltarse una ejecución. En un flujo de trabajo que no es avanzado, el salto de una condición, o el salto de un paso que falla en un flujo de trabajo en serie, abarca todos los pasos. En un flujo de trabajo avanzado, abarca un paso dentro de un contenedor de ejecución que comprueba condiciones o después de él, y un paso en un bucle;
- una tabla que otro flujo de trabajo reemplazó por completo después de que empezara la ejecución fallida, en lugar de agregarle filas; y
- en el caso de un flujo de trabajo, una tabla que él mismo reemplazó antes de leerla, en su última ejecución que la leyó.
Un flujo de trabajo que se está ejecutando no se juzga hasta que termina su ejecución. Cuando el historial de ejecuciones no se puede leer, Weave informa de estos casos como sin comprobar en lugar de correctos.
Lo que esta comprobación no ve:
- una ejecución que terminó sin que ningún paso registrara un fallo, como una cuyo servidor se detuvo, y una ejecución que alguien detuvo;
- una tabla que un paso elige con una variable, nombra con un nombre que tiene más de una tabla, lee a través de una vista o lee de otro proyecto;
- un gráfico de panel de control sobre una consulta guardada, o sobre un conjunto de datos SQL cuyo SQL Weave no puede leer una vez quitada su lógica de plantilla;
- una tabla cuyo nombre construye una plantilla;
- una tabla que un conjunto de datos SQL nombra sin esquema, a menos que el esquema propio del conjunto de datos sea el esquema de informes del proyecto;
- cualquier conjunto de datos SQL de un proyecto en un almacén de datos de Snowflake o Databricks;
- una tabla que no está publicada, y las aplicaciones de Panel; y
- las ejecuciones anteriores al historial de ejecuciones que lee Weave, que son los últimos 30 días y, para cada flujo de trabajo, sus últimas 20 ejecuciones.
Solo ve el hallazgo de un panel de control si puede abrirlo. Sin el rol
analyze.table.read, ninguna de las dos comprobaciones se ejecuta.
Totales de métricas inusuales. Cada día Weave lee las métricas de su proyecto e informa de aquella cuyo último período terminado resultó muy distinto de lo habitual, nombrando el elemento, como un cliente o una planta, que está detrás del cambio. Consulte Totales de métricas inusuales.
Revisión de un flujo de trabajo
Sección titulada «Revisión de un flujo de trabajo»Una revisión comprueba un flujo de trabajo antes de que usted confíe en él. Ejecuta las comprobaciones de Weave sobre el flujo de trabajo y sus pasos, incluidos los pasos de cualquier flujo de trabajo que este ejecute, y tres más que Weave ejecuta solo en una revisión, porque leen más de lo que la pestaña Weave puede permitirse leer cada vez que se abre:
- Una asignación que alimenta sus propias entradas. Para cada paso de asignación que ejecuta el flujo de trabajo, si lo que escribe vuelve a fluir, a través de cualesquiera pasos y de cualquier flujo de trabajo, hacia la tabla que asigna o hacia su tabla de inductores. Cuando es así, cuánto asigna el paso, o cómo lo reparte, depende de lo que asignó en una ejecución anterior. Weave nombra los pasos por los que pasa el bucle y le pide que compruebe si el bucle es intencionado. No se informa de un bucle que no pasa por ningún paso de asignación, como una carga incremental que lee la tabla a la que anexa.
- Tablas y columnas de inductores de asignación. Si la tabla de inductores que usa un paso de asignación existe y tiene todas las columnas que el paso lee de ella. No se busca una columna de inductor que el paso rellena con una constante o una expresión. Una tabla de inductores construida en cualquier otro lugar se comprueba tal como está ahora; cuando un paso de este flujo de trabajo la construye, sus columnas no se conocen hasta que ese paso se ejecuta, por lo que Weave informa de la asignación como sin comprobar en lugar de aprobada. También la informa como sin comprobar cuando el paso elige su tabla de inductores con una variable o una ruta de carpeta, cuando el flujo de trabajo es una macro y cuando su rol no puede ver la tabla.
- Seguridad a nivel de fila en una columna renombrada. Para cada tabla que escribe el flujo de trabajo, si tiene una columna etiquetada con la dimensión que usa un atributo de seguridad a nivel de fila pero que no se llama como ese atributo. La seguridad a nivel de fila filtra solo por columnas que se llaman como sus atributos, por lo que no filtra por esa columna. Esta comprobación necesita el rol de Arquitecto en el proyecto; para cualquier otra persona, la revisión indica que no se comprobó, y lo mismo ocurre con una tabla que el flujo de trabajo nombra con una variable o una ruta de carpeta.
Una revisión comienza diciendo lo que encontró y sobre cuánto del flujo de trabajo, y nunca termina con un visto bueno:
Weave found 2 problems in the workflow "Q3 Close". It couldn't finish checking 1of its 8 steps (listed below), so it may have missed problems in those. See belowfor what these checks don't cover.
Weave noticed the step "Allocate rent": it uses the column "sq_ft" from its drivertable "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 drivertable "IT driver" through "Build IT driver", so how it spreads what it allocatesdepends on what it allocated on an earlier run. Check whether that loop isintended.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 thattable, so its columns aren't known until that step runs.Los pasos que su rol no puede ver cuentan para el total, y la revisión indica que no los comprobó.
Una revisión enumera lo que no comprueba. No ejecuta las comprobaciones de Weave sobre tablas (si una tabla escrita según una programación llega tarde y si se ha escrito en una tabla que el flujo de trabajo lee desde entonces), que leen todo el proyecto y se ejecutan en la pestaña Weave. Para un flujo de trabajo con pasos de asignación, no comprueba si cada importe que se asigna encuentra una fila de inductor o un miembro de dimensión que coincida, si las tablas de origen y de inductores contienen cifras con el mismo nivel de detalle, ni los bucles que pasan por un paso que nombra su tabla dentro de SQL o con una variable.
Para revisar un flujo de trabajo, ábralo en su lienzo o en su cuadrícula de Pasos y elija Comprobar. El botón está disponible para quienes pueden editar el flujo de trabajo y leer las tablas del proyecto. La ventana Verificación de Weave muestra, por orden:
- las líneas iniciales de la revisión;
- Resumen (redactado por IA), cuando la revisión tiene un resumen;
- los Problemas de la revisión y, a continuación, lo que No se pudo verificar. Un problema al que apunta el resumen se marca como En el resumen, y Ir a, junto al hallazgo de un paso, selecciona ese paso donde eligió Comprobar;
- Lo que esta verificación no cubre, siempre en último lugar.
Si elige Comprobar de nuevo, se ejecuta una revisión nueva en la misma ventana.
También puede pedir a un asistente de IA conectado a través de PlaidCloud MCP
que revise un flujo de trabajo (su herramienta es workflow_review) o llamar a la
API de la plataforma. Una revisión necesita acceso de lectura a los pasos, flujos
de trabajo y tablas del proyecto. Las tres comprobaciones anteriores no aparecen
en la pestaña Weave; Weave las ejecuta solo en una revisión.
En la ventana Verificación de Weave y a través de la API de la plataforma, una revisión que encuentra problemas lleva además un resumen de una o dos frases redactado por la IA integrada de PlaidCloud, y hasta tres de sus problemas para mirar primero. A la IA solo se le muestran los problemas de la revisión. Antes de devolver el resumen, los problemas a los que apunta deben ser los de la propia revisión, cualquier nombre que cite y cualquier dígito que escriba deben aparecer en esos problemas, y no puede usar una expresión como “ningún otro problema”. Un resumen que no lo cumple se descarta, y la revisión se devuelve sin él. Una revisión sin problemas no tiene resumen. A través de un asistente de IA, la revisión no tiene resumen; el asistente lee los hallazgos por sí mismo.
Aviso al terminar una ejecución
Sección titulada «Aviso al terminar una ejecución»Cuando termina la ejecución de un flujo de trabajo, Weave examina ese flujo de trabajo y avisa al responsable de cada problema (consulte Asignar un responsable a un hallazgo) de los problemas que tiene ese flujo de trabajo, tanto de sus ejecuciones como de la configuración guardada de sus pasos, que todavía no ha leído en la pestaña Weave del proyecto, mediante un mensaje en la aplicación. Un problema sin responsable, o cuyo responsable ya no puede verlo, va a la persona a la que pertenece la ejecución: quien la inició o, en una ejecución programada, quien guardó la programación por última vez. Cada problema se menciona una sola vez. Mientras no lo haya leído en la pestaña Weave, las ejecuciones posteriores no vuelven a mencionarlo, de modo que un Workflow Loop que ejecuta muchos flujos de trabajo no llena su pantalla de repeticiones. El recuento del botón Weave lo conserva hasta que lo lea.
El mensaje permanece en pantalla durante 30 segundos y tiene un vínculo Abrir Weave, que abre la pestaña Weave del proyecto en los hallazgos sobre el flujo de trabajo que se ejecutó. Haga clic en cualquier otra parte del mensaje para cerrarlo.
Mientras hay en pantalla un mensaje de Weave sobre un proyecto, uno nuevo sobre el mismo proyecto se une a él en lugar de aparecer debajo. El mensaje muestra la frase más reciente, seguida de una línea como Y 2 más en este proyecto., y permanece en pantalla durante 30 segundos desde la más reciente. Cuando los mensajes tratan de flujos de trabajo distintos, Abrir Weave abre toda la pestaña Weave. Así, los flujos de trabajo que fallan con pocos instantes de diferencia le dan un solo mensaje en lugar de uno por cada uno. Un recordatorio de preparación siempre aparece por sí solo.
Después de leer un problema, solo se vuelve a mencionar cuando cambia lo que dice. Un hallazgo de ejecución describe la ejecución de la que procede (su fecha, su hora, sus recuentos), por lo que un flujo de trabajo que falla todas las noches se vuelve a mencionar en el siguiente fallo después de que usted haya leído el último. Un problema de configuración dice lo mismo de una ejecución a otra, por lo que, una vez leído, no se repite con cada ejecución.
Una ejecución detenida no envía nada, sea quien sea quien la detuvo. Un flujo de trabajo ejecutado por un paso Macro Run o Macro Concurrent no envía nada por sí mismo, y esa llamada no se cuenta entre sus ejecuciones; un flujo de trabajo iniciado por un paso Ejecutar flujo de trabajo o Workflow Loop es una ejecución de ese flujo de trabajo como cualquier otra. Lo que Weave no pudo comprobar nunca se envía de esta manera, ni tampoco los hallazgos sobre tablas escritas según una programación o sobre las tablas de un flujo de trabajo escritas desde que las leyó: Weave avisa de esos entre ejecuciones. Consulte Aviso entre ejecuciones.
Que se le avise no es lo mismo que haber leído: una alerta no marca el hallazgo como leído en la pestaña Weave, y tampoco lo hace seguir su vínculo Abrir Weave.
Cada problema del que le informa un mensaje se suma al recuento del botón Weave del encabezado. Consulte El botón Weave del encabezado.
Aviso entre ejecuciones
Sección titulada «Aviso entre ejecuciones»Algunos problemas aparecen sin que se esté ejecutando nada: una tabla que no se ha escrito según su programación o dentro de su umbral de actualización; una ejecución programada que no se inició, o que venció mientras el flujo de trabajo seguía ejecutándose; un flujo de trabajo cuyas tablas ha escrito otro flujo de trabajo desde la última vez que las leyó; y un flujo de trabajo o panel de control que depende de una tabla que una ejecución fallida no terminó. El final de una ejecución no puede avisarle de ellos, así que una vez por hora Weave comprueba cada proyecto en busca de estos problemas y avisa al responsable de cada uno (consulte Asignar un responsable a un hallazgo) mediante un mensaje en la aplicación.
La comprobación horaria le avisa de cada uno de estos problemas una sola vez, aunque lo encuentren muchas comprobaciones, y su primera comprobación de un proyecto le avisa de los que ya existen, por mucho tiempo que lleven. Solo le avisa de nuevo después de que el problema haya desaparecido y vuelto, o después de que usted lo haya leído y lo que dice haya cambiado, como una ejecución programada posterior que tampoco se inició. Un problema de programación también está entre las comprobaciones propias de un flujo de trabajo, pero una vez que la comprobación horaria le ha avisado de él, el mensaje del final de la siguiente ejecución del flujo de trabajo no lo repite hasta que usted lo haya leído; consulte Aviso al terminar una ejecución. Varios problemas de un mismo proyecto llegan en un solo mensaje, que los cuenta y cita el primero:
Weave detectó 3 problemas en el proyecto “Finance Close”, empezando por la tabla “Sales Daily”: el paso “Load Sales” la escribió por última vez el 14 oct 06:00 UTC, y el flujo de trabajo “Nightly Load” debía ejecutarse según su programación desde entonces
Una tabla que escribe más de un flujo de trabajo no tiene responsable hasta que alguien le asigna uno. Cuando no se ha escrito según la programación, Weave avisa al responsable de cada flujo de trabajo que debía escribirla y no lo hizo. Cualquier otro problema sin responsable no se envía; figura en la pestaña Weave del proyecto.
La comprobación se ejecuta como cada responsable, por lo que un mensaje nombra solo lo que su rol le permite ver. Solo se le avisa como miembro activo del proyecto cuyo rol le permite ver sus pasos y flujos de trabajo, y de las tablas solo si puede leer tablas.
El mensaje permanece en pantalla durante 30 segundos y tiene un vínculo Abrir Weave, que abre la pestaña Weave del proyecto, en el flujo de trabajo cuando todos los problemas del mensaje tratan del mismo. Un mensaje solo se muestra mientras usted tiene la sesión iniciada, pero cada problema del que le informa se suma al recuento del botón Weave del encabezado, por lo que uno que se le haya pasado sigue contándose allí. Que se le avise no marca un hallazgo como leído.
Marcar un hallazgo como leído
Sección titulada «Marcar un hallazgo como leído»Cada hallazgo lleva un id, y puede marcarlo como leído para que deje de aparecer como nuevo: en la pestaña Weave del proyecto, haga clic en Marcar como leído en su tarjeta (consulte Marcar hallazgos como leídos). El id se deriva del propio hallazgo, por lo que un hallazgo que descartó vuelve a aparecer como nuevo si cambia el problema subyacente: un paso que marcó como leído tras corregir una columna reaparece si más adelante falla otra columna distinta.
El estado de lectura es solo suyo. Marcar un hallazgo como leído no lo marca como leído para nadie más del proyecto.
Mientras se ejecuta un flujo de trabajo que escribe una tabla atrasada, Weave informa de la tabla como sin comprobar. Si marca como leído cualquier hallazgo durante ese tiempo y la ejecución termina sin escribir la tabla, su hallazgo vuelve a aparecer como nuevo.
Dos pasos distintos que aparecen dos veces en un mismo flujo de trabajo son dos hallazgos, por lo que marcar uno como leído deja el otro sin leer. Un flujo de trabajo sin nombre aparece como “flujo de trabajo sin nombre”, y una comprobación que no pudo ejecutarse se nombra por su título, como “Error en la última ejecución”.
Un resumen periódico
Sección titulada «Un resumen periódico»Un resumen periódico es el mismo informe reducido a lo que todavía no ha leído, con la misma voz. Puede solicitar uno en cualquier momento, y puede recibirlo como notificación en la aplicación, con un vínculo Abrir Weave a la pestaña Weave del proyecto.
Los hallazgos que Weave no pudo comprobar forman parte de un resumen periódico como cualquier otro. Un resumen periódico que los omitiera sin avisar sería justamente el silencio tranquilizador que la tercera respuesta existe para evitar.