Desde múltiples herramientas cliente se pueden crear conexiones y lanzar consultas contra cubos de Analysis Services, tanto en formato tabular como multidimensional. Es muy común encontrar reportes que se nutren de información leída desde estos cubos. Vamos a analizar cuales son los diferentes comportamientos de tres herramientas cliente cuando cambiamos la visibilidad de un atributo de una dimensión.
A modo de refresco, vamos a ver como podemos cambiar la visibilidad de un atributo en SSAS. Sobre el cubo de Adventure Works 2012 (multidimensional) vamos a usar la dimensión Fecha y tomaremos un atributo que se encuentre dentro de una jerarquía pero que se pueda seleccionar fuera de ella, como por ejemplo “Calendar Year”
Podemos ver el atributo fuera de la jerarquía porque tiene su propiedad AttributeHierarchyVisible establecida a True. Establecerla a False permitiría ver el atributo dentro de una jerarquía pero no fuera de ella en las herramientas cliente. Sin embargo, el atributo seguiría siendo consultable con una sentencia MDX lanzada directamente contra SSAS. En este caso, desde SQL Server Management Studio:
Después de cambiar el la propiedad AttributeHierarchyVisible de Calendar Year a False, desplegamos en nuestro servidor de SSAS y volvemos a lanzar la misma consulta y obtenemos el mismo resultado:
De acuerdo, SQL Server Management Studio no es una herramienta cliente con la que normalmente los usuarios de negocio se conectarán a un cubo. Veamos que sucede con otras herramientas.
Empezaremos por la herramienta por antonomasia, Excel 2013:
Sencillamente, no veremos el atributo, mientras que el resto de atributos de la carpeta Calendar sí están visibles para su uso fuera de las jerarquías de las que forme parte. Este es el comportamiento esperado, y dado que en Excel no podemos escribir consultas MDX directamente como en SSMS, no podremos usar este atributo fuera de la jerarquía.
Pero, ¿qué pasa con las herramientas cliente que sí permiten lanzar MDX escrita por nosotros? Probemos con SQL Server Reporting Services 2012.
Tenemos un dataset atacando al mismo cubo (ya desplegado con el atributo establecido a no visible) con la misma consulta:
Probamos la consulta y desde SQL Server Data Tools nos permite ejecutarla sin problemas:
También podremos ejecutar el informe sin dificultad si lo desplegamos a un servidor de Reporting Services 2012, en este caso una sencillo grafico de barras que muestra los resultados:
En este caso sí podemos usar el atributo fuera de la jerarquía a pesar de que está configurado para que la herramientas cliente no lo puedan ver. Al lanzar la MDX directamente, SSAS asume que conocemos aquellos atributos que estemos usando, resuelve correctamente la consulta y nos devuelve los datos.
Vamos a ver qué sucede ahora con PerformancePoint Services en SharePoint 2013. Desde el diseñador de PerformancePoint Services 2013, creamos un nuevo gráfico analítico y pegamos la consulta en la pestaña “Query”:
Si tenemos el atributo a visible, e intentamos cómo quedaría el gráfico, podemos verlo sin problemas:
Sin embargo, con la propiedad del atributo AttributeHierarchyVisible establecida a False recibimos este error:
Si nos encontrásemos este error sin saber su causa, deberíamos ir al Visor de Eventos y nos encontraríamos un error de la aplicación de PerformancePoint Services con el siguiente texto de error:
En un primer momento vemos que tenemos una excepción de referencia a un objeto no instanciado (para los que hayáis programado orientado a objetos, como si nos faltase una cláusula “new”). Luego vemos que el último método de la pila de llamadas se llama “CreateMetadataScript”. La visibilidad del atributo fuera de la jerarquía es metadato de la dimensión del cubo Adventure Works, lo que nos lleva a pensar que primero intenta establecer el metadato disponible y al no encontrar el atributo usado en la consulta MDX, genera una excepción en el código. En este caso podemos establecer la causa del error de manera relativamente directa, ya que conocemos los cambios que se han dado en el cubo. Si nos encontrásemos en un entorno en el que ha habido más cambios o en el que no controlamos todos los modelos de SSAS sobre los que construimos informes, encontrar la causa e interpretar el mensaje de error del Visor de Eventos podría ser bastante más complejo.
Para solucionarlo, simplemente tendríamos que cambiar de nuevo la visibilidad del atributo o bien usarlo dentro de las jerarquías que necesitásemos.
Recapitulando, hemos visto 3 casos diferentes en los que cada herramienta cliente trata de manera diferente los metadatos sobre visibilidad de atributos de dimensión disponibles en el cubo de Analysis Services:
| Cliente | ¿Queries MDX personalizadas? | Visibilidad de atributos |
| Excel | NO | Restringida por los metadatos del cubo |
| SSRS 2012 | SI | Libre |
| PerformancePoint Services | SI | Restringida por los metadatos del cubo |
Una premisa que vale para todos estos casos es la de la precaución y la planificación necesaria a la hora de realizar un cambio en la estructura de un cubo de Analysis Services, pero en este caso concreto hemos comprobado que un “simple” cambio en la visibilidad de un atributo puede causar que un informe de PPS 2013 falle dando un error que en un primer momento puede resultar difícil de interpretar para localizar la causa del mismo.
Espero que os sirva en caso de que os encontréis con algo parecido y os ahorre tiempo y dolores de cabeza 🙂
