Conexión a orígenes de datos SAP HANA mediante DirectQuery en Power BI

Puede conectarse a orígenes de datos de SAP HANA directamente mediante DirectQuery. Hay dos opciones para conectarse a SAP HANA:

  • Tratar SAP HANA como origen multidimensional (opción predeterminada): en este caso, el comportamiento es similar a cuando Power BI se conecta a otros orígenes multidimensionales, como SAP Business Warehouse o Analysis Services. Al conectarse a SAP HANA con esta configuración, se selecciona una única vista de análisis o cálculo, y todas las medidas, jerarquías y atributos de esa vista están disponibles en la lista de campos. A medida que se crean objetos visuales, los datos agregados se recuperan siempre de SAP HANA. Esta técnica es el enfoque recomendado y es el método predeterminado para los informes nuevos de DirectQuery en SAP HANA.

  • Tratar SAP HANA como origen relacional: en este caso, Power BI trata SAP HANA como un origen relacional. Este enfoque ofrece una mayor flexibilidad. Sin embargo, es necesario tener cuidado con este enfoque para garantizar que las medidas se agregan del modo esperado y para evitar problemas de rendimiento.

El enfoque de conexión viene determinado por una opción de herramienta global, que se configura al seleccionar Archivo>Opciones y configuración y Opciones>DirectQuery, y luego la opción Tratar SAP HANA como origen relacional, como se muestra en la imagen siguiente.

Screenshot of the Options dialog, showing the DirectQuery options.

La opción para tratar SAP HANA como un origen relacional controla el método usado para todos los informes nuevos que usen DirectQuery en SAP HANA. No surte efecto en las conexiones de SAP HANA existentes en el informe actual ni en las conexiones de otros informes que estén abiertas. Por tanto, si la opción está actualmente desactivada, al agregar una nueva conexión a SAP HANA mediante la opción Obtener datos, esta se establecerá tratando SAP HANA como un origen multidimensional. Sin embargo, si se abre otro informe que también se conecta a SAP HANA, ese informe seguirá comportándose según la opción que se estableció en el momento en que se creó. Esto significa que los informes que se conecten a SAP HANA creados con anterioridad a febrero de 2018 seguirán tratando SAP HANA como un origen relacional.

Los dos enfoques tienen comportamientos muy diferentes, y no es posible cambiar un informe ya creado de un enfoque a otro.

Tratar SAP HANA como un origen multidimensional (opción predeterminada)

Todas las conexiones nuevas establecidas con SAP HANA usan este método de conexión de forma predeterminada, tratando SAP HANA como un origen multidimensional. Si quiere tratar una conexión con SAP HANA como origen relacional, debe seleccionar Archivo>Opciones y configuración>Opciones y, después, activar la casilla situada debajo de DirectQuery>Tratar SAP HANA como origen relacional.

Al conectarse a SAP HANA como origen multidimensional, es necesario considerar lo siguiente:

  • En Get Data Navigator (Obtener navegador de datos), se puede seleccionar una sola vista de SAP HANA. No es posible seleccionar medidas o atributos individuales. No hay ninguna consulta definida en el momento de la conexión, lo cual es diferente de la importación de datos o el uso de DirectQuery cuando se trata SAP HANA como origen relacional. Esta consideración también significa que no es posible usar directamente una consulta SQL de SAP HANA al seleccionar este método de conexión.

  • Todas las medidas, jerarquías y atributos de la vista seleccionada se muestran en la lista de campos.

  • Siempre que se use una medida en un elemento visual, se consultará SAP HANA para recuperar el valor de medida en el nivel de agregación necesario para el objeto visual. Al tratar con medidas que no sean de adición, como contadores, relaciones etc., SAP HANA se ocupará de todas las agregaciones, y Power BI ya no realizará ninguna.

  • Para garantizar que siempre puedan obtenerse de SAP HANA los valores de agregado correctos, deben imponerse ciertas restricciones. Por ejemplo, no es posible agregar columnas calculadas ni combinar datos de varias vistas de SAP HANA dentro del mismo informe.

El tratamiento de SAP HANA como origen multidimensional no ofrece la mayor flexibilidad proporcionada por el enfoque relacional alternativo, pero es más sencillo. El enfoque también garantiza valores agregados correctos cuando se trabaja con medidas de SAP HANA más complejas y, por lo general, da lugar a un mayor rendimiento.

La lista Field incluye todas las medidas, atributos y jerarquías de la vista de SAP HANA. Tenga en cuenta que se encontrará con los siguientes comportamientos al usar este método de conexión:

  • De forma predeterminada, se ocultará cualquier atributo incluido en al menos una jerarquía. Sin embargo, se pueden ver si fuera necesario seleccionando Ver ocultos en el menú contextual de la lista de campos. Sin embargo, se pueden hacer visibles en el mismo menú contextual, en caso necesario.

  • En SAP HANA se puede definir un atributo para que use otro atributo como etiqueta. Por ejemplo, Product, con los valores 1, 2, 3, etc., podría usar ProductName, con los valores Bike, Shirt, Gloves, etc., como su etiqueta. En este caso, aparecería un solo campo Producto en la lista de campos, cuyos valores son las etiquetas Bike, Shirt, Gloves, etc., pero ordenados por los valores clave 1, 2, 3, que determinarán también su carácter único. También se crea una columna oculta Product.Key, que permite el acceso a los valores clave subyacentes si fuera necesario.

Las variables definidas en la vista de SAP HANA subyacente se muestran en el momento de la conexión y se pueden introducir los valores necesarios. Dichos valores se pueden cambiar posteriormente seleccionando Transformar datos en la cinta de opciones y, luego, Editar parámetros en el menú desplegable que aparece.

Las operaciones de modelado permitidas son más restrictivas que en el caso general al usar DirectQuery, dada la necesidad de comprobar que siempre pueden obtenerse los datos agregados correctos de SAP HANA. Sin embargo, resulta todavía posible realizar muchas adiciones y cambios, como definir medidas, cambiar el nombre y ocultar campos, así como definir los formatos de presentación. Todos esos cambios se conservan en la actualización, y se aplican los cambios que no planteen conflictos realizados en la vista de SAP HANA.

Restricciones de modelado adicionales

Las otras restricciones de modelado principales al conectarse a SAP HANA mediante DirectQuery (tratado como origen multidimensional) son las siguientes:

  • No se admiten las columnas calculadas: la capacidad para crear columnas calculadas está deshabilitada. Este hecho también significa que la agrupación y la agrupación en clústeres, que crean columnas calculadas, no están disponibles.
  • Limitaciones adicionales para las medidas: se han impuesto otras limitaciones sobre las expresiones DAX que pueden usarse en las medidas, para reflejar el nivel de compatibilidad que ofrece SAP HANA.
  • No se admite la definición de relaciones: solo puede consultarse una vista única dentro de un informe y, por lo tanto, no se admite la definición de relaciones.
  • Sin vista de datos: la vista de datos normalmente muestra los datos del nivel de detalle en las tablas. Dada la naturaleza de los orígenes OLAP, como SAP HANA, esta vista no está disponible a través de SAP HANA.
  • Los detalles de las columnas y medidas son fijos: la lista de columnas y medidas que se ve en la lista de campos la fija el origen subyacente y no se puede modificar. Por ejemplo, no se puede eliminar una columna, ni cambiar su tipo de datos. Sin embargo, se puede cambiar el nombre.
  • Limitaciones adicionales en DAX: hay otras limitaciones en DAX que se pueden usar en las definiciones de las medidas para reflejar las limitaciones en el origen. Por ejemplo, no es posible utilizar una función de agregado en una tabla.

Restricciones de visualización adicionales

Hay una serie de restricciones en los objetos visuales a la hora de conectarse a SAP HANA mediante DirectQuery (tratado como origen multidimensional):

  • No se permite la agregación de columnas: no es posible cambiar la agregación de una columna en un objeto visual; es siempre No resumir.

Tratar SAP HANA como origen relacional

Al elegir conectarse a SAP HANA como un origen relacional, existe cierta flexibilidad adicional. Por ejemplo, puede crear columnas calculadas, incluir datos de varias vistas de SAP HANA y crear relaciones entre las tablas resultantes. Sin embargo, hay diferencias en el comportamiento al tratar SAP HANA como un origen multidimensional, especialmente cuando la vista de SAP HANA contiene medidas no aditivas (por ejemplo, recuentos distintivos, o promedios, en lugar de sumas simples) y relacionadas con la eficacia de las consultas que se ejecutan en SAP HANA.

Resulta útil comenzar aclarar el comportamiento de un origen relacional como SQL Server, cuando la consulta definida en Obtener datos o en el Editor de Power Query realiza una agregación. En el ejemplo siguiente, una consulta definida en el Editor de Power Query devuelve el precio medio por ProductID.

Diagram showing a query defined in Power Query Editor that returns the average price by Product ID.

Si se van a importar datos en Power BI (frente al uso de DirectQuery), el resultado sería el siguiente:

  • Los datos se importan en el nivel de agregación que define la consulta creada en Editor de Power Query. Por ejemplo, el precio medio por producto. Este hecho da como resultado una tabla con dos columnas ProductID y AveragePrice que se pueden utilizar en los objetos visuales.
  • En un objeto visual, cualquier agregación subsiguiente (como Suma, Promedio, Mínimo, etc.) se realiza con los datos importados. Por ejemplo, al incluir AveragePrice en un objeto visual, se usa el agregado Suma de forma predeterminada, cuyo resultado sería la suma de AveragePrice de cada ProductID, que en este caso sería 13,67. Lo mismo se aplica a cualquier función de agregado alternativa (como Mínimo, Promedio, etc.) usada en el objeto visual. Por ejemplo, el promedio de AveragePrice devuelve la media de 6,66, 4 y 3, que equivale a 4,56, y no la media del precio de los seis registros de la tabla subyacente, que es 5,17.

Si se usa DirectQuery (sobre el mismo origen relacional) en lugar de la importación, se aplica la misma semántica y los resultados serían exactamente los mismos:

  • Si la consulta es la misma, se presentan de forma lógica y exacta los mismos datos en la capa de informes, aunque los datos no se importen realmente.

  • En un objeto visual, cualquier agregación subsiguiente (Suma, Promedio y Mínimo, etc.) vuelve a realizarse según la tabla lógica de la consulta. Y, una vez más, un objeto visual que contiene el promedio de AveragePrice devuelve el mismo resultado de 4,56.

Considere SAP HANA cuando la conexión se trata como un origen relacional. Power BI puede trabajar con las vistas analíticas y las vistas de cálculo en SAP HANA, ya que ambas opciones pueden contener medidas. Sin embargo, el enfoque en el caso de SAP HANA sigue los mismos principios descritos anteriormente en esta sección: la consulta definida en Obtener datos o en el Editor de Power Query determina los datos disponibles y, después, cualquier agregación subsiguiente aplicada a un objeto visual se calcula con respecto a dichos datos; y lo mismo se aplica para la importación y para DirectQuery. No obstante, por la naturaleza de SAP HANA, la consulta definida en el cuadro de diálogo inicial Obtener datos o en el Editor de Power Query siempre es una consulta de agregado y, por norma general, incluye medidas en las que la vista de SAP HANA define la agregación real que se va a usar.

El equivalente del ejemplo de SQL Server anterior es que hay una vista de SAP HANA que contiene las medidas ID, ProductID y DepotID, además de medidas que incluyen AveragePrice, que se define en la vista como precio promedio.

Si en la experiencia Obtener Datos las selecciones realizadas fueron para ProductID y la medida AveragePrice, entonces eso es definir una consulta sobre la vista, donde se solicitan esos datos agregados. En el ejemplo anterior, por motivos de simplicidad se usa pseudo-SQL que no coincide con la sintaxis exacta de SQL de SAP HANA. Después, todas las agregaciones adicionales definidas en un objeto visual se agregan a los resultados de dicha consulta. Una vez más, como se ha descrito anteriormente para SQL Server, este resultado se aplica a los casos de importación y DirectQuery. En el caso de DirectQuery, la consulta de Obtener datos o del Editor de Power Query se usa en una subselección dentro de una consulta única enviada a SAP HANA y, por tanto, no se da el caso realmente de que se lean todos los datos antes de realizar más agregaciones.

Al utilizar DirectQuery sobre SAP HANA, es necesario tener en cuenta las siguientes consideraciones importantes derivadas de lo anterior:

  • Es necesario prestar atención a todas las agregaciones adicionales realizadas en objetos visuales, siempre que la medida de SAP HANA no se corresponda con una adición (por ejemplo, que no sea una simple función de Suma, Mínimo o Máximo).

  • En Obtener datos o el Editor de Power Query, solo se deben incluir las columnas necesarias para recuperar los datos necesarios, lo que refleja el hecho de que el resultado sea una consulta que debe ser una consulta razonable que se pueda enviar a SAP HANA. Por ejemplo, si se seleccionaron docenas de columnas, pensando que podrían necesitarse en objetos visuales posteriores, entonces incluso para DirectQuery un objeto visual simple significa que la consulta agregada utilizada en la subselección contiene esas docenas de columnas, que generalmente tienen un rendimiento deficiente.

En el ejemplo siguiente, la selección de cinco columnas (CalendarQuarter, Color, LastName, ProductLine, SalesOrderNumber) en el cuadro de diálogo Obtener datos, junto con la medida OrderQuantity, significa que la posterior creación de un objeto visual sencillo que contiene Min OrderQuantity dé como resultado la siguiente consulta de SQL a SAP HANA. La parte sombreada es la subselección, que contiene la consulta de Obtener datos/Editor de Power Query. Si esta subselección ofrece un resultado de cardinalidad alto, entonces es probable que el rendimiento resultante de SAP HANA sea bajo.

Screenshot of a query example, showing the SQL query to SAP HANA.

Debido a este comportamiento, se recomienda limitar los elementos seleccionados en Obtener datos o en el Editor de Power Query a aquellos elementos que sean necesarios, pero siempre que el resultado sea una consulta razonable para SAP HANA.

Procedimientos recomendados

En ambos enfoques de conexión a SAP HANA, las recomendaciones para utilizar DirectQuery se aplican también a SAP HANA, en particular las relacionadas con la garantía del buen rendimiento. Para más información, consulte Uso de DirectQuery en Power BI.

Consideraciones y limitaciones

En la lista siguiente se enumeran todas las características de SAP HANA que no son totalmente compatibles, o que se comportan de forma diferente cuando se usa Power BI.

  • Jerarquías de elementos primarios-secundarios: las jerarquías de elementos primarios-secundarios no serán visible en Power BI. El motivo es que Power BI accede a SAP HANA por medio de la interfaz SQL, y no es posible acceder totalmente a las jerarquías de elementos primarios-secundarios a través de SQL.
  • Otros metadatos de la jerarquía: en Power BI se muestra la estructura básica de jerarquías; sin embargo, algunos metadatos de la jerarquía (por ejemplo, el control del comportamiento de las jerarquías desiguales) no surten ningún efecto. De nuevo, este hecho se debe a las limitaciones impuestas por la interfaz SQL.
  • Conexión mediante SSL: puede conectarse mediante importación y como origen multidimensional con TLS, pero no se puede conectar a instancias de SAP HANA configuradas para usar TLS con el conector relacional.
  • Compatibilidad con vistas de atributo: Power BI puede conectarse a las vistas de análisis y cálculo, pero no puede conectarse directamente a las vistas de atributo.
  • Compatibilidad con objetos de catálogo: Power BI no puede conectarse a objetos de catálogo.
  • Cambio en las variables después de publicar: no se pueden cambiar los valores de las variables de SAP HANA directamente en el servicio Power BI una vez publicado el informe.

Problemas conocidos

En la lista siguiente se describen todos los problemas conocidos al conectarse a SAP HANA (DirectQuery) con Power BI.

  • Problema de SAP HANA al consultar los contadores y otras medidas: se devuelven datos incorrectos de SAP HANA al conectarse a una vista de análisis y hay una medida de contador, y alguna otra medida de relación, en el mismo objeto visual. Este tema se trata en la Nota de SAP 2128928 (resultados inesperados cuando se consulta una columna calculada y un contador). En este caso, la medida de la relación será incorrecta.

  • Varias columnas de Power BI a partir de una única columna de SAP HANA: en algunas vistas de cálculo en las que se usa una columna de SAP HANA en más de una jerarquía, SAP HANA las expone como dos atributos distintos. Este enfoque da como resultado la creación de dos columnas en Power BI. Estas columnas están ocultas de manera predeterminada; sin embargo, todas las consultas que implican a las jerarquías, o a las columnas directamente, se comportan según lo esperado.

Para más información acerca de DirectQuery, revise los siguientes recursos: