Catálogo de las acciones que se pueden pedir sobre un data model de Board sin abrirlo a mano: qué se puede automatizar, qué datos hay que dar para cada cosa y qué devuelve. Escrito en vocabulario de Board — no hace falta saber programar.
Las acciones del día a día: consultar cómo está montado un modelo, cargar datos maestros, lanzar cargas y ejecutar procedures. Cubren la mayoría de lo que se pide.
Dime qué data models hay en este Board y cuáles están en la última versión de formato.
Devuelve: nombre de cada modelo y si está migrado al último formato.
Dame todas las entidades de Fichajes, cuántos miembros tiene cada una, sus anchos de código y descripción, y de qué grupo cuelgan.
Devuelve: por cada entidad — nombre, grupo, nº de miembros actuales, máximo reservado, ancho de código y de descripción, si es desbalanceada o de rollup, y de qué entidades es hija en la jerarquía.
Ojo: si el nombre del modelo está mal escrito o vacío, Board no da error: te contesta con otro modelo. Conviene confirmar siempre contra qué modelo se está trabajando.
Dame los 41 cubos de Fichajes con sus dimensiones, el tipo de dato de cada uno y cuánto ocupan.
Devuelve: por cada cubo — nombre visible, nombre técnico (V0001, V0002…), grupo, tipo de dato, versiones, y por cada dimensión la entidad y su sparsity.
El tamaño que devuelve es espacio reservado en disco, no número de valores. No sirve para comparar dos modelos entre sí.
Sácame la lista completa de proyectos con su código y su descripción.
Devuelve: código, descripción y orden de cada miembro. Viene paginado, pero eso se resuelve solo.
Dime qué empleados están asignados a cada oficina, y cuáles se han quedado sin asignar.
Devuelve: pares hijo → padre con código y descripción de ambos, y el total.
Dime qué jerarquías están incompletas en Fichajes.
Devuelve: dos listas — miembros hijos sin padre asignado, y padres que no tienen ningún hijo colgando. Es el mismo «analysis» que enseña la pantalla de relaciones.
Léeme el procedure «Extraer jornadas semana» de Fichajes y explícame paso a paso qué hace y cuándo usarlo.
Devuelve: el procedure entero — sus grupos, cada paso en orden, el tipo de acción de cada paso (reset de selección, data reader, dataflow, extract, llamada REST, script Python…), sobre qué data model actúa, qué cubos y entidades toca, y cuáles están desactivados. Con eso se puede redactar la explicación funcional.
Es de las cosas más útiles: permite inventariar y documentar todos los procedures de un modelo sin abrirlos uno a uno. Hay 72 tipos de paso distintos y todos se leen.
Dime qué data readers tiene el modelo, de qué fichero o conexión leen y si la última carga fue bien.
Devuelve: por cada data reader — nombre, grupo, tipo (fichero de texto, SQL, SAP…), origen, fecha de la última ejecución, registros válidos, registros descartados y duración. Es la forma de auditar cargas sin entrar en Board.
Y también se puede pedir el detalle de uno concreto: el mapeo columna → entidad/cubo, si machaca o acumula, y sus fórmulas ETL.
Añade estos 40 proyectos nuevos a la entidad Proyecto, y cambia la descripción de estos 3.
Devuelve: el número de miembros que tiene la entidad al terminar — sirve de comprobación inmediata.
Es la única escritura de datos de Board que no necesita ni data reader ni navegador. Ideal para sincronizar maestros contra un Excel o una base de datos.
El código respeta el ancho de código de la entidad y la descripción el suyo: si te pasas, la carga falla o trunca.
Asigna cada proyecto a su cliente según este listado.
Devuelve: confirmación. Después se puede releer la relación para verificar.
Para desasignar un miembro se le pone padre «ninguno». Y existe una acción hermana para asignar de golpe un padre por defecto a todos los huérfanos.
Ejecuta la carga «CargaPeriodo» y dime cuántos registros ha metido y cuántos ha descartado.
Devuelve: nada inmediato — se comprueba releyendo la tabla de data readers (fecha, válidos, descartados, duración).
Por qué necesita navegador: la orden de lanzar existe y responde «OK», pero no ejecuta nada si no viene de una sesión web abierta. Comprobado a fondo. Se automatiza igual, abriendo Board en un navegador controlado y pulsando RUN, pero es más lento y hay que elegir el fichero en la pantalla.
No es una operación inocente: un data reader puede añadir miembros, sobrescribir cubos o reemplazarlos enteros según cómo esté configurado.
Lanza el procedure «Actualizar dias transcurridos y laborables» todas las noches a las 3.
Devuelve: nada directo. El progreso y los errores se ven en los mensajes de Board; el resultado se comprueba mirando lo que el procedure haya tocado.
Por qué necesita navegador: igual que los data readers — la orden responde «OK» y no hace nada fuera de una sesión web. Se automatiza abriendo Board y pulsando RUN.
Un procedure sólo actúa sobre su propio data model. No sirve guardarlo en el modelo A para que toque el modelo B: termina sin error y sin haber hecho nada.
Créame un modelo PRESUPUESTO_2027 de 2024 a 2032, con trimestres y semanas, en español.
Devuelve: el modelo creado con sus entidades temporales ya montadas (Día, Mes, Semana, Trimestre, Año, Año Fiscal y cuatro huecos para entidades temporales a medida).
En Board crear el modelo es definir su calendario: no son dos pasos. Y ampliar el rango de años después obliga a recalcular, así que conviene pedirlo con margen.
Crea una entidad Centro de coste con código de 10 y descripción de 40, hasta 5.000 miembros, en el grupo «Organización».
Devuelve: la entidad creada. También se pueden modificar varias de golpe, moverlas de grupo, reordenarlas, vaciarlas o borrarlas.
Crear la entidad no la cuelga de ninguna jerarquía: eso es un paso aparte.
Hay modelos antiguos con descripción más corta que el código; hoy Board ya no lo permite, así que no se pueden replicar tal cual.
Haz que Proyecto cuelgue de Cliente, Tipo y Estado.
Devuelve: el estado de la relación resultante, incluidos avisos de corrupta, duplicada o sobrecargada.
Es un reemplazo, no un añadido: se manda la lista entera de padres. Para añadir uno hay que enviar los que ya había más el nuevo.
Crea un cubo Ventas presupuestadas con dimensiones Mes, Producto y Cliente, en decimales.
Devuelve: el cubo creado con su nombre técnico. También se puede vaciar un cubo manteniendo la definición, borrar una versión concreta o borrarlo entero.
Ninguna de estas acciones pide confirmación: el diálogo «¿Seguro?» que ves en Board lo pone la pantalla, no el servidor. Vaciar o borrar es inmediato e irreversible.
Y cambiar las dimensiones de un cubo existente lo recalcula y puede perder datos.
Operaciones de proyecto: clonar modelos enteros, mover datos entre entornos, exponer datos a otros sistemas, y las cosas que hoy siguen exigiendo pasar por la interfaz.
Créame una copia vacía de Fichajes llamada fichajes-test, con las mismas entidades, jerarquías y cubos.
Copia: calendario, entidades con sus anchos y grupos, jerarquías, y cubos con sus dimensiones y sparsity.
No copia: datos, data readers, procedures, capsules ni pantallas.
Verificado con un modelo real: 17 entidades, 5 jerarquías y 41 cubos, dejando el origen intacto.
Los nombres técnicos se reasignan: el cubo V0008 del origen puede ser V0006 en el destino. Cualquier cosa que referencie un cubo por su nombre técnico no es portable tal cual.
Pásame a fichajes-test todos los miembros de Fichajes y las asignaciones de cada jerarquía.
Devuelve: un cotejo entidad por entidad — miembros en origen vs. destino — y las jerarquías que quedan incompletas.
Se empareja por nombre de entidad y por código de miembro, nunca por números internos: esos se reasignan siempre.
No olvides los miembros «a medida» dentro de entidades temporales (por ejemplo Días de la semana o Periodo): no los crea el calendario y es fácil darlos por hechos.
Replica en fichajes-test los datos reales de los cubos de Fichajes.
Dataset\<origen>\All\Cubes.Cómo funciona: se ejecuta en el modelo origen un procedure de tipo Extract all cubes, que deja un fichero por cubo con cabecera; luego se crea automáticamente un data reader por fichero en el destino y se lanzan.
Los ficheros llevan en la cabecera el nombre visible de cada entidad y del cubo — por eso el clon funciona aunque los números internos y los nombres técnicos no coincidan.
Ejecución real: 36 ficheros, 36 data readers, 17.671 registros cargados y 0 descartados.
Necesita navegador dos veces: para lanzar el extract en el origen y para lanzar las cargas en el destino. Y el extract escribe ficheros en la carpeta de dataset del modelo origen (no toca el modelo, pero sí el disco).
Montáme un data reader que lea ventas_2027.csv y cargue el cubo Ventas cruzando Mes, Producto y Cliente.
ventas_*.csv).Truco: si el fichero lleva cabecera con los nombres de las entidades y del cubo, Board propone el mapeo solo. Ahorra casi todo el trabajo.
El separador es una trampa clásica: si te equivocas, el data reader se ejecuta «bien» y descarta el 100 % de los registros sin decir por qué. La vista previa del fichero lo autodetecta y no avisa del error.
Y el emparejamiento del cubo que propone Board no siempre acierta — conviene revisarlo contra el nombre visible del cubo.
Crea una API Query VentasPorMes para que Power BI pueda leer ese dato de Board.
Devuelve: la query creada. Cada una publica un punto de acceso propio en la API pública de Board.
Crear la query no define qué datos devuelve: eso es su layout (qué cubos y qué entidades), y ese paso sigue exigiendo el editor de layouts.
La API pública de Board no puede ni listar ni crear API Queries: se preparan por dentro y se consumen por fuera.
Que un sistema externo lea datos de Board por REST sin usar el cliente web.
Estado: la vía existe y está documentada, pero hasta que no se dé de alta un cliente API en el Subscription Hub no se puede usar. No hay atajo: el permiso de la sesión web no sirve, aunque lo parezca.
Dame el valor de Jornadas Imputadas para este empleado y este mes.
Alternativas: (1) exportar el cubo a fichero con un procedure de extract y leer el fichero; (2) crear una API Query y consumirla por la API pública; (3) montar un layout en una pantalla y exportarlo.
Los valores de cubo sólo se ven a través de un layout dentro de una capsule. No hay ninguna forma directa de preguntar «cuánto vale esta celda».
Cambia el presupuesto de este proyecto en marzo a 12.000 €.
Alternativas: (1) preparar un data reader y lanzarlo; (2) un procedure que encadene limpiar el cubo + cargar + calcular; (3) si es un maestro y no un valor, la carga de miembros sí es directa.
El data entry de Board no escribe «la intersección Mes×Proyecto del cubo X», escribe la celda que el usuario está viendo: depende de la pantalla abierta, de la selección activa y de cómo esté pintada la rejilla. Reproducirlo por fuera equivale a reimplementar el cliente web.
Móntame un procedure que limpie el cubo de forecast, lance las tres cargas y ejecute el dataflow de reparto.
Devuelve: el procedure guardado, listo para ejecutar. Se puede reescribir un procedure existente entero, así que también sirve para activar o desactivar un paso concreto y luego dejarlo como estaba.
Se manda el procedure completo, no un parche: para cambiar un paso hay que leer el procedure, modificarlo y volver a guardarlo entero. Guardar antes el original es la forma segura de poder revertir.
Sácame a CSV los miembros de Proyecto y el árbol completo de Empleado.
Devuelve: un fichero por entidad en la carpeta de dataset del modelo, con código y descripción (o la jerarquía entera).
Esta sí funciona sin navegador — a diferencia de la extracción de cubos, que exige un procedure. Sobrescribe extracciones anteriores de esas mismas entidades.
Haz un punto de restauración de Fichajes antes de tocar nada.
Devuelve: confirmación. Tras borrar, la lista de modelos restantes.
Ninguna pide confirmación. Borrar un data model lo elimina entero y al instante. Es el motivo por el que conviene fijar siempre y explícitamente sobre qué modelo se trabaja antes de lanzar nada.
Hazme un inventario de todo: modelos, entidades, cubos, procedures, data readers y API Queries, en una hoja de cálculo.
Devuelve: el inventario completo cruzado — qué cubo usa qué entidades, qué procedure toca qué cubo, qué data reader alimenta qué. Es una de las cosas con mejor relación esfuerzo/valor: documenta un Board entero sin abrirlo.
Duplica esta pantalla y cámbiale el layout para que muestre el nuevo cubo.
Estado: se pueden listar y leer capsules, pantallas y objetos sin problema. Crear y editar layouts es donde sigue haciendo falta la interfaz: el editor trabaja con identificadores que sólo existen mientras la pantalla está abierta.
Es el eslabón que hoy impide dejar una API Query lista para consumir de punta a punta sin tocar Board.
Dime qué perfiles hay definidos en este modelo y qué ve cada uno.
Devuelve: los perfiles definidos. Crearlos y modificarlos también está disponible, aunque es de lo menos probado.