Partager via

Se connecter à des sources de données SAP HANA à l’aide de DirectQuery dans Power BI

  • Article

Vous pouvez vous connecter directement à des sources de données SAP HANA à l’aide de DirectQuery, ce qui est souvent nécessaire pour les jeux de données volumineux qui dépassent les ressources disponibles pour prendre en charge les modèles d’importation. Il existe deux approches pour la connexion à SAP HANA en mode DirectQuery, chacune avec différentes fonctionnalités :

  • traiter SAP HANA comme une source multidimensionnelle (valeur par défaut) : Dans ce cas, le comportement est similaire lorsque Power BI se connecte à d’autres sources multidimensionnelles comme SAP Business Warehouse ou Analysis Services. Lorsque vous vous connectez à SAP HANA en tant que source multidimensionnelle, une seule vue analytique ou de calcul est sélectionnée et toutes les mesures, hiérarchies et attributs de cette vue sont disponibles dans la liste des champs. Vous ne pouvez pas ajouter de colonnes calculées ou d’autres personnalisations de données dans le modèle sémantique. À mesure que des visuels sont créés, les données d’agrégation sont directement récupérées à partir de SAP HANA. Le traitement de SAP HANA comme source multidimensionnelle est la valeur par défaut pour les nouveaux rapports DirectQuery sur SAP HANA.

  • traiter SAP HANA comme une source relationnelle : Dans ce cas, Power BI traite SAP HANA comme une source de données relationnelle. Cette approche offre une plus grande flexibilité. Entre autres choses, vous pouvez ajouter des colonnes calculées et inclure des données provenant d’autres sources, mais vous devez veiller à ce que les mesures soient agrégées comme prévu. Évitez les mesures non additives. Veillez également à utiliser des vues simples avec peu de colonnes et jointures pour éviter les problèmes de performance. Envisagez de recréer des mesures dans le modèle sémantique, mais gardez à l’esprit que les mesures complexes peuvent ne pas se plier. Les hiérarchies SAP HANA ne sont pas disponibles lors de l’utilisation de SAP HANA comme source relationnelle.

La méthode de connexion est déterminée par une option d’outil globale, définie en sélectionnant Options et paramètres de fichier>, puis Options>DirectQuery, puis en sélectionnant l’option Traiter SAP HANA comme source relationnelle, comme illustré dans l’image suivante.

Capture d’écran de la boîte de dialogue Options, montrant les options DirectQuery.

L’option permettant de traiter SAP HANA en tant que source relationnelle contrôle la méthode de connexion pour n’importe quel nouveau rapport à l’aide de DirectQuery sur SAP HANA. Elle n’a aucun effet sur les connexions SAP HANA existantes dans le rapport actuel, ni sur les connexions dans d’autres rapports ouverts. Par conséquent, si l’option est actuellement désactivée, lors de l’ajout d’une nouvelle connexion à SAP HANA à l’aide de Obtenir des données, cette connexion traite SAP HANA comme une source multidimensionnelle. Toutefois, si un autre rapport est ouvert qui se connecte également à SAP HANA, ce rapport continue de se comporter en fonction de l’option définie au moment de sa création. Cela signifie que tous les rapports qui se connectent à SAP HANA en tant que source relationnelle continuent de traiter SAP HANA comme une source relationnelle même si l’option est désormais décochée.

Les deux méthodes de connexion SAP HANA constituent un comportement différent et il n’est pas possible de basculer un rapport existant d’une méthode de connexion à l’autre.

Traiter SAP HANA comme une source multidimensionnelle (par défaut)

Toutes les nouvelles connexions à SAP HANA utilisent cette méthode de connexion par défaut, traitant SAP HANA comme une source multidimensionnelle. Lors de la connexion à SAP HANA en tant que source multidimensionnelle, les considérations suivantes s’appliquent :

  • Dans le Navigateur d'obtention de données, vous pouvez sélectionner une vue SAP HANA unique. Il n’est pas possible de sélectionner des mesures ou des attributs individuels. Il n’existe aucune requête définie au moment de la connexion, qui est différente de l’importation de données ou lors de l’utilisation de DirectQuery lors du traitement de SAP HANA comme source relationnelle. Cette considération signifie également qu’il n’est pas possible d’utiliser directement une requête SQL SAP HANA lors de la sélection de cette méthode de connexion.

  • Toutes les mesures, hiérarchies et attributs de l’affichage sélectionné sont affichés dans la liste des champs.

  • Lorsqu'une mesure est utilisée dans un visuel, SAP HANA est interrogé pour récupérer la valeur de la mesure au niveau d’agrégation nécessaire pour le visuel. Lorsque vous traitez de mesures non additives, telles que les compteurs et les ratios, toutes les agrégations sont effectuées par SAP HANA et aucune autre agrégation n’est effectuée par Power BI.

  • Pour garantir que les valeurs d’agrégation correctes peuvent toujours être obtenues à partir de SAP HANA, certaines restrictions doivent être imposées. Par exemple, il n’est pas possible d’ajouter des colonnes calculées ou de combiner des données à partir de plusieurs vues SAP HANA dans le même rapport. Il n’est pas également possible de supprimer des colonnes ou de modifier leurs types de données.

Le traitement de SAP HANA comme une source multidimensionnelle offre moins de flexibilité que l’alternative approche de relationnelle, mais c’est plus simple. Cette méthode de connexion garantit des valeurs d’agrégation correctes lors du traitement des mesures SAP HANA plus complexes et entraîne généralement des performances plus élevées.

La liste Champ inclut toutes les mesures, attributs et hiérarchies à partir de la vue SAP HANA. Notez les comportements suivants qui s’appliquent lors de l’utilisation de cette méthode de connexion :

  • Tout attribut inclus dans au moins une hiérarchie est masqué par défaut. Toutefois, elles peuvent être visibles si nécessaire en sélectionnant Affichage masqué dans le menu contextuel de la liste des champs. Dans le même menu contextuel, elles peuvent être rendues visibles, si nécessaire.

  • Dans SAP HANA, un attribut peut être défini pour utiliser un autre attribut comme étiquette. Par exemple, Product, avec des valeurs 1, 2, 3, et ainsi de suite, peut utiliser ProductName, avec des valeurs Bike, Shirt, Gloves, et ainsi de suite, comme étiquette. Dans ce cas, un champ unique Product est affiché dans la liste des champs, dont les valeurs sont les étiquettes Bike, Shirt, Gloves, et ainsi de suite, mais qui est triée par, et avec unicité déterminée par, les valeurs clés 1, 2, 3. Une colonne masquée Product.Key est également créée, ce qui permet d’accéder aux valeurs de clé sous-jacentes si nécessaire.

Toutes les variables définies dans la vue SAP HANA sous-jacente sont affichées au moment de la connexion, et les valeurs nécessaires peuvent être entrées. Ces valeurs peuvent être modifiées ultérieurement en sélectionnant Transformer des données à partir du ruban, puis Modifier les paramètres dans le menu déroulant affiché.

Les opérations de modélisation autorisées sont plus restrictives que dans le cas général lors de l’utilisation de DirectQuery, étant donné la nécessité de s’assurer que les données d’agrégation correctes peuvent toujours être obtenues à partir de SAP HANA. Toutefois, il est toujours possible d’apporter des ajouts et des modifications, notamment la définition de mesures, le renommage et le masquage des champs et la définition des formats d’affichage. Toutes ces modifications sont conservées lors de l’actualisation et toutes les modifications non conflictuelles apportées à la vue SAP HANA sont appliquées.

Restrictions de modélisation supplémentaires

En plus des limitations mentionnées ci-dessus, tenez compte des restrictions de modélisation suivantes lors de la connexion à SAP HANA en tant que source multidimensionnelle :

  • Aucune prise en charge des colonnes calculées : la possibilité de créer des colonnes calculées est désactivée. Cela signifie également que le regroupement et le clustering, qui reposent sur des colonnes calculées, ne sont pas disponibles.
  • Limitations supplémentaires pour les mesures : Il existe d’autres limitations imposées aux expressions DAX qui peuvent être utilisées dans les mesures, afin de refléter le niveau de support offert par SAP HANA. Par exemple, il n’est pas possible d’utiliser une fonction d’agrégation sur une table.
  • Aucune prise en charge de la définition des relations : Seule une vue unique peut être interrogée dans un rapport et, par conséquent, il n’existe aucune prise en charge de la définition des relations.
  • Aucune vue de données : La vue de données affiche normalement les données de niveau détail dans les tables. Étant donné la nature des sources multidimensionnelles, cette vue n’est pas disponible lors de l’utilisation de SAP HANA comme source multidimensionnelle.
  • Détails des colonnes et des mesures sont fixes : les colonnes et les mesures de la liste de champs sont déterminées par la source sous-jacente et ne peuvent pas être modifiées. Par exemple, il n’est pas possible de supprimer une colonne, ni de modifier son type de données. Toutefois, elle peut être renommée.

Restrictions de visualisation supplémentaires

Il existe des restrictions dans les visuels lors de la connexion à SAP HANA en tant que source multidimensionnelle :

  • Aucune agrégation de colonnes : il n’est pas possible de modifier l’agrégation d’une colonne sur un visuel ; elle est toujours définie sur Ne pas résumer.

Traiter SAP HANA comme une source relationnelle

Pour vous connecter à SAP HANA en tant que source relationnelle, vous devez sélectionner Options et paramètres de fichier>, puis Options>DirectQuery, puis sélectionner l’option Traiter SAP HANA comme source relationnelle.

Lorsque vous utilisez SAP HANA comme source relationnelle, une certaine flexibilité supplémentaire est disponible. Par exemple, vous pouvez créer des colonnes calculées, inclure des données à partir de plusieurs vues SAP HANA et créer des relations entre les tables résultantes. Toutefois, il existe des différences par rapport au comportement lors de la connexion à SAP HANA en tant que source multidimensionnelle, en particulier lorsque la vue SAP HANA contient des mesures non additives, par exemple, des nombres distincts ou des moyennes, plutôt que des sommes simples. Les mesures non additives peuvent produire des résultats incorrects. Les mesures peuvent également réduire l’efficacité de l’optimisation du plan de requête dans SAP HANA et entraîner des performances et des délais d’expiration des requêtes médiocres.

Présentation de SAP HANA comme source relationnelle

Il est utile de commencer par clarifier le comportement d’une source relationnelle, telle que SQL Server, lorsque la requête définie dans Obtenir des données ou l’éditeur Power Query effectue une agrégation. Dans l’exemple suivant, une requête définie dans l’Éditeur Power Query retourne le prix moyen par ProductID.

Diagramme montrant une requête définie dans l’Éditeur Power Query qui retourne le prix moyen par ID de produit.

Si les données ont été importées dans Power BI au lieu d’utiliser DirectQuery, la situation suivante se traduit par :

  • Les données sont importées au niveau de l’agrégation définie par la requête créée dans l’Éditeur Power Query. Par exemple, le prix moyen par produit. Ce fait entraîne une table avec les deux colonnes ProductID et AveragePrice qui peuvent être utilisées dans les visuels.
  • Dans un visuel, toute agrégation ultérieure, telle que Sum, Moyenne, Min, et d’autres, sont effectuées sur ces données importées. Par exemple, si l’on inclut AveragePrice sur un visuel, l’agrégat Sum est utilisé par défaut et retourne la somme des valeurs AveragePrice de chaque ProductID, ce qui donnerait 13,67 dans notre exemple. La même chose s’applique à toute autre fonction d’agrégation, telle que min ou moyenne, utilisée sur le visuel. Par exemple, Average de AveragePrice retourne la moyenne de 6,66, 4 et 3, soit 4,56, et non la moyenne de Price sur les six enregistrements de la table sous-jacente, qui elle est égale à 5,17.

Si DirectQuery sur cette même source relationnelle est utilisée au lieu d’Importer, la même sémantique s’applique et les résultats sont exactement les mêmes :

  • Étant donné la même requête, les mêmes données sont présentées logiquement à la couche de création de rapports, même si les données ne sont pas réellement importées.

  • Dans un visuel, toute agrégation ultérieure, telle que Somme, Moyenneet Min, est à nouveau effectuée sur cette table logique à partir de la requête. Là encore, un visuel contenant Average de AveragePrice renvoie la même valeur de 4,56.

Considérez SAP HANA lorsque la connexion est traitée comme une source relationnelle. Power BI peut utiliser les vues analytiques et les vues de calcul dans SAP HANA, qui peuvent contenir des mesures. Pourtant, aujourd’hui, l’approche de SAP HANA suit les mêmes principes que décrits précédemment dans cette section : la requête définie dans Obtenir des données ou l’éditeur Power Query détermine les données disponibles, puis toute agrégation ultérieure dans un visuel est sur ces données, et la même s’applique à la fois à l’importation et à DirectQuery. Toutefois, étant donné la nature de SAP HANA, la requête définie dans la boîte de dialogue initiale Obtenir des données ou Éditeur Power Query est toujours une requête d’agrégation et inclut généralement des mesures où les agrégations réelles utilisées sont définies par la vue SAP HANA.

L’équivalent de l’exemple précédent de SQL Server est qu’il existe une vue SAP HANA contenant ID, ProductID, DepotID, et des mesures incluant PrixMoyen, définies dans la vue comme Moyenne du Prix.

Si, dans la boîte de dialogue Obtenir des données, les sélections effectuées l’ont été pour ProductID et la mesure AveragePrice, cela définit une requête sur la vue nécessitant ces données d’agrégation. Dans l’exemple précédent, par souci de simplicité, pseudo-SQL est utilisé qui ne correspond pas à la syntaxe exacte de SAP HANA SQL. Ensuite, toutes les autres agrégations définies dans un visuel permettent d’agréger davantage les résultats d’une telle requête. Là encore, comme décrit précédemment pour SQL Server, ce résultat s’applique à la fois pour le cas Import et DirectQuery. Dans le cas de DirectQuery, la requête issue de Obtenir des données ou de l’éditeur Power Query est utilisée dans une sous-sélection au sein d'une seule requête envoyée à SAP HANA, et par conséquent, il n'est pas nécessaire de lire toutes les données avant de procéder à des agrégations supplémentaires.

Toutes ces considérations et comportements nécessitent les considérations importantes suivantes lors de l’utilisation de DirectQuery sur SAP HANA comme source relationnelle :

  • L’attention doit être portée à toute agrégation supplémentaire réalisée dans les visuels, chaque fois que la mesure dans SAP HANA est non-additive, par exemple, pas une simple Sommation, Minimumou Maximum.

  • Dans Obtenir des données ou l’éditeur Power Query, seules les colonnes requises doivent être incluses pour récupérer les données nécessaires, reflétant le fait que le résultat est une requête qui doit être une requête raisonnable qui peut être envoyée à SAP HANA. Par exemple, si des dizaines de colonnes ont été sélectionnées, dans l'idée qu'on pourrait en avoir besoin pour les visuels suivants, alors même pour DirectQuery, dans le cas d'un visuel simple, la requête d’agrégation utilisée dans la sous-sélection contient ces dizaines de colonnes, ce qui fonctionne généralement mal et peut subir des expirations.

Dans l’exemple suivant, la sélection de cinq colonnes (CalendarQuarter, color, LastName, ProductLine, SalesOrderNumber) dans la boîte de dialogue Obtenir des données, ainsi que la mesure OrderQuantity, signifie que la création ultérieure d’un visuel simple contenant le Min OrderQuantity entraîne la requête SQL suivante sur SAP HANA. La partie ombrée correspond à la sous-sélection, qui contient la requête provenant de la boîte de dialogue Obtenir des données / Éditeur Power Query. Si cette sous-sélection donne un résultat de cardinalité élevé, les performances SAP HANA résultantes sont susceptibles d’être médiocres ou de rencontrer des délais d’expiration. L’impact sur les performances n’est pas causé par la demande de tous les champs de la sous-sélection par Power BI, car la plupart de ces champs seront éliminés par la requête externe. Au lieu de cela, l’impact est dû aux mesures de la sous-sélection qui l’obligent à se matérialiser sur le serveur HANA.

Capture d’écran d’un exemple de requête montrant la requête SQL sur SAP HANA.

En raison de ce comportement, nous vous recommandons d’utiliser les éléments sélectionnés dans Obtenir des données ou l’éditeur Power Query pour les éléments nécessaires, tout en entraînant une requête raisonnable pour SAP HANA. Si possible, envisagez de recréer toutes les mesures requises dans le modèle sémantique et d’utiliser SAP HANA plus comme une source relationnelle traditionnelle.

Meilleures pratiques

Pour que les deux méthodes se connectent à SAP HANA, suivez les recommandations générales relatives à l’utilisation de DirectQuery, en particulier les recommandations relatives à l’amélioration des performances des requêtes. Pour plus d'informations, consultez sur l'utilisation de DirectQuery dans Power BI.

Considérations et limitations

La liste suivante décrit toutes les fonctionnalités SAP HANA qui ne sont pas entièrement prises en charge ou qui se comportent différemment lors de l’utilisation de Power BI.

  • Hiérarchies de type parent-enfant : les hiérarchies de type parent-enfant ne sont pas visibles dans Power BI. Cela est dû au fait que Power BI accède à SAP HANA à l’aide de l’interface SQL et que les hiérarchies enfants parentes ne peuvent pas être entièrement accessibles à l’aide de SQL.
  • Autres métadonnées de hiérarchie : La structure de base des hiérarchies s’affiche dans Power BI, mais certaines métadonnées de hiérarchie, telles que le contrôle du comportement des hiérarchies en panne, n’ont aucun effet. Là encore, cela est dû aux limitations imposées par l’interface SQL.
  • Connexion à l’aide de SSL : Vous pouvez vous connecter à l’aide de l'importation et de la connexion multidimensionnelle avec TLS, mais vous ne pouvez pas vous connecter aux instances SAP HANA configurées pour utiliser TLS avec la méthode de connexion relationnelle.
  • Prise en charge des vues d’attribut : Power BI peut se connecter aux vues d’analyse et de calcul, mais ne peut pas se connecter directement aux vues d’attribut.
  • Prise en charge des objets Catalogue : Power BI ne peut pas se connecter à des objets Catalogue.
  • Modifier les variables après la publication : Vous ne pouvez pas modifier les valeurs des variables SAP HANA directement dans le service Power BI, une fois le rapport publié.

Problèmes connus

La liste suivante décrit tous les problèmes connus lors de la connexion à SAP HANA (DirectQuery) à l’aide de Power BI.

  • Problème SAP HANA en cas de requête sur des compteurs et d’autres mesures : SAP HANA retourne des données incorrectes si une connexion est établie à une vue d’analyse, et qu’une mesure de type compteur et d’autres mesures de taux sont incluses dans le même visuel. Ce problème est abordé par note SAP 2128928 (résultats inattendus lors de l’interrogation d’une colonne calculée et d’un compteur). La mesure de ratio est incorrecte dans ce cas.

  • plusieurs colonnes Power BI à partir d’une seule colonne SAP HANA : Pour certaines vues de calcul, où une colonne SAP HANA est utilisée dans plusieurs hiérarchies, SAP HANA expose la colonne sous la forme de deux attributs distincts. Cette approche entraîne la création de deux colonnes dans Power BI. Ces colonnes sont masquées par défaut et toutes les requêtes impliquant les hiérarchies, ou les colonnes directement, se comportent correctement.

Contenu connexe

Pour plus d’informations sur DirectQuery, consultez les ressources suivantes :