Referencia de comandos

2026-09-11
Peer Grønnerup

Applies to:

❌ ~~Tabular Editor 2~~
❌ ~~Tabular Editor 3~~
✔ Tabular Editor CLI

Important

La CLI de Tabular Editor se encuentra en vista previa pública limitada. Se ofrece para su evaluación con una cuenta de Tabular Editor; no se requiere ninguna licencia durante la vista previa. Los comandos, las opciones y las salidas pueden cambiar antes de la disponibilidad general. La compilación de vista previa dejará de funcionar a partir del 2026-10-31. No recomendamos usar la CLI en pipelines de CI/CD de producción durante la vista previa.

Esta página ofrece una breve descripción y un ejemplo por comando. Todos los comandos aceptan --help para consultar la documentación completa de las opciones:

te deploy --help            # Help for a single command
te bpa run --help           # Help for a command with subcommands

Note

Durante la versión preliminar, la salida de --help de la CLI es la referencia definitiva de parámetros y opciones. El contenido de esta página se ha seleccionado manualmente y puede quedarse atrás respecto a --help cuando se añadan novedades entre versiones preliminares.

Rutas de objeto

El direccionamiento de objetos en la CLI usa una única gramática compartida por todos los comandos. En la referencia siguiente aparecen dos tipos de ruta:

<path>: identifica exactamente un objeto o contenedor. Lo usan los comandos que cambian el modelo o necesitan un único destino: te set, te add, te remove, te move, te deps, te macro run --on y te get con -p, --deps o --properties.
<path-filter>: identifica cero o más objetos y admite comodines. Lo usan los comandos que operan sobre un conjunto: te list, te get sin opciones (con un comodín o una ruta de contenedor se listan todas las coincidencias), te bpa run --path y otros comandos de inspección.

Ambas formas de ruta comparten las mismas reglas de sintaxis; solo se diferencian en dos puntos:

Las rutas de filtro permiten comodines *; las rutas de objeto no.
Las rutas de objeto permiten el sufijo entre corchetes de DAX (por ejemplo, Sales[Amount]); las rutas de filtro no.

Segmentos y separadores

Una ruta es una secuencia de segmentos separados por barras. Cada segmento nombra un único paso: una tabla, un objeto hijo o una palabra clave de contenedor.

Sales — un segmento
Sales/Revenue — dos segmentos
Roles/Admin/Members/bob — cuatro segmentos

La entrada vacía y . significan «la raíz del modelo»: el punto de partida implícito para las rutas de filtro y el sujeto explícito de las consultas del tipo te get ..

Uso de comillas

La mayoría de los nombres de segmentos funcionan tal cual. Pon un segmento entre comillas cuando su nombre contenga espacios, barras, corchetes o cualquier carácter que, de otro modo, se interpretaría como sintaxis. La CLI sigue las convenciones de comillas de DAX, por lo que el uso de comillas en las rutas de te coincide con lo que escribirías dentro de una expresión DAX:

Forma	Uso	Regla de escape
`'Net Sales'`	Tablas y objetos con nombre con espacios.	Duplica la comilla simple (`'Bob''s'` → `Bob's`).
`"Net Sales"`	Igual que arriba; resulta práctico entre distintos shells cuando es incómodo escapar comillas simples.	Duplica la comilla doble (`"He said ""hi"""` → `He said "hi"`).
`[Sales Amount]`	Un sufijo entre corchetes al estilo DAX en una tabla (`'Sales'[Sales Amount]`) o una referencia global al modelo solo entre corchetes (`[Total Sales]`). Solo en rutas de objeto.	Duplica el corchete de cierre (`[foo]]bar]` → `foo]bar`).

Dentro de los segmentos entre comillas, * se trata como un carácter literal, no como un comodín. Por tanto, 'Sa*' coincide con una tabla cuyo nombre es exactamente Sa*.

Los caracteres reservados en las rutas son / [ ] ' " * ? { }. Un segmento que contenga cualquiera de los caracteres * ? { } debe ir entre comillas (te get "Tables/'{foo}'", te get 'Sales/"my*name"'); el uso sin comillas se rechaza con un error que indica el carácter y muestra la forma entrecomillada. ? está reservado y no tiene significado de comodín. Toda ruta que imprime la CLI —en errores, sugerencias, la salida de --paths-only y el campo objectPath en JSON— está entrecomillada de forma canónica y se puede volver a pegar directamente en te get. Las formas con comillas mixtas requieren PowerShell o bash; cmd.exe no puede expresarlas.

Referencias al estilo DAX (solo rutas de objeto)

Se aceptan dos formas con sintaxis DAX en cualquier lugar donde se admita un <path>:

'Table'[Member] — equivalente a Table/Member. El sufijo entre corchetes hace que las coincidencias ambiguas se resuelvan a favor de columnas y medidas frente a jerarquías/particiones.
[Member] — una medida o columna independiente, sin tabla delante. Busca en todo el modelo una medida o columna con ese nombre. Las medidas tienen prioridad cuando existen tanto la medida como la columna.

te get "'Sales'[Amount]"             # Same as te get Sales/Amount
te get "'Net Sales'[Sales Amount]"   # Spaced names via DAX form
te get "[Total Sales]"               # Model-wide measure-or-column lookup

Contenedores y palabras clave

Varios nombres funcionan como palabras clave de contenedor. Una palabra clave puede usarse sola (para enumerar todo el contenedor) o aparecer dentro de una ruta (para entrar en esa subcolección del elemento padre actual).

Palabra clave	Ámbito	Significado
`Tables`, `Medidas`, `Columns`, `Hierarchies`, `Particiones`, `KPIs`, `Sets`	Modelo	Todos los objetos de ese tipo en todo el modelo.
`Relaciones`, `Roles`, `Perspectives`, `Cultures`, `DataSources`, `Expressions`, `CalculationGroups`, `Functions`, `Annotations`	Modelo	Contenedores a nivel de modelo.
`Medidas`, `Columns`, `Hierarchies`, `Particiones`, `Calendars`, `CalculationItems`, `KPIs`, `Sets`	Tabla	Subcontenedores dentro de una tabla.
`Levels`	Jerarquía	Niveles de una jerarquía.
`Members`, `TablePermissions` (alias `Permissions`)	Rol	Elementos hijos de un rol.

Los conjuntos calculados solo se pueden referenciar en forma de contenedor (<table>/Sets/<name>); un KPI individual es <table>/<measure>/KPI; los calendarios se resuelven en <table>/Calendars/<name>; las relaciones se resuelven en Relationships/<name> (el propio nombre de la relación en el modelo: un GUID o una etiqueta como Relationship 1; --paths-only lo imprime, y también se acepta el nombre para mostrar).

Algunos ejemplos muestran en qué se diferencian las rutas simples y las rutas con ámbito de contenedor:

te get Sales/Revenue                       # Measure or column on Sales
te get Sales/Measures/Revenue              # Same, container-scoped - disambiguates if other kinds share the name
te get Sales/Geography/Levels/Year         # Specific level of a hierarchy
te get Roles/Admin/Members/bob@example.com # Role member
te get Sales/refreshPolicy                 # Refresh-policy sub-object on a table
te get Sales/Revenue/KPI                   # KPI sub-object of a measure

Pon un segmento entre comillas para forzar la coincidencia literal del nombre cuando el nombre real de un objeto coincide con una palabra clave. La tabla cuyo nombre literal es Tables es 'Tables' y se accede con te get "'Tables'". Lo mismo se aplica a las tablas llamadas KPIs o Sets.

Comodines en rutas de filtro

Las rutas de filtro añaden un único carácter comodín - * - que coincide con cualquier secuencia de caracteres dentro de un solo segmento (codicioso, de un solo segmento). Los comodines son la forma en que te list y comandos similares acotan sus resultados.

te list 'Sa*'                          # Tables whose name starts with Sa
te list 'Sales/*Amount'                # Children of Sales whose name ends with Amount
te list '*/Amount'                     # An Amount column/measure across every table
te list 'Roles/Re*/Members'            # Members of every role matching Re*

Una ruta de filtro con N segmentos produce resultados con N niveles de profundidad; los comodines nunca amplían automáticamente un nivel más allá de lo que hayas escrito. El atajo de un solo segmento te list Sales es la excepción: un nombre de tabla sin calificar y sin comodines se expande a los elementos secundarios directos de la tabla para ajustarse a la intención de «muéstrame qué hay en Sales». En cambio, te list Sa* devuelve solo las tablas coincidentes, sin expansión.

El sufijo entre corchetes de DAX se rechaza en las rutas de filtro; pon entre comillas los nombres que contengan [ y ] si necesitas que coincidan literalmente.

Errores y sugerencias

Los segmentos mal escritos generan un error contextual con una sugerencia de "quizás quisiste decir" cuando la CLI puede deducir lo que querías decir. La lista ofrece tablas, medidas, columnas y jerarquías, cada una como una ruta completa Table/Object que se puede pegar tal cual en el siguiente comando. Un nombre escrito entre comillas simples es una referencia a una tabla (te deps 'Revenue' busca una tabla llamada Revenue), y el error indica las formas Table/Object y "[Object]" para cualquier elemento que no sea una tabla. Las rutas a las que les falta el elemento padre fallan antes de la comprobación del elemento hoja, así que los mensajes señalan el segmento que realmente está mal. Todas las rutas que imprime un error o una sugerencia se toman de tu modelo y se entrecomillan para que se resuelvan tal como se muestran; si algo se rechaza, nunca se sugiere una ruta que no exista. Los contenedores vacíos (por ejemplo, te list Hierarchies en un modelo sin jerarquías) muestran un simple mensaje de «no hay nada aquí» en lugar de un error.

Alias de comandos

La mayoría de los verbos en su forma larga también aceptan un alias corto. Cada fila muestra el comando canónico y el comando equivalente en forma abreviada que acepta como alias.

Canónico	Forma(s) con alias
`te save-as`	`te save`
`te list`	`te ls`
`te remove`	`te rm`
`te move`	`te mv`, `te rename`
`te bpa rules list`	`te bpa rules ls`
`te bpa rules remove`	`te bpa rules rm`
`te config list`	`te config ls`
`te macro list`	`te macro ls`
`te macro remove`	`te macro rm`
`te profile list`	`te profile ls`
`te profile remove`	`te profile rm`
`te session list`	`te session ls`
`te test list`	`te test ls`

Opciones globales

Estas opciones están disponibles en todos los comandos y se pueden usar antes o después del nombre del subcomando.

Opción	Descripción
`-m, --model <path>`	Ruta al modelo semántico (carpeta TMDL, archivo `.bim`, carpeta `Database.json` o carpeta `.SemanticModel`).
`-s, --server <endpoint>`	Punto de conexión de Analysis Services o un Workspace de Power BI. Un nombre de servidor/FQDN (`MY.SERVER.COM`), una dirección IP (`192.168.1.1`), `host:port`, `localhost`, `SERVER\INSTANCE`, `asazure://...` o una cadena de conexión MSOLAP permite conectarse directamente a Analysis Services / AAS. Un nombre simple de un solo token (`MyWorkspace`), una ruta de Fabric `Name.Workspace[/Model.SemanticModel]` o una URL `powerbi://...` apunta a un Workspace de Power BI. Un nombre de Workspace que contiene un punto no se puede distinguir de un nombre de servidor, así que se trata como un servidor y la CLI muestra una advertencia; use su forma `.Workspace` o la URL completa `powerbi://` para dirigirse a Power BI.
`-d, --database <name>`	Nombre del modelo semántico en el Workspace.
`--local`	Conéctese a una instancia de Analysis Services que se esté ejecutando localmente: Power BI Desktop, Workspaces de Visual Studio o SSAS independiente (solo en Windows).
`--auth <method>`	Método de autenticación: `auto`, `interactive`, `spn`, `env`, `managed-identity` (predeterminado: `auto`).
`--output-format <format>`	Formato de Stdout: `text` (predeterminado), `json`, `csv`, `tmsl` (alias `bim`), `tmdl`. `csv` se respeta en los comandos que emiten datos tabulares; `tmsl`/`tmdl` solo los respetan `te get` y `te list` para la serialización de objetos completos. Los comandos rechazan los formatos que no admiten.
`--error-format <format>`	Formato de stderr para errores, advertencias y sugerencias: `text` (predeterminado) o `json`. Para cualquier otro valor, se usa `text`. Es independiente de `--output-format`, así que puedes combinar stdout en JSON con errores en texto sin formato (o viceversa).
`--recent [N]`	Usa un modelo que hayas usado recientemente. Sin valor = selector interactivo; `N` = el N-ésimo más reciente (1 = el último usado).
`--non-interactive`	Desactiva todas las indicaciones interactivas. Finaliza con un error accionable si falta algún dato obligatorio.
`--debug`	Habilita el registro de depuración en stderr (cadenas de conexión, flujo de autenticación, tiempos).

te --version muestra la versión de la CLI y finaliza.

En los comandos que leen un modelo, el orden de resolución es:

--recent → --local → --server/--database (remoto) → --model → conexión activa establecida con te connect.

El modelo nunca es un argumento posicional: una ruta suelta en la línea de comandos se rechaza con el error "unrecognized command or argument". (Los argumentos posicionales en te connect, te init, te diff y te query son los propios objetivos de esos comandos, no el modelo)

Note

Las opciones mal escritas se rechazan de entrada. Si pasas un --flag que no se reconoce en el comando que invocaste, la CLI finaliza con un error útil en lugar de absorber silenciosamente el token como argumento posicional. Esto detecta errores tipográficos, como que --force termine convirtiéndose por accidente en --forec en scripts de CI.

Note

Nombres de servidor con puntos. -s/--server trata un nombre con puntos (por ejemplo, Sales.2026) como el nombre de host de un servidor de Analysis Services, no como un Workspace de Power BI. La CLI muestra una advertencia cuando tiene que tomar esta decisión, con una sugerencia para anexar .Workspace (por ejemplo, Sales.2026.Workspace) o usar una URL powerbi:// completa si lo que querías era el Workspace de Power BI. Se aplica a te connect, te deploy, te refresh, te query, te vertipaq y te test run.

Inicialización y guardado del modelo

save-as

Vuelva a serializar un modelo en un formato o una ubicación diferentes. Úsalo para escribir en archivos locales un modelo de un Workspace remoto, convertir formatos o guardar de nuevo las ediciones en el origen. (Alias: save.)

te save-as acepta:

-o, --output-path <path> - archivo o carpeta de destino. Opcional: si se omite, te save-as vuelve a escribir en la ubicación de origen, conservando el formato original.
--serialization <fmt> - tmdl, bim (alias tmsl), database.json, pbip. Si se omite, se usa el formato del modelo cargado; con -o, se infiere a partir de la ruta de salida (.bim escribe un BIM de un solo archivo; .json, una carpeta Database.json).
--force - omite la validación y sobrescribe la salida existente. Algunos rechazos (contenedores ambiguos, raíces de proyecto con varios SemanticModel) siguen ocurriendo incluso con --force.
--skip-bpa - omite por completo el control de BPA.
--fix-bpa - corrige automáticamente las infracciones de BPA cuando las reglas definan una expresión de corrección.
--bpa-rules <path> - repetible; reemplaza bpa.rules de la configuración de la CLI solo en este guardado. Las reglas integradas siguen aplicándose salvo que bpa.builtInRules sea false.
--skip-validation - omite el análisis semántico y la validación de DAX para descargas rápidas en modo passthrough.
--supporting-files - genera archivos auxiliares de Fabric (.platform, definition.pbism).

te save-as                                    # Save back to source (no -o needed)
te save-as -m ./model.bim -o ./tmdl-out       # Convert BIM to TMDL
te save-as -o ./project --serialization pbip         # Save as a PBIP project
te save-as -o ./out -s my-workspace -d my-model --skip-validation   # Fast download

La salida de --serialization pbip se abre directamente en Power BI Desktop y toma el nombre del modelo de origen (SpaceParts.pbip, no Model.pbip). Guardar en una carpeta que ya contiene un proyecto solo agrega los archivos que faltan y deja todo lo que ya estaba allí —las páginas del Report, el tema, la conexión y la identidad del elemento— exactamente como estaba, de modo que un guardado que no cambia nada deja el proyecto sin cambios en el control de versiones.

La validación protege el guardado: no se escribe un modelo con una colisión de nombres que Analysis Services rechazaría (TE0012 / TE0013, consulta validate), salvo que se use --force o --skip-validation.

Tip

Use te save-as -o <path> -s <Workspace> -d <model> para descargar un modelo remoto al disco. Combínalo con --skip-validation para obtener el passthrough más rápido cuando solo necesites los bytes (sin análisis semántico de DAX).

init

Crea un nuevo modelo semántico vacío en la ruta especificada. De forma predeterminada, se crea un modelo TMDL en modo de compatibilidad PowerBI con el nivel de compatibilidad 1705.

te init acepta:

<output-path> - argumento posicional: directorio en el que se creará el modelo (si se omite, se usa la ruta global --model).
--compatibility-mode <mode> - PowerBI (predeterminado) o AnalysisServices.
--compatibility-level <N> (alias --compat) - nivel de compatibilidad. El valor predeterminado es 1705 cuando el modo es PowerBI; en caso contrario, 1500. Consulta Actualizar el nivel de compatibilidad.
--name <name> - nombre del modelo o la base de datos (predeterminado: el nombre del directorio).
--serialization <fmt> - tmdl (predeterminado), bim (alias tmsl), database.json, pbip.
--force - reemplaza cualquier archivo o directorio existente en la ruta de destino.

te init ./new-model                                       # TMDL, PowerBI mode, compat 1705
te init ./new-model --serialization bim                   # Single-file BIM model
te init ./as-model --compatibility-mode AnalysisServices  # AS model, compat 1500
te init ./existing-dir --force                            # Overwrite non-empty directory

te init es idempotente: al volver a ejecutarlo sobre un modelo que ya creó, muestra Already exists y sale con 0 (con --output-format json: {"created": false, "reason": "already_exists", ...}). Los conflictos reales siguen devolviendo 1; --force vuelve a crear todo desde cero.

Edición del modelo

Los comandos que modifican (set, add, remove, move y también script, macro run, bpa run --fix) son simulaciones de forma predeterminada: sin --save, el comando informa de lo que cambiaría y descarta los cambios (Dry run - nothing saved. Agregue --save para guardar.). Agrega --save para guardar en el origen, o --save-to <path> para escribir en otra ubicación. En set, add, remove, move, script y bpa run, la salida de cambios se muestra como un diff unificado por cada objeto modificado; puedes cambiarla con --stat o --name-only (mutuamente excluyentes con --diff, la opción predeterminada), o definir un valor predeterminado permanente con te config set mutationOutput diff|stat|name-only|none. La salida JSON siempre incluye el array completo de cambios. Se rechaza el guardado si el cambio introduce nuevos errores de validación de DAX, salvo que se use --force.

set

Establece propiedades en un objeto del modelo, da formato a sus expresiones o sincroniza una tabla con su esquema de origen. Acepta un argumento <path>.

te set acepta:

-p, --property <Name=Value>: asignación de propiedades (p. ej., -p expression="SUM(Sales[Amt])", -p isHidden=true). Repetible: todo lo que aparece después del primer = es el valor. Las asignaciones posicionales sin prefijo también funcionan: te set Sales/Amount formatString="#,0" --save. Los nombres de las propiedades no distinguen mayúsculas de minúsculas, aceptan ambas grafías cuando la etiqueta de la cuadrícula y el nombre de TOM difieren (Hidden e IsHidden), y aceptan rutas con puntos e indexadores: -p KPI.StatusGraphic=..., -p "Annotations[Tabular Editor]=...", -p "TranslatedNames[fr-FR]=...". Ejecuta te get <path> --properties para listar todos los nombres que acepta un objeto; consulta get. La expresión de una partición es -p Expression sea cual sea el tipo de partición (MExpression y Query siguen funcionando). Usa -p Name=- para leer el valor desde stdin (una asignación por flujo; un valor canalizado se toma literalmente, así que si canalizas el texto null, se almacena la palabra null). -p Name= asigna una cadena vacía.
--unset <Name>: borra una propiedad; se puede repetir (--unset description --unset displayFolder). -p Name=null es la forma abreviada. Funciona con cualquier propiedad que pueda no tener valor, incluidas las propiedades de texto, y con las propiedades con valor de objeto (SortByColumn, RefreshPolicy); -p "Annotations[key]=null" elimina una anotación. Las propiedades numéricas, booleanas y de elección fija no se pueden borrar; se rechaza el intento.
--format <PropertyName>: da formato a esa propiedad de expresión (se puede repetir; DAX o M se detectan a partir de la propiedad). Las opciones del formateador --long (menos saltos de línea) y --no-space-after-function requieren usar --format con una propiedad DAX. --semicolons se rechaza junto con --format: una expresión almacenada en un modelo siempre está separada por comas, así que el dialecto con punto y coma nunca puede analizarla. En su lugar, da formato al DAX escrito con punto y coma con te util format-dax --semicolons.
--update-schema: sincroniza las columnas de una tabla con su esquema de origen: agrega nuevas columnas de origen con los tipos detectados, actualiza el tipo de las que hayan cambiado y conserva todo lo demás de cada columna existente (nombre, descripción, cadena de formato, carpeta de visualización, columna de ordenación, visibilidad, anotaciones, traducciones, pertenencia a perspectivas). Las columnas de origen eliminadas solo generan una advertencia, a menos que uses --drop-removed-columns (destructivo). Una columna de origen renombrada parece una eliminación + una adición; reasígnala primero con -p SourceColumn=<newName>. Se rechaza en tablas calculadas y grupos de cálculo; no se puede combinar con -p ni con --format. Si no se especifica ninguna opción de conexión, la conexión se lee del propio modelo: el Data source al que están vinculadas las particiones de la tabla, la conexión escrita en la consulta de la tabla o el único Data source utilizable del modelo. La tabla de origen se toma del enlace de la partición y, si no se puede, del nombre de la tabla del modelo como alternativa; --data-source <name> te permite elegir cuando el modelo tiene varios Data sources utilizables. Nombrar una conexión explícitamente con las opciones de detección de esquema compartidas con te add (--source sql|lakehouse|warehouse, --endpoint, --connection-string, --source-database, --source-table) siempre prevalece. Cuando no se puede determinar ningún origen, o no se puede encontrar la tabla de origen, el error indica cuál de los dos casos se aplica y nombra la tabla que buscó.
-t, --type <kind>: desambiguación cuando la misma ruta puede resolverse en varios tipos de objeto (medida, Column, CalculatedColumn, Hierarchy, Calendar, partición, CalculationItem).
--save / --save-to <path> - guarda los cambios.
--diff / --stat / --name-only - formato de salida de los cambios (consulta la nota anterior).
--serialization <fmt> - sobrescribe la serialización al guardar (tmdl, bim (alias tmsl), database.json).
--force - guarda incluso si la modificación introduce errores de validación de DAX.

te set Sales/Amount -p expression="SUM(Sales[Amt])" --save
te set "'Net Sales'[Sales Amount]" -p formatString="#,0" --save        # DAX form with spaced names
te set Sales -p isHidden=true --save
te set Sales/Amount -p formatString="#,0" -p description="Net sales" --save   # Multiple properties, one atomic change
te set "Sales/Total Sales" --unset description --save                   # Clear a property (same as -p description=null)
te set Sales/Amount --format Expression --save                          # Format one expression property
te set Sales --update-schema --save                                     # Sync columns with the source schema (connection inferred from the model)
te set Sales --update-schema --data-source "Sales DW" --save            # Pick the data source when the model has several

Políticas de actualización incremental

Las políticas de actualización son propiedades normales del subobjeto RefreshPolicy de una tabla, así que te get y te set las administran como cualquier otra cosa. Nombres de las propiedades: Mode, RollingWindowPeriods/RollingWindowGranularity, IncrementalPeriods/IncrementalGranularity, IncrementalPeriodsOffset, SourceExpression, PollingExpression (entrada desde archivo: -p SourceExpression=- < src.m).

te get Sales/RefreshPolicy                                              # Inspect a table's refresh policy
te set Sales/RefreshPolicy -p RollingWindowPeriods=5 -p RollingWindowGranularity=Day -p IncrementalPeriods=1 -p IncrementalGranularity=Day --save
te set Sales -p RefreshPolicy=null --save                               # Remove the policy

La política se crea implícitamente en el primer set. Al eliminarla, las particiones generadas por la política se mantienen, y la operación se rechaza cuando son las únicas particiones de la tabla. Para aplicar una directiva en el servidor, consulta te refresh --apply-refresh-policy; para aplicarla solo a nivel de metadatos, usa te script --inline \"Model.Tables[\\"Sales\\"].ApplyRefreshPolicy();\" --save.

add

Agrega un objeto al modelo. Especifica un <path> para el nuevo objeto (el elemento padre ya debe existir; el segmento final es el nuevo nombre) y el tipo mediante -t / --type. Las relaciones mantienen su sintaxis abreviada (Sales[Key]->Dim[Key]). Las rutas con formato de contenedor son destinos válidos para add (Sales/Measures/Margin, Sales/Partitions/Q1, Sales/Calendars/Fiscal, Roles/Admin/TablePermissions/Sales, Roles/Admin/Members/user@x.com); cualquier ruta que muestre la CLI se puede reutilizar en te add.

te add acepta:

-t, --type <type>: tipo de objeto. Valores habituales: Table, CalculatedTable, CalcGroup, Measure, CalculatedColumn, DataColumn, Hierarchy, Level, Calendar, CalcItem, KPI, Partition, Expression, Function, Perspective, Culture, Role, TablePermission, Member. Se admite el autocompletado con la tecla Tab; la lista completa se puede obtener ejecutando te add --help.
-p, --property <Name=Value> - asignación de propiedades al nuevo objeto (repetible). La expresión va en -p Expression="...", o usa --file, o -p Expression=- para leerla desde stdin.
--file <path> - lee la expresión desde un archivo en lugar de incluirla en línea.
--mode <mode> - modo de almacenamiento de las tablas nuevas: import (predeterminado), directquery (alias dq), dual, directlake (alias dl).
--if-not-exists - sale con código 0 sin error si el objeto ya existe. Úsalo en canalizaciones de CI/CD idempotentes.
--save / --save-to <path> - guarda los cambios.
--diff / --stat / --name-only - formato de salida de los cambios (consulta la nota de Edición del modelo).
--serialization <fmt> - sobrescribe la serialización al guardar (tmdl, bim (alias tmsl), database.json, pbip).
--source-type <kind> - tipo de origen de la partición inicial en una tabla nueva: m, query o calculated. Anula la detección heurística. query crea una partición SQL SELECT heredada vinculada al origen de datos del proveedor del modelo, y se rechaza si se usa con orígenes Lakehouse/Warehouse o cuando no existe ningún origen de datos del proveedor; calculated solo es válido con -t CalculatedTable.
--partition-expression <m> - expresión M sin procesar para la partición inicial de la tabla nueva.
--force - guarda incluso si la modificación introduce errores de validación de DAX.

Para añadir una única columna de datos a una tabla existente, usa -t DataColumn, con SourceColumn y DataType obligatorios (se rechaza en tablas calculadas y grupos de cálculo):

te add Sales/Quantity -t DataColumn -p SourceColumn=Qty -p DataType=Int64 --save

Las tablas pueden crearse de una sola vez a partir del propio Data source del modelo; no hacen falta opciones de conexión. La CLI obtiene la conexión del Data source del modelo, detecta las columnas de la tabla de origen y sus tipos, y crea la tabla con una partición ya vinculada a ese Data source. En un Data source heredado (provider), la partición es una consulta SQL heredada que contiene el SELECT generado, igual que la que escribe el asistente de escritorio Importar tablas; pasa --source-type m para usar en su lugar una partición de Power Query (M). En un Data source estructurado (Power Query), la partición siempre es M. Los rechazos son claros y no generan nada: varios Data source utilizables y no se especifica --data-source; ningún Data source que la CLI pueda leer (se admiten orígenes de SQL Server, Azure SQL y Fabric SQL); un origen cuya contraseña el modelo no almacena; o una tabla de origen que la conexión no puede encontrar. El error indica la tabla que buscó y de dónde salió ese nombre.

--source-table <schema.table> - crea la tabla a partir de esta tabla de origen.
--query "SELECT ..." - crea la tabla a partir de una consulta: la consulta se inspecciona en la conexión sin ejecutarse, la tabla nueva obtiene exactamente las columnas que devuelve y la consulta se conserva como contenido de la partición. Funciona tanto con una conexión inferida como con una indicada explícitamente. --source-type query coloca el SQL en una partición heredada de tipo Query, vinculada al Data source heredado del modelo. No se admite junto con --mode directlake (una partición de Direct Lake no contiene ninguna consulta), con --columns ni con una expresión propia (-p Expression= o --file).
--data-source "<name>" - desambigua cuando el modelo tiene varios Data source.

La detección de esquema con un origen explícito también funciona y siempre prevalece sobre la inferencia: --source sql|lakehouse|warehouse, --endpoint, --connection-string, --source-database, --source-table o una especificación manual de columnas --columns "Id:Int64,Name:String". te add "<table>" -t Table sin ningún origen sigue creando una tabla vacía para completarla tú mismo.

te add Sales/Revenue -t Measure -p Expression="SUM(Sales[Amount])" --save
te add Sales/Quantity -t DataColumn -p SourceColumn=Qty -p DataType=Int64 --save
te add "Sales[ProdKey]->Product[ProdKey]" --save                        # Relationship shorthand
te add Sales/MarketingFlag -t CalculatedColumn -p Expression="Sales[Amount] > 1000" --if-not-exists --save
te add Perspectives/Default/Sales --save                                # Include Sales in the Default perspective
te add Roles/Reader -t Role --save                                      # New role at the model level
te add Inventory -t Table --source-table dbo.Inventory --save           # Table from the model's own data source
te add TopCustomers -t Table --query "SELECT TOP 100 * FROM dbo.Customers" --save

eliminar

Elimina un objeto. De forma predeterminada, comprueba las dependencias para evitar romper referencias existentes. (Alias: rm.)

te remove acepta:

<path> — argumento posicional: el objeto que se va a eliminar.
-t, --type <kind> - desambigua cuando la ruta coincide con varios elementos secundarios de una tabla (p. ej., una columna y una jerarquía con el mismo nombre).
--force — omite la comprobación de objetos dependientes.
--if-exists — sale con código 0 sin error si el objeto no existe. Úsalo en canalizaciones de CI/CD idempotentes.
--dry-run — muestra una vista previa de la eliminación sin aplicarla.
--save / --save-to <path> - guarda el cambio.
--diff / --stat / --name-only - controlan cómo se muestra la salida de cambios (consulta la nota Edición del modelo).
--serialization <fmt> - sobrescribe la serialización al guardar (tmdl, bim (alias tmsl), database.json).

te remove Sales/Revenue --save
te remove "'Sales'[Revenue]" --save              # DAX form
te remove Sales/Revenue --dry-run                # Preview only
te remove Sales/OldMeasure --if-exists --save    # Idempotent

mover

Mueve o renombra un objeto del modelo. Tanto el origen como el destino son argumentos <path>. (Alias: mv y rename.)

te move acepta:

-t, --type <kind> - desambigua cuando la ruta de origen coincide con varios tipos de objeto (p. ej., una columna y una jerarquía con el mismo nombre).
--save / --save-to <path> - guarda el cambio.
--diff / --stat / --name-only - formato de la salida de los cambios (consulta la nota sobre edición del modelo).
--serialization <fmt> - sobrescribe la serialización al guardar (tmdl, bim (alias tmsl), database.json).
--force - guarda incluso si la mutación introduce errores de validación de DAX.

Cambiar el nombre de un objeto cuyo nombre no puedes establecer se rechaza con un código de salida distinto de cero, en lugar de informarse como No changes.; por ejemplo: una relación (su nombre siempre describe las columnas que une), el KPI de una medida o el permiso de tabla de un rol.

te move Sales/Revenue Finance/Revenue --save                # Move measure to another table
te move Sales/Revenue Sales/TotalRevenue --save             # Rename measure
te move Sales/Date Sales/CalendarDate -t Hierarchy --save   # Disambiguate hierarchy from column
te move "Sales/Partitions/Old" "Sales/Partitions/New" --save   # Container-form paths work too

Inspección

list

Enumera objetos con una navegación similar a la del sistema de archivos. Acepta un argumento <path-filter> que admite comodines. Se admiten tanto contenedores de nivel de modelo como contenedores con ámbito de tabla; consulta la tabla de palabras clave de contenedores anterior para ver la lista completa. (Alias: ls.)

te list acepta:

--type <kind> - limita a un tipo de objeto (table, measure, column, hierarchy, partition, relationship, role, perspective, culture, calculationitem, kpi, set, function). Sin <path-filter>, esto equivale a escribir la palabra clave del contenedor correspondiente.
--paths-only - emite una ruta de objeto por línea, ideal para pasarlo a xargs, te get o te set.
--no-multiline - contrae las celdas multilínea (normalmente expresiones DAX o M) a una sola línea y las trunca para que las filas sigan siendo fáciles de recorrer en tablas anchas. Solo afecta a la salida de texto; la salida JSON/CSV/TMSL no se ve afectada.
--output-format tmsl (alias bim) - genera los objetos coincidentes como un script TMSL/BIM. Útil para te list Tables --output-format bim > tables.json. --output-format tmdl no es compatible con ls (TMDL solo admite un único objeto; usa te get).

te list                                     # All tables in the model
te list Sales                               # All children of Sales (columns + measures + hierarchies + partitions)
te list Sales/Measures                      # Just Sales's measures
te list 'Sales/*Amount'                     # Children of Sales whose name ends with Amount
te list 'Sa*'                               # Tables whose name starts with Sa (no auto-expansion)
te list '*/Amount'                          # An Amount column/measure across every table
te list 'Roles/Re*/Members'                 # Members of every role matching Re*
te list Sales/Geography/Levels              # All levels of the Geography hierarchy
te list KPIs                                # All KPIs (with parent measure)
te list Sales/KPIs                          # KPIs on measures of Sales
te list Sets                                # Calculated sets
te list Functions                           # DAX user-defined functions
te list "'Net Sales'/'Sales Amount'"        # Quote names containing spaces
te list Measures --paths-only               # One Table/Measure per line for piping
te list --type measure                      # Same as `te list Measures`
te list Measures --no-multiline             # Wide table with column dividers, single-line DAX
te list Tables --output-format bim > tables.json   # All tables emitted as TMSL/BIM

En la salida JSON, cada objeto de la lista empieza con su objectPath, una ruta canónica que se resuelve con te get.

get

Obtiene las propiedades de un objeto del modelo, filtra y enumera conjuntos de objetos y analiza dependencias: get es el único flujo de lectura de la CLI (te list y te deps siguen disponibles como accesos directos). Acepta un <path>; si lo omites, enumera el modelo (igual que te list), o pasa . para la raíz del modelo. Una ruta comodín (te get "Sa*") o una ruta de contenedor (te get Sales/Measures) enumera todas las coincidencias sin necesidad de --ls; -p, --deps y --properties requieren exactamente un objeto, así que con una ruta comodín lo indican y sugieren quitar la opción.

te get acepta:

-p, --property <property> - obtiene una única propiedad (por ejemplo, expression, formatString).
--where <Prop=Value> - filtra el conjunto de resultados; se puede repetir (AND) y no distingue entre mayúsculas y minúsculas. Un valor sin * es una coincidencia exacta; * es un comodín, así que una búsqueda por contenido es --where Name=*margin*. Sin ruta, --where filtra las tablas de nivel superior del modelo; pasa un contenedor para buscar otros tipos (te get Measures --where Name=*margin*). Un resultado vacío indica qué se buscó y cómo se aplicó el patrón, y ofrece comandos para ampliar la búsqueda.
--properties - enumera los nombres de propiedad que acepta -p en el objeto resuelto, junto con el tipo de cada propiedad, si se puede escribir, qué contiene y, cuando una propiedad acepta un conjunto fijo de valores, los valores que admite. Se muestran ambas formas cuando difieren (Hidden / IsHidden), y las anotaciones y traducciones aparecen en la forma entre corchetes en la que deben escribirse. Las propiedades internas de control se omiten; --all las añade. Solo admite salida de texto y JSON; necesita una ruta de un solo objeto y no puede combinarse con -p, --ls, --where, --deps ni --unused.
--ls - diseño de tabla compacto (el mismo renderizado que te list).
--deps [upstream|downstream] - análisis de dependencias (predeterminado: en ambas direcciones); --deep para mostrar el árbol recursivo, --max-depth <N> (predeterminado: 10).
--unused / --hidden - muestra los objetos no usados, como en te deps.
--paths-only - una ruta canónica de objeto por línea, para canalizarla.
--no-multiline - contrae las celdas de varias líneas (con --ls/--where). Solo para la salida de texto.
-t, --type <kind> - desambigua cuando la ruta coincide con varios elementos secundarios de una tabla (p. ej., una columna y una jerarquía con el mismo nombre). Valores: Measure, Column, CalculatedColumn, Hierarchy, Calendar, Partition, CalculationItem.
--output-format tmsl (alias bim) - genera el objeto resuelto como JSON TMSL/BIM.
--output-format tmdl - genera el objeto resuelto como TMDL (solo objetos con nombre).

te get y te list comparten un único catálogo de descriptores, así que cada propiedad se muestra igual en todos los formatos: la tabla de texto, JSON y CSV muestran el mismo conjunto, y al añadir una propiedad nueva al modelo, queda expuesta en todas partes.

La línea Settable: en el resultado de te get <path> enumera las propiedades que te set acepta en ese objeto (entre ellas, SortByColumn) y termina con una referencia a --properties para ver la lista completa; un nombre de propiedad desconocido en te get -p o te set -p remite a esa misma lista. te get -p resalta la sintaxis de todas las propiedades cuyo valor es una expresión, incluidas las filas de detalle y las expresiones de cadena de formato dinámicas. En la salida JSON, un único objeto comienza con objectPath (la ruta canónica, que te get, te set o te remove pueden resolver tal cual), seguido de type y properties; una lista sin coincidencias imprime un array vacío.

te get Sales/Amount -p expression                # Print DAX
te get "'Sales'[Amount]"                         # DAX form: same as Sales/Amount
te get "[Total Sales]"                           # Lone-bracket: model-wide measure-or-column
te get "'Net Sales'[Sales Amount]" -p expression # DAX form with spaced names
te get Sales/Revenue/KPI                         # KPI sub-object of a measure
te get Sales --output-format tmdl                # Emit the table as TMDL
te get Sales --output-format bim                 # Emit the table as TMSL/BIM
te get . -p description                          # Model-level property
te get "Sa*"                                     # Every table matching the wildcard, no --ls needed
te get Measures --where IsHidden=true --ls       # Filter + list rendering
te get Measures --where Name=*margin*            # Contains-search across all measures
te get Sales/Amount --properties                 # Property names -p accepts, with types and allowed values
te get Sales/Revenue --deps downstream --deep    # Recursive dependents

buscar

Busca texto en las propiedades de cadena y genera un Report por cada ubicación coincidente. De forma predeterminada, el patrón es una subcadena literal que no distingue mayúsculas de minúsculas; te find "Gross*" busca un asterisco literal, así que pasa --regex si quieres buscar por patrón. Usa te get --where Name=*Gross* cuando quieras filtrar objetos por el valor de una propiedad en lugar de buscar texto. Un resultado vacío indica el ámbito que se buscó y el modo de coincidencia utilizado, y ofrece comandos para ampliar la búsqueda; si un patrón de --regex no es una expresión regular válida, se rechaza con un error que identifica la opción y el patrón.

te find acepta:

--in <scope> — ámbito: names, expressions, descriptions, displayFolders, formatStrings, annotations, all (predeterminado: all).
--regex, --case-sensitive, --paths-only.
--no-multiline - contrae el contexto de coincidencia multilínea a una sola línea. Solo para la salida de texto.

--in expressions abarca todos los IExpressionObject del modelo, incluidas las TargetExpression / StatusExpression / TrendExpression de los KPI, la DetailRowsExpression de la medida, el M de origen/sondeo de la partición, la FilterExpression de los permisos de tabla y las expresiones MultipleOrEmptySelection / NoSelection del grupo de cálculo; así, un literal como 123 definido en el objetivo de un KPI aparece igual que el cuerpo de una medida.

te find "CALCULATE" --in expressions
te find "Revenue" --in names
te find "CALCULATE" --in expressions --paths-only | xargs -I{} te get {} -p expression
te find "Gross.*Margin" --in names --regex

Con --output-format json, te find genera un Report del ámbito que buscó y del modo de coincidencia que utilizó, junto con las coincidencias.

diferencias

Compara dos modelos para detectar diferencias estructurales. Devuelve los siguientes códigos de salida: 0 = idéntico, 1 = diferencias encontradas, 2 = error.

Los cambios se presentan en un Report de la misma manera que lo hacen los comandos que modifican el modelo con su propio Report: una entrada consolidada por cada objeto cambiado, con líneas -/+ por propiedad en la salida de texto. En JSON, las entradas del array changes incluyen objectPath (la ruta canónica, que puedes pasar por una tubería a te get), objectType (el mismo vocabulario cerrado que el JSON de hallazgos: KPI, Member, ...), changeKind (created, deleted, modified o moved: un objeto renombrado que lleva una etiqueta de linaje es una sola entrada moved con movedFromObjectPath) y un array properties de {property, before, after} con nombres de propiedad en PascalCase. Un objeto que existe solo en uno de los dos modelos se enumera junto con su contenido: los filtros de seguridad a nivel de filas de un rol nuevo, las columnas, medidas y particiones de una tabla nueva, los niveles de una jerarquía nueva; cada uno como su propia entrada, y los recuentos del resumen los incluyen.

te diff ./model-v1 ./model-v2
te diff old.bim new.bim

# Branch on exit code (POSIX sh):
te diff ./a ./b; case $? in 0) echo same;; 1) echo different;; *) echo error;; esac

# Branch on exit code (PowerShell):
te diff ./a ./b; switch ($LASTEXITCODE) { 0 { 'same' } 1 { 'different' } default { 'error' } }

dependencias

Analiza las dependencias ascendentes y descendentes de un objeto, o detecta objetos sin usar en todo el modelo. Un atajo para te get --deps / te get --unused. La forma de un solo objeto acepta un <path>.

te deps admite:

--upstream - muestra solo las dependencias aguas arriba (lo que usa este objeto).
--downstream - muestra solo las dependencias aguas abajo (lo que usa este objeto).
--deep - muestra el árbol recursivo de dependencias en lugar de solo las dependencias directas.
--max-depth <N> - profundidad máxima del recorrido de --deep (valor predeterminado: 10).
-t, --type <kind> - desambigua cuando la ruta coincide con varios elementos secundarios de una tabla (p. ej., una columna y una jerarquía con el mismo nombre).
--unused - enumera las medidas, las columnas calculadas y todas las columnas de datos a las que no hace referencia ninguna expresión DAX y que no se usan en ninguna relación, nivel de jerarquía, ordenación por columna, variación, base de AlternateOf ni rol de tiempo de calendario. Cada resultado muestra (hidden) en modo de texto y un campo isHidden en JSON.
--hidden - limita --unused a solo los objetos ocultos. Los objetos ocultos y sin usar son los candidatos más seguros para eliminar, porque ningún elemento visible para el usuario depende de ellos.

En la salida JSON, cada entrada —y cada nodo del árbol de upstream, downstream y --deep— se denomina igual que el resto de objetos en la CLI: objectPath (ruta canónica, que puede pasarse por una canalización a te get), object (nombre simple) y objectType.

te deps Sales/Revenue                     # Upstream + downstream for one object
te deps "'Sales'[Revenue]"                # DAX form is accepted everywhere a <path> is
te deps Sales/Revenue --downstream --deep # Everything that depends on Revenue, recursively
te deps --unused                          # All unused measures and columns
te deps --unused --hidden                 # Only hidden, unused objects

Análisis y calidad

validate

Valida las expresiones del modelo, la integridad del esquema y los errores de TOM.

te validate admite:

--ci <fmt> - emite anotaciones de CI en stderr: vsts (alias azdo, azure-devops) o github (alias gh). none o un valor vacío significa que no habrá anotaciones; cualquier otro valor se rechaza antes de ejecutar el comando.
--trx <PATH> - escribe los resultados en un archivo .trx de VSTEST.
--errors-only - abreviatura de --no-warnings --no-antipatterns: solo muestra errores.
--no-warnings - oculta las advertencias del analizador semántico.
--no-antipatterns - oculta las sugerencias de antipatrones (indicaciones de buenas prácticas de DAX).
--server-only - muestra solo los errores reportados por el servidor conectado; omite el análisis semántico local.
--no-multiline - contrae el contenido multilínea de las celdas (mensajes de error, expresiones) en una sola línea. Solo para la salida de texto.

te validate -m ./model
te validate --ci github --trx results.trx
te validate --errors-only                 # Hide warnings and anti-pattern hints

Cada hallazgo tiene un código estable, que se muestra en la columna Código de las tablas de Errores, Advertencias y Antipatrones, así como en JSON, en las anotaciones --ci y en --trx. Hay tres códigos que conviene conocer cuando se trabaja con un modelo escrito a mano: TE0012 (una columna y una medida, o dos columnas, comparten un nombre dentro de una tabla) y TE0013 (el nombre de una medida se repite entre tablas) son errores: Analysis Services se niega a cargar ese modelo y te save-as se niega a escribirlo a menos que se proporcione --force o --skip-validation; TE0014 es una advertencia de que una carpeta TMDL no tiene database.tmdl, por lo que el nivel de compatibilidad vigente sustituye al declarado por el modelo. La carpeta sigue cargándose y te validate sigue saliendo con código 0 pese a TE0014; ocúltala como cualquier otra advertencia con --no-warnings o --errors-only.

Con --output-format json, te validate emite el documento JSON compartido de hallazgos (summary más un array plano findings[]) que comparte con te bpa run, te test run y te query; consulta Resultados legibles por máquina (JSON).

Note

te validate no admite --output-format csv: CSV se rechaza desde el inicio con un error claro y con indicaciones para resolverlo, en lugar de producir un resultado parcial. Use text o json para la salida de validación.

bpa run

Ejecuta reglas de Best Practice Analyzer contra un modelo.

te bpa run admite:

-r, --rules <rules> - ruta(s) o URL(s) a archivo(s) de reglas BPA en formato JSON. Se puede repetir. Sustituye la capa de reglas de usuario en esta invocación: consulta Orígenes y resolución de reglas más abajo.
--no-model-rules - excluye las reglas de BPA incrustadas en las anotaciones del modelo.
--no-defaults - excluye las reglas predeterminadas de BPA integradas.
--vpax <file> - carga estadísticas del Analizador VertiPaq desde un archivo .vpax para habilitar reglas compatibles con VPA.
--allow-external-rules - permitir obtener archivos de reglas de BPA desde direcciones URL incrustadas en las anotaciones del modelo.
--rule <id> - ejecutar solo regla(s) específicas por ID. Se puede repetir.
--path <path-filter> - limitar el análisis a las tablas que contengan los objetos coincidentes. Acepta nombres literales, palabras clave de contenedor y comodines (por ejemplo, 'Sales', 'Sa*', 'Sales/Medidas', '*/Amount').
--fix - aplicar expresiones de corrección para corregir automáticamente las infracciones cuando sea posible.
--save - volver a guardar el modelo en el origen después de aplicar las correcciones.
--save-to <path> - guardar el modelo en una ruta diferente después de aplicar las correcciones.
--diff / --stat / --name-only - modifican la presentación de la salida de cambios durante la fase de corrección (consulta la nota Edición del modelo).
--serialization <fmt> - serialización del modelo: tmdl, bim (alias tmsl), Database.json.
--fail-on <severity> - umbral de fallo: error (predeterminado) o warning. Sale con el código 1 cuando las infracciones alcanzan el umbral. Los errores de carga o evaluación de reglas (expresiones no válidas, archivos de reglas ilegibles) también provocan un código de salida distinto de cero, independientemente de --fail-on.
--ci <fmt> - emite comandos de registro de CI en stderr: vsts (Azure DevOps; alias azdo, azure-devops) o github (GitHub Actions; alias gh). Los valores no reconocidos se rechazan de entrada.
--trx <path> - escribir los resultados como un archivo .trx de VSTEST en la PATH especificada.
--no-multiline - contraer el contenido de varias líneas de las celdas de la tabla de infracciones en una sola línea. Solo para la salida de texto.

te bpa run --fail-on error --ci github
te bpa run --fix --save
te bpa run --rule PERF_UNUSED_HIDDEN_COLUMN
te bpa run --path Sales            # Tables touched by the Sales filter only
te bpa run --path 'Sa*'            # Wildcard - every table starting with Sa
te bpa run --path Sales/Measures   # Path filter applied to the matched tables

Con --output-format json, te bpa run emite el documento JSON compartido de hallazgos (consulta @te-cli-findings); con --fix, el JSON es un único documento que también incluye el conjunto de cambios fix.

Orígenes de las reglas y su resolución

Cada invocación de te bpa run reúne reglas de tres capas independientes:

Reglas de usuario - se aplica exactamente un origen, en este orden de prioridad:
- -r, --rules <rules>: acepta una PATH de archivo o una URL (prioridad más alta)
- La variable de entorno TE_BPA_RULES
- la matriz bpa.rules de la configuración de la CLI (~/.config/te/config.json)
Reglas integradas predeterminadas - se cargan a menos que se pase --no-defaults o que bpa.builtInRules sea false en la configuración. Se omiten las reglas integradas individuales incluidas en bpa.disabledBuiltInRuleIds.
Reglas integradas en el modelo - reglas en la anotación BestPracticeAnalyzer_Rules del modelo; se cargan a menos que se pase --no-model-rules. Se omiten las anotaciones de URL externas, a menos que también pases --allow-external-rules.

Los valores predeterminados integrados son exactamente el conjunto de reglas integradas documentado en Tabular Editor 3 (los ID TE3_BUILT_IN_*), por lo que te bpa run y TE3 Desktop coinciden en lo que señalan las reglas integradas. Las seis reglas del Analizador VertiPaq (VPA_*) que en versiones preliminares anteriores se presentaban como integradas no forman parte de ese conjunto, y la opción --vpa-rules ya no existe; si una canalización depende de alguna de ellas como criterio de validación, copia su definición en tu propio archivo de reglas y haz referencia a ese archivo con --rules, bpa.rules o TE_BPA_RULES. --vpax no ha cambiado y sigue proporcionando las estadísticas que lee una regla propia compatible con VPA. Los C# Scripts (te script, te macro run) acceden al mismo conjunto de reglas a través de Bpa.Rules y Bpa.Analyze().

Cada ID de regla se evalúa una vez. Cuando el mismo ID aparece en más de una capa, en te bpa run prevalece la definición de un archivo --rules explícito, mientras que en las validaciones al implementar o guardar prevalece la definición integrada. Después se eliminan los ID de reglas de la anotación BestPracticeAnalyzer_IgnoreRules del modelo.

La línea Rules loaded: de la salida atribuye cada capa que contribuye, por ejemplo:

Rules loaded: 38 from 1 file(s) from bpa.rules config + built-in defaults + model annotations

bpa rules

Administra colecciones de reglas de BPA: enumera, inspecciona, inicializa y activa o desactiva reglas en tu archivo local de reglas o en las anotaciones del modelo. Las reglas integradas son de solo lectura; para omitir una sin perder el resto, usa te bpa rules disable (no edites directamente el conjunto integrado).

Subcomandos:

Subcomando	Propósito
`add <id>`	Agrega una nueva regla de BPA.
`disable`	Desactiva una regla de BPA integrada para el usuario actual.
`enable`	Vuelve a activar una regla de BPA integrada que se había desactivado antes.
`ignore <rule-id>`	Agrega una regla a la lista de ignorados del modelo.
`init`	Crea un archivo vacío de reglas de BPA en la ruta PATH resuelta.
`list` (alias `ls`)	Enumera las reglas de BPA de todos los orígenes con su estado.
`remove <rule-id>` (alias `rm`)	Elimina una regla de BPA.
`set <rule-id>`	Actualiza las propiedades de una regla del BPA.
`unignore <rule-id>`	Elimina una regla de la lista de reglas ignoradas del modelo.

Todos los subcomandos de te bpa rules aceptan:

--rules-file <PATH>: ruta a un archivo JSON de reglas del BPA. De forma predeterminada, se usa la primera entrada existente de bpa.rules en la configuración de la CLI (~/.config/te/config.json) o la variable de entorno TE_BPA_RULES.
--model-rules: opera sobre las reglas incrustadas en la anotación del modelo en lugar de un archivo.

Important

te bpa rules set y te bpa rules remove no permiten modificar los ID de reglas integradas. Si intentas hacerlo, el comando finaliza con el código 1 y te indica que uses te bpa rules disable. Para personalizar el comportamiento de una regla integrada, deshabilita la regla integrada y agrega una copia personalizada con un identificador distinto:

te bpa rules disable TE3_BUILT_IN_DATE_TABLE_EXISTS
te bpa rules add MY_DATE_TABLE_EXISTS

bpa rules list

Muestra las reglas de todos los orígenes (integradas, de usuario y del modelo). (Alias: ls.)

te bpa rules list acepta:

(predeterminado) Solo las reglas activas.
--all: incluye las reglas deshabilitadas e ignoradas.
--disabled: solo los ID de reglas integradas que el usuario ha deshabilitado mediante te bpa rules disable.
--ignored: solo las reglas cuyos ID aparecen en BestPracticeAnalyzer_IgnoreRules en el modelo.
--no-defaults: excluye las reglas integradas de la salida.

te bpa rules list              # Active rules
te bpa rules list --all        # Include disabled and ignored rules
te bpa rules list --ignored

Las reglas integradas deshabilitadas se marcan con un marcador [disabled] junto al ID de la regla.

bpa rules init

Crea un archivo de reglas del BPA vacío ([]) en el PATH configurado. Úsalo una vez antes de ejecutar te bpa rules set / te bpa rules remove sobre una ruta que todavía no existe.

te bpa rules init acepta:

--force: sobrescribe un archivo existente con []. Es obligatorio si el archivo de destino ya existe.
--rules-file <path> - ruta del archivo de destino. Puede aparecer antes o después del subcomando init.

Resolución de rutas (PATH; se usa la primera coincidencia): --rules-file → variable de entorno TE_BPA_RULES → primera entrada de bpa.rules[] en la configuración de tu CLI → ./BPARules.json (directorio de trabajo actual).

te bpa rules init
te bpa rules init --rules-file ./MyRules.json
te bpa rules init --force

bpa rules add / set / remove / ignore / unignore

Modifica el archivo de reglas (add, set, remove (alias rm)) o la lista de exclusión integrada en el modelo (ignore, unignore). Los tres subcomandos que realizan cambios operan sobre --rules-file <path> o --model-rules y no permiten modificar los ID de reglas integradas.

te bpa rules add <id>: crea una regla nueva. Pasa cada propiedad como una opción con nombre:
- --name <text> - nombre descriptivo de la regla (obligatorio).
- --scope <list> - tipos de objeto separados por comas a los que se aplica la regla: medida, Column, Table, Hierarchy, partición, relación, rol, perspectiva, Culture, etc. (obligatorio).
- --expression <text> - predicado de Dynamic LINQ. Devuelve true para los objetos que infringen la regla (obligatorio).
- --category <text> - etiqueta de agrupación (por ejemplo, Performance, Naming, DAX Expressions).
- --severity <1|2|3> - 1 (información), 2 (advertencia, valor predeterminado), 3 (error).
- --description <text> - descripción orientada al usuario que se muestra cuando se dispara la regla.
- --fix-expression <text> - expresión de Dynamic LINQ usada por te bpa run --fix para corregir automáticamente.
te bpa rules set <id> - actualiza las propiedades de una regla existente. Usa -p, --property <name=value> (se puede repetir; - lee el valor desde la entrada estándar, stdin). Nombres de propiedad: name, expression, scope, category, severity, description, fixExpression.
te bpa rules remove <id> - elimina una regla.
te bpa rules ignore <id> - agrega un ID de regla a la anotación BestPracticeAnalyzer_IgnoreRules del modelo.
te bpa rules unignore <id> - elimina un ID de regla de la lista de reglas ignoradas del modelo.

# Add a rule: measures that are not hidden and have no description
te bpa rules add MEASURE_NEEDS_DESCRIPTION \
    --name "Measures should have a description" \
    --scope Measure \
    --expression "not IsHidden and string.IsNullOrEmpty(Description)" \
    --severity 2 \
    --category Metadata

# Update severity on an existing rule
te bpa rules set MEASURE_NEEDS_DESCRIPTION -p severity=3

# Remove the rule
te bpa rules remove MEASURE_NEEDS_DESCRIPTION

bpa rules disable

Deshabilita una regla BPA integrada específica. El identificador de la regla se agrega a bpa.disabledBuiltInRuleIds en la configuración de tu CLI. Las ejecuciones posteriores del gate (deploy, save, mutation) y te bpa run omiten la regla deshabilitada.

El comando es idempotente: ejecutar disable sobre una regla ya deshabilitada finaliza correctamente sin modificar la configuración. Finaliza con el código 1 si <rule-id> no es una regla BPA integrada; usa te bpa rules list para ver los identificadores válidos de reglas BPA integradas.

te bpa rules disable TE3_BUILT_IN_DATE_TABLE_EXISTS

bpa rules enable

Vuelve a habilitar una regla BPA integrada deshabilitada anteriormente al quitar el identificador de la regla de bpa.disabledBuiltInRuleIds. Finaliza con el código 1 si la regla no está deshabilitada actualmente.

te bpa rules enable TE3_BUILT_IN_DATE_TABLE_EXISTS

vertipaq

Analiza las estadísticas de almacenamiento de VertiPaq.

te vertipaq acepta:

<path> - argumento posicional opcional: un nombre de tabla para limitar el análisis a una sola tabla.
--columns, --relationships, --partitions, --all.
--detail - muestra las columnas expandidas (desglose del tamaño de datos/diccionario/jerarquía, codificación y segmentos).
--fields <list> - campos separados por comas que se mostrarán (por ejemplo, --fields name,card,size,%tbl,%db,bar). Los campos disponibles varían según la vista.
--export <file.vpax> - exporta las estadísticas de VertiPaq a un archivo .vpax para analizarlas sin conexión.
--import <file.vpax> - carga un archivo .vpax exportado previamente y lo analiza sin conexión.
--obfuscate - ofusca nombres y expresiones en el VPAX exportado.
--top <N>, --stats, --annotate, --save.
--auth <method> - sobrescribe el método de autenticación al conectarse a un modelo remoto.

te vertipaq                      # Columns by size (default)
te vertipaq Sales                # Stats limited to the Sales table
te vertipaq --all                # Tables, columns, relationships, partitions
te vertipaq --export stats.vpax
te vertipaq --import stats.vpax  # Analyze offline

Formatear expresiones

El formato de expresiones se gestiona en tres lugares, según lo que estés formateando:

Una expresión del modelo: te set <path> --format <PropertyName> --save - consulta set.
Una expresión independiente (que no está en ningún modelo): te util format-dax / te util format-m - consulta Utilidades.
Un barrido de todo el modelo: te script --inline "Model.AllMeasures.FormatDax();" --save.

El DAX de un modelo siempre está separado por comas, así que --semicolons solo existe en te util format-dax para el DAX que hayas escrito tú mismo con punto y coma.

Ejecución

query

Ejecuta una consulta DAX contra un modelo implementado.

te query admite:

<dax> - argumento posicional: la consulta DAX que se va a ejecutar. Equivale a pasar -q. Usa la forma que se lea mejor; si se proporcionan ambas, prevalece el -q explícito.
-q, --query <dax> - consulta en línea (forma con opción con nombre del argumento posicional anterior). -q - lee la consulta desde stdin; si la entrada llega por canalización y no se proporciona ninguna consulta, stdin se lee implícitamente.
--file <file.dax> - consulta desde un archivo.
--limit <N> - valor predeterminado: 100.
-o, --output-file <path> - escribe los resultados en un archivo (.csv, .tsv, .json, .dax).
--trace, --cold, --plan, --runs <N> - seguimiento del rendimiento y pruebas comparativas.
--no-validate - omite la validación semántica de DAX previa a la ejecución.

te query "EVALUATE TOPN(5, 'Sales')" -s my-ws -d my-model           # Positional DAX
te query -q "EVALUATE TOPN(5, 'Sales')" -s my-ws -d my-model        # Named-flag form
te query --file query.dax --output-format json

script

Ejecuta uno o varios C# Scripts contra un modelo semántico. La CLI usa el mismo host de scripts que Tabular Editor 3 Desktop, así que un script que se ejecuta en TE3 se ejecuta aquí sin cambios.

te script admite:

--file <path> - archivo .cs / .csx (repetible). También se aceptan argumentos posicionales .cs/.csx sin nombre.
--inline <code> - C# en línea (repetible; usa - para stdin).
--validate - compila el/los script(s) e informa de errores sin ejecutarlos. No necesita ningún modelo, así que funciona sin conexión como linter de CI.
--save / --save-to / --serialization.
--diff / --stat / --name-only - formato de la salida de cambios (consulta la nota sobre edición del modelo).
--force - guarda incluso si la modificación introduce errores de validación de DAX.

Los archivos y los fragmentos en línea se ejecutan en el orden en que aparecen en la línea de comandos.

te script --file fix.cs --save
te script fix.cs cleanup.csx --save              # Bare positionals, run in order
te script --inline "Info(Model.Tables.Count);"
echo "Info(Model.Name);" | te script --inline -
te script --file fix.cs --validate               # Compile-only, no model needed

Una ejecución en la que algún script llama a Error(...) finaliza con un código distinto de cero, informa \"success\": false en JSON y termina indicando que la ejecución se completó con errores; aun así, los cambios que el script ya haya realizado se guardan cuando se usa --save. Warning(...) e Info(...) nunca hacen que una ejecución falle. En Windows, la directiva de administrador DisableCSharpScripts bloquea te script por completo; consulta Directivas de administrador.

Important

Dos detalles de comportamiento que conviene conocer si vas a portar un script antiguo:

No hay selección interactiva en los scripts de la CLI. Los asistentes de TE3 Desktop SelectMeasure(), SelectTable(), SelectColumn(), SelectObject() y SelectObjects() lanzan NotSupportedException cuando se invocan desde te script - la CLI no tiene interfaz de usuario para mostrar una ventana emergente. Resuelve previamente el/los objeto(s) fuera del script y pásalos a través de variables de entorno o de stdin, o bien envuelve la llamada en try/catch si el script se comparte con TE3.
Las directivas using predeterminadas coinciden con las de TE3 Desktop. Los scripts que usan DataTable, File, StringBuilder o Regex deben incluir explícitamente la directiva correspondiente using System.Data; / using System.IO; / using System.Text; / using System.Text.RegularExpressions;.

Note

Símbolos del preprocesador para scripts compartidos entre hosts. Los scripts compilados por te script tienen definido el símbolo TECLI. En los scripts de TE3 Desktop se define TE3 en su lugar, además de símbolos acotados por versión como TE3_3_10_OR_GREATER ... TE3_3_X_OR_GREATER para la versión menor actual de TE3. TE2 no define ninguno de los dos símbolos. Úselos para escribir scripts portátiles:

#if TECLI
    // CLI-only code - no UI calls
    Info($"Running under the CLI on {Environment.OSVersion.Platform}");
#elif TE3
    // TE3 Desktop-only code - UI APIs available
    ShowMessage("Hello from TE3");
#else
    // TE2 (legacy) - neither TECLI nor TE3 is defined
    Info("Hello from TE2");
#endif

#if TE3_3_15_OR_GREATER
    // Gated on a specific TE3 minor version
#endif

Consulta C# Scripts para conocer el panorama general del scripting entre versiones.

macro

Administra y ejecuta macros desde un archivo JSON de macros (normalmente MacroActions.json). El archivo de macros se determina en este orden: --macros <PATH> → la variable de entorno TE_MACROS_PATH → macros en la configuración de la CLI → ./MacroActions.json. En Windows, la directiva de administrador DisableMacros rechaza todos los comandos te macro; consulta Directivas de administrador.

Subcomandos:

Subcomando	Propósito
`list` (alias `ls`)	Listar macros.
`run <name-or-id>`	Ejecuta una macro.
`add <name>`	Agregar una macro.
`set <name-or-id>`	Actualizar las propiedades de la macro.
`remove <name-or-id>` (alias `rm`)	Eliminar una macro.
`sort`	Ordenar y reasignar los identificadores.
`init`	Crear un archivo de macros vacío en la ruta resuelta.

macro add / set / remove

Modifica el archivo de macros (add, set, remove (alias rm)). Los tres funcionan con --macros <path> (o con el archivo de macros resuelto).

te macro add <name>: crea una nueva macro. Proporciona el cuerpo del script mediante -e "<code>" (en línea) o -s <file.cs> (archivo del script). Opcional: --tooltip <text>, --contexts <list> (donde se aplica la macro, por ejemplo, Table,Medida), --enabled true|false.
te macro set <name-or-id>: actualiza las propiedades de la macro. Usa -p, --property <name=value> (se puede repetir; - lee el valor desde stdin). Nombres de propiedad: name, execute, enabled, tooltip, validContexts.
te macro remove <name-or-id>: elimina una macro.

te macro add MyMacro -e "Info(Selected.Measure.Name);" --tooltip "Print measure name" --contexts Measure
te macro set MyMacro -p tooltip="Updated tooltip"
te macro remove MyMacro

macro init

Crea un archivo de macros vacío ({"Actions":[]}) en la ruta configurada. Úsalo una sola vez cuando el archivo de macros resultante aún no exista.

te macro init acepta:

--force - sobrescribe un archivo existente. Obligatorio si el destino ya existe.
--macros <path> - ruta del archivo de destino. Puede aparecer antes o después del subcomando init.

te macro init
te macro init --macros ./project-macros.json
te macro init --force

macro run

Ejecuta una macro. Las macros que emiten tablas mediante dataTable.Output() muestran una salida con formato en la terminal, por lo que las macros de consulta de estilo DAX funcionan igual en te macro run que en TE3.

te macro run acepta:

--on <path> - establece el contexto de selección de la macro en un único objeto con nombre (una tabla, una medida, una columna, …). Equivale a hacer clic con el botón derecho en ese objeto en TE3 e invocar la macro desde el menú contextual.
--save / --save-to - guarda cualquier cambio que realice la macro. Como todos los comandos de modificación, te macro run es una ejecución de prueba sin --save.
--serialization <fmt> / --force: igual que en los demás comandos de modificación.

te macro run "Hide all measures"
te macro run "Format DAX" --on Sales/Revenue --save
te macro run "Format DAX" --on "'Net Sales'[Sales Amount]" --save   # DAX form works in --on too

Implementación y actualización

deploy

Despliega un modelo semántico en Power BI, Fabric, Azure Analysis Services o en SQL Server Analysis Services local.

Simulación de forma predeterminada: te deploy se conecta en modo de solo lectura e imprime en stdout el TMSL exacto que enviaría. Añade --execute para desplegar realmente.

te deploy acepta:

-s, --server / -d, --database - el origen del modelo, exactamente igual que en cualquier otro comando.
--target-server <target> / --target-database <name> - el destino de la implementación: el nombre de un Workspace, un endpoint o un servidor, y el nombre del modelo semántico que se creará o sobrescribirá. Si usas un nombre de servidor, un FQDN, una dirección IP o una cadena de conexión de MSOLAP, la implementación se realiza en Analysis Services (autenticación Integrada de Windows para entornos locales); si usas el nombre de un Workspace o una URL powerbi://..., la implementación se realiza en Power BI. Para orígenes de modelo locales, el destino recurre a la conexión activa de te connect; cuando el origen es remoto, las opciones de destino son obligatorias. No se permite implementar un modelo sobre sí mismo.
--execute - despliega realmente. En modo interactivo, esto muestra un resumen y un prompt de confirmación con n como opción segura predeterminada; --execute --force omite el prompt (obligatorio en CI, donde un prompt sin --force se considera un error).
--deploy-full - sobrescribir + conexiones + particiones + expresiones compartidas + roles + miembros de roles.
--deploy-connections
--deploy-partitions
--skip-refresh-policy
--deploy-roles
--deploy-role-members
--deploy-shared-expressions
--create-only
--skip-bpa - omite por completo el control de BPA.
--fix-bpa - corrige automáticamente las infracciones de BPA cuando las reglas definan una expresión de corrección.
--bpa-rules <PATH> - se puede repetir; anula bpa.rules de la configuración de tu CLI solo para este despliegue. Las reglas integradas siguen aplicándose salvo que bpa.builtInRules sea false.
--force - omite la confirmación interactiva.
--ci <fmt> - vsts (alias azdo, azure-devops) o github (alias gh); los valores no reconocidos se rechazan de entrada.
-p, --profile <name> - uso puntual de un perfil de Autenticación y conexiones guardado.

--output-format bim|tmdl se rechaza durante la implementación. Para capturar el script de implementación y revisarlo, redirige la salida de la simulación: te deploy ... > deploy.tmsl.

te deploy -m ./model --target-server my-workspace --target-database my-model --execute --force --ci github
te deploy -m ./model --target-server MY.SERVER.COM --target-database my-model --execute --force    # On-prem SSAS
te deploy -m ./model --target-server my-workspace --target-database my-model > deploy.tmsl         # Dry run: TMSL only
te deploy -s src-workspace -d src-model --target-server dst-workspace --target-database copy --execute   # Remote to remote
te deploy --local --target-server my-workspace --target-database my-model --execute                # Publish a Desktop model

Important

te deploy ejecuta el Best Practice Analyzer como control previo antes de realizar el despliegue. Consulta Configuración personalizada para la configuración del control de BPA.

Una implementación falla cuando el servidor informa de errores en uno o varios objetos, aunque los metadatos se hayan escrito: el código de salida no es cero, el JSON informa "success": false con el motivo en error, el encabezado indica que la implementación se completó con errores y --ci informa de los errores de objeto como errores. Los objetos no procesados no son un error: una implementación de solo metadatos puede, legítimamente, dejar objetos sin datos. La copia espejo del Workspace configurada con te connect -w aplica la misma regla.

Note

Cuando se establece --output-format json, la carga útil JSON de te deploy siempre incluye los valores resueltos de server y database, incluso cuando se resolvieron desde la conexión activa o el perfil, en lugar de pasarse explícitamente. Los pipelines pueden usar estos campos para confirmar el destino del despliegue sin volver a analizar la línea de comandos. Con --output-format json, te deploy también finaliza con un código distinto de cero si falla, igual que en modo texto; la carga útil JSON es el registro del error, no una señal de éxito.

refresh

Inicia una actualización de datos en un modelo implementado.

Simulación de forma predeterminada: te refresh imprime en stdout el TMSL que enviaría una actualización. Añade --execute para ejecutarla.

te refresh admite:

--type <type> - full, dataonly (alias data-only, data), automatic (alias auto), calculate (alias calc), clearvalues (alias clear), defragment (alias defrag), add (predeterminado: automatic).
--table <name> - actualiza tabla(s) específicas; se puede repetir.
--partition <Table.Partition> - actualiza partición(es) específicas.
--execute - ejecuta realmente la actualización. En un terminal, pide confirmación con n como opción segura predeterminada; añade --force para omitir la pregunta. Una ejecución desatendida (salida redirigida, --output-format json o --non-interactive) se detiene con un error a menos que se indique --force, así que te refresh --type full --execute --force es la forma para CI.
--force - omite la solicitud de confirmación.
--apply-refresh-policy <true|false|table> - aplica políticas de actualización para determinar qué particiones se actualizan con la actualización incremental; pasa un nombre de tabla para limitar la actualización a esa tabla. Las políticas se aplican de forma predeterminada cuando el tipo y el ámbito de la actualización son compatibles, excepto en los modelos hospedados en Power BI Desktop. Un valor explícito prevalece (con advertencias cuando no puede surtir efecto).
--effective-date <yyyy-MM-dd> - establece la fecha efectiva que usa la política de actualización (se omite, con una advertencia, cuando no se aplica ninguna política de actualización).
--max-parallelism <N> - establece el número máximo de particiones que se pueden actualizar en paralelo. Envuelve la actualización en un comando TMSL sequence.
--no-progress, --trace [path]. --trace sin --execute muestra una advertencia e imprime el TMSL. La temporización de la traza se basa en el reloj del servidor; el registro se conserva hasta que el servidor termina de entregar los eventos en búfer; y, al inicio de una actualización con traza, las trazas te-refresh-* de más de una hora que hayan quedado de ejecuciones interrumpidas se detienen y se descartan (las trazas de otras herramientas no se tocan nunca).

Las actualizaciones ejecutadas con --output-format json siempre incluyen un array progress; con la clave de configuración vertipaqOnRefresh habilitada, también se incluye un array vertipaq por tabla (filas, tamaño, columnas), sin necesidad de --trace.

te refresh --type full --execute                        # Full refresh (asks for confirmation at a terminal)
te refresh --type full --execute --force                # Unattended: skip the confirmation
te refresh --table Sales --type full --execute          # Single table
te refresh --type full > refresh.tmsl                   # Dry run: emit TMSL only
te refresh --apply-refresh-policy Sales --execute       # Apply Sales' incremental refresh policy

Las políticas de actualización incremental se definen con te set en el subobjeto RefreshPolicy de una tabla.

Pruebas

ejecución de prueba

Ejecuta un conjunto de pruebas de aserción de DAX contra un modelo desplegado.

te test run admite:

--suite <path> - directorio de la suite de pruebas (predeterminado: .te-tests/).
--tag <tag> - solo las pruebas con esta etiqueta.
--fail-on <severity> - error (predeterminado) o warning.
--ci <fmt>, --trx <PATH> - anotaciones de CI y salida TRX.

te test run --ci github --trx results.trx
te test run --tag revenue

Las suites se validan antes de establecer cualquier conexión; una suite que no supere la validación (por ejemplo, si falta query_file) finaliza con el código de salida 1 sin ejecutar nada. Con --output-format json, te test run emite el documento JSON compartido de hallazgos con extras específicos de las pruebas (suites, invalidSuites, testSummary) - consulta Resultados legibles por máquina (JSON).

test init / spec / use / list / snapshot / compare

te test list también acepta el alias ls.

Los subcomandos adicionales permiten crear la estructura de las pruebas, imprimir el formato de la especificación de aserciones, cambiar la suite activa, listar las suites, capturar instantáneas y comparar modelos. Consulta te test --help para más detalles.

te test init --example             # Scaffold an example suite
te test spec                       # Print the full assertion format reference
te test init --from-model --model ./my-model  # Generate stubs from your measures

Conexión y autenticación

connect

Establece (o muestra) la conexión activa para la sesión actual del terminal. Consulta Autenticación y conexiones.

te connect                                # Show current active connection
te connect my-workspace my-model          # Remote (positional)
te connect -s my-workspace -d my-model    # Remote (named-flag form)
te connect ./model                        # Local
te connect --local                        # Local Analysis Services instance (Windows)
te connect --local my-model               # Match an instance (e.g. an open report's window title) or a database name
te connect --profile prod                 # Activate a saved profile
te connect --clear                        # Clear the active connection (and any workspace mirror)

te connect --local enumera todas las instancias locales de Analysis Services —Power BI Desktop (versiones de Store y del instalador), los Workspace de Visual Studio y SSAS independiente— y, cuando una instancia hospeda varias bases de datos, muestra una indicación en dos pasos (primero la instancia y luego la base de datos). En modo no interactivo, falla y muestra la lista de candidatos en vez de seleccionar silenciosamente; acótala con te connect --local <database>.

Modo del área de trabajo (`-w` / `--workspace`)

Empareja un origen principal con un destino secundario para que cada --save posterior sincronice el modelo entre ambos. Útil para mantener una copia de trabajo local de un Workspace remoto o para enviar los cambios locales a un Workspace al guardar.

te connect <ws> <model> -w ./src - el origen principal es remoto; ./src recibe una exportación inicial de TMDL y refleja cada guardado.
te connect ./src -w <ws> <model> - el origen principal es local; un despliegue inicial envía el modelo al Workspace, y los guardados posteriores lo vuelven a desplegar automáticamente.
--workspace-format <fmt> - elige el formato en disco al reflejarlo en una carpeta/archivo: tmdl, bim (alias tmsl) o database.json. Si se omite, el formato se infiere de la ruta de destino del Workspace (por ejemplo, -w ./model.bim infiere BIM para archivos con extensión .bim).
--workspace-auth <method> - método de autenticación para un destino de Workspace remoto cuando el principal es local. Por defecto, usa --auth si está establecido; si no, auto.
--force: obligatorio cuando el destino ya existe (carpeta no vacía o base de datos existente). Sin él, te connect muestra un prompt interactivo y/n, con n como opción segura predeterminada.

Una vez activado, te set --save, te remove --save, te script --save, etc. guardan de forma transparente en ambos destinos. El orden de guardado siempre es primero local y después remoto, para que la copia en disco refleje el último cambio del usuario aunque falle el envío al servidor. Borra la réplica con te connect --clear.

te connect Finance "Revenue Model" -w ./revenue-model    # Mirror remote → local TMDL
te connect ./revenue-model -w Finance "Revenue Model"    # Mirror local → remote

Administra la autenticación almacenada en caché. Consulta Autenticación y conexiones.

profile list / show / set / remove

Administra perfiles de conexión con nombre. (Alias de te profile list: ls; alias de te profile remove: rm.) Consulta Autenticación y conexiones.

Configuración

config list / paths / init / set

Ver y administrar la configuración de la CLI. (Alias de te config list: ls.) Consulta Configuración personalizada.

te config set admite un par posicional key value o el equivalente -p key=value.

te config list                          # Display all settings
te config paths                         # Resolved macros and BPA rules file paths
te config init                          # Create default config
te config set autoFormat true
te config set -p spinner=false          # -p form

Utilidades

Utilidades que no dependen de ningún modelo. Los subcomandos de te util nunca operan sobre un modelo: se rechazan --model, -s/-d, --local, --recent y --auth.

util format-dax

Dar formato a una expresión DAX independiente.

<expression> - la expresión a la que dar formato; - la lee desde stdin.
--semicolons - da formato al DAX escrito con punto y coma como separadores de lista (configuración regional europea). La opción selecciona el dialecto con punto y coma tanto para la expresión leída como para la salida, así que está pensada para DAX que hayas escrito con punto y coma: el DAX separado por comas produce un error de sintaxis con esta opción. Solo se acepta aquí: te set --format lo rechaza, porque una expresión almacenada en un modelo siempre va separada por comas.
--long - formato largo con menos saltos de línea. El formato predeterminado es corto.
--no-space-after-function - omite el espacio después de los nombres de función.

te util format-dax "SUM ( Sales[Amount] )"
cat query.dax | te util format-dax -
te util format-dax "CALCULATE(SUM(Sales[Amt]); Sales[Region] = \"EU\")" --semicolons   # Semicolon-authored DAX

La salida JSON incluye success, formatted y errors. Para las expresiones que ya están en el modelo, usa te set <path> --format <PropertyName> en su lugar; para procesar todo el modelo, te script --inline "Model.AllMeasures.FormatDax();" --save.

util format-m

Da formato a una expresión M/Power Query independiente. - lee desde stdin; no hay opciones específicas del lenguaje. Una expresión mal formada —por ejemplo, una cadena sin terminar— se informa como un fallo con un código de salida distinto de cero, y se devuelve el texto original sin cambios; nunca un resultado truncado en silencio.

te util format-m "let x = 1 in x"
cat partition.m | te util format-m -

util migrate

Guía de referencia que muestra cómo las opciones heredadas de la CLI de Tabular Editor 2 se corresponden con la nueva CLI. Útil como referencia rápida mientras migras una canalización basada en TE2. Consulta Migración desde la línea de comandos de TE2 para ver la guía de migración completa.

te util migrate                   # Full flag mapping table
te util migrate -A                # Look up a single TE2 flag
te util migrate --output-format json     # Machine-readable mapping

Consola

interactivo

Inicia una sesión REPL guiada con un prompt adaptado al modelo. Consulta Modo interactivo.

Tip

Si ejecutas te en una terminal sin argumentos, también entrarás en el REPL de forma predeterminada (como si hubieras ejecutado te interactive). Esto lo controla la clave de configuración launchInteractiveMode; consulta Modo interactivo.

te interactive admite:

--no-banner - omite el banner de bienvenida al iniciar. Útil cuando controlas el REPL desde scripts.
--echo - muestra en stdout cada comando ejecutado antes de su salida. Útil al canalizar comandos a través de stdin para que el registro muestre qué se ejecutó.
--batch - modo por lotes no interactivo: lee comandos desde stdin línea a línea, ejecuta cada uno y sale al llegar a EOF. Se habilita automáticamente cuando stdin está redirigido.
--no-batch - fuerza el modo TTY interactivo incluso cuando stdin está redirigido (mutuamente excluyente con --batch).

te interactive                                # Connect later
te interactive --model ./model                # Start with a local model
te interactive -s MyWorkspace -d MyModel      # Start with a remote model
printf "list Measures\nexit\n" | te interactive --model ./model   # Pipe commands via stdin

Dentro de la sesión, los comandos que modifican el modelo dejan los cambios pendientes en memoria: save (sin argumentos) confirma las ediciones pendientes y revert las descarta, mientras que save-as vuelve a serializar el modelo en otro formato o ubicación. Al cerrar una sesión que aún tiene ediciones pendientes, se pide confirmación (o, cuando nadie puede responder, se avisa y se sale con un código distinto de cero); exit --force las descarta deliberadamente; consulta Modo interactivo.

Las comillas y las referencias de estilo DAX funcionan igual que fuera de la sesión - consulta la sección Rutas de objetos de arriba y Modo interactivo para más detalles sobre la división de argv con reconocimiento de corchetes dentro del REPL.

sesión

Muestra o administra la sesión actual del terminal. La CLI mantiene el estado de cada terminal (conexión activa, perfil activo, conjunto de pruebas activo) en un archivo de sesión, aislado por cada proceso de shell. Configura la variable de entorno TE_SESSION para compartir una sesión con nombre entre shells.

Subcomandos:

Subcomando	Propósito
`show`	Muestra los detalles de la sesión actual (ID, ruta del archivo, estado activo). Es la opción predeterminada cuando no se especifica ningún subcomando.
`list` (alias `ls`)	Lista todos los archivos de sesión.
`clear`	Limpia el estado activo de la sesión actual.
`prune`	Elimina los archivos de sesión cuyo proceso de shell ya no se está ejecutando.

te session prune admite:

--all - también elimina las sesiones con shells en ejecución y las sesiones con nombre (TE_SESSION). La sesión actual siempre se conserva.
--dry-run - muestra qué se eliminaría sin hacerlo.

te session                        # Show current session details
te session list                   # List all session files
te session clear                  # Clear active state for this session
te session prune                  # Remove sessions whose shell is dead
te session prune --all --dry-run  # Preview a full cleanup

autocompletado

Genera un script de autocompletado para bash, zsh, powershell (alias pwsh) o fish. Consulta Instalación y configuración.

te completion bash
te completion zsh
te completion pwsh
te completion fish

Códigos de salida

Salir	Significado
`0`	Éxito.
`1`	Fallo genérico (argumentos inválidos, fallo del comando, errores de validación, fallo de autenticación, fallo en el BPA gate con gravedad >= error, una ejecución de `te script` en la que un script generó un Report de error, una ejecución de `te deploy` que el servidor aceptó con errores en objetos). Para `te diff`: se encontraron diferencias.
`2`	Solo en `te diff`: se produjo un error al comparar, por lo que se desconoce el estado de la diferencia.

Para un control detallado en las canalizaciones de CI, combina los códigos de salida con las anotaciones --ci <vsts/github> y los archivos de resultados --trx; consulta Integración de CI/CD.

Páginas relacionadas

Tabular Editor CLI (Vista previa pública limitada) - información general y contexto.
Instalación y configuración - instalación y configuración de la CLI.
Autenticación y conexiones - autenticación y administración de conexiones.
Configuración personalizada - archivo de configuración, BPA gate y comportamiento tras la mutación.
Resultados legibles por máquina (JSON): el JSON de hallazgos que comparten validate, bpa run, test run y query.
Migración desde la línea de comandos de TE2 - mapeo de opciones TE2 → TE3.

Table of Contents

Referencia de comandos

Important

Note

Rutas de objeto

Segmentos y separadores

Uso de comillas

Referencias al estilo DAX (solo rutas de objeto)

Contenedores y palabras clave

Comodines en rutas de filtro

Errores y sugerencias

Alias de comandos

Opciones globales

Note

Note

Inicialización y guardado del modelo

save-as

Tip

init

Edición del modelo

set

Políticas de actualización incremental

add

eliminar

mover

Inspección

list

get

buscar

diferencias

dependencias

Análisis y calidad

validate

Note

bpa run

Orígenes de las reglas y su resolución

bpa rules

Important

bpa rules list

bpa rules init

bpa rules add / set / remove / ignore / unignore

bpa rules disable

bpa rules enable

vertipaq

Formatear expresiones

Ejecución

query

script

Important

Note

macro

macro add / set / remove

macro init

macro run

Implementación y actualización

deploy

Important

Note

refresh

Pruebas

ejecución de prueba

test init / spec / use / list / snapshot / compare

Conexión y autenticación

connect

Modo del área de trabajo (-w / --workspace)

auth login / status / logout

profile list / show / set / remove

Configuración

config list / paths / init / set

Utilidades

util format-dax

util format-m

util migrate

Consola

interactivo

Tip

sesión

autocompletado

Códigos de salida

Páginas relacionadas

Modo del área de trabajo (`-w` / `--workspace`)