Utilisation de DirectQuery pour jeux de données Power BI et Azure Analysis Services (préversion)

Avec DirectQuery pour les jeux de données Power BI et Azure Analysis Services (AAS) , vous pouvez utiliser DirectQuery pour vous connecter à des jeux de données AAS ou Power BI et, si vous le souhaitez, le combiner avec d’autres données DirectQuery et données importées. Les auteurs de rapports qui souhaitent combiner les données de leur modèle sémantique d’entreprise avec d’autres données qu’ils possèdent, comme une feuille de calcul Excel, ou qui souhaitent personnaliser ou enrichir les métadonnées de leur modèle sémantique d’entreprise, trouveront cette fonctionnalité particulièrement utile.

Activer la fonctionnalité de préversion

Étant donné que la fonctionnalité est actuellement en préversion, vous devez d’abord l’activer. Pour ce faire, dans Power BI Desktop, sélectionnez Fichier > Options et paramètres > Options, puis dans la section Fonctionnalités en préversion, cochez la case DirectQuery pour jeux de données Power BI et Analysis Services pour activer cette fonctionnalité en préversion. Vous devrez peut-être redémarrer Power BI Desktop pour que les modifications entrent en vigueur.

Utilisation de DirectQuery pour les connexions actives

L’utilisation de DirectQuery pour les jeux de données Power BI et Azure Analysis Services nécessite que votre rapport comporte un modèle local. Vous pouvez démarrer à partir d’une connexion active et ajouter un modèle local (ou le mettre à niveau), ou démarrer avec une connexion DirectQuery ou des données importées, ce qui crée automatiquement un modèle local dans votre rapport.

Pour voir quelles connexions sont utilisées dans votre modèle, consultez la barre d’état dans le coin inférieur droit de Power BI Desktop. Si vous êtes connecté uniquement à une source Azure Analysis Services, un message semblable à l’image suivante s’affiche :

Connexion uniquement à Azure Analysis Services

Si vous êtes connecté à un jeu de données Power BI, un message s’affiche vous indiquant le jeu de données Power BI auquel vous êtes connecté :

Connexion au jeu de données Power BI

Si vous souhaitez personnaliser les métadonnées des champs dans votre jeu de données connecté en temps réel, sélectionnez Make changes to this model (Apporter des modifications à ce modèle) dans la barre d’état. Vous pouvez également cliquer sur le bouton Make changes to this model (Apporter des modifications à ce modèle) dans le ruban, comme illustré dans l’image suivante. Dans la vue Rapport, le bouton Make changes to this model (Apporter des modifications à ce modèle) se trouve dans l’onglet Modélisation. Dans la vue Modèle, le bouton se trouve dans l’onglet Accueil.

Bouton Make changes to this model (Apporter des modifications à ce modèle)

La sélection du bouton affiche une boîte de dialogue confirmant l’ajout d’un modèle local. Sélectionnez Ajouter un modèle local pour permettre la création de nouvelles colonnes ou la modification des métadonnées, pour les champs de jeux de données Power BI ou Azure Analysis Services. L’image suivante montre la boîte de dialogue qui s’affiche.

Boîte de dialogue Créer un modèle local

Quand vous êtes connecté en temps réel à une source Analysis Services, aucun modèle local n’est disponible. Afin d’utiliser DirectQuery pour des sources connectées en temps réel, par exemple des jeux de données Power BI et Azure Analysis Services, vous devez ajouter un modèle local à votre rapport. Lorsque vous publiez un rapport avec un modèle local dans le service Power BI, un jeu de données pour ce modèle local est également publié.

Chaînage

Les jeux de données, ainsi que les jeux de données et les modèles sur lesquels ils sont basés, forment une chaîne . Ce processus, appelé chaînage, vous permet de publier un rapport et un jeu de données basé sur d’autres jeux de données Power BI, une caractéristique qui n’était pas possible auparavant.

Par exemple, imaginez que votre collègue publie un jeu de données Power BI appelé Ventes et budget basé sur un modèle Azure Analysis Services appelé Ventes, et l’associe à une feuille Excel appelée Budget.

Lorsque vous publiez un nouveau rapport (et un jeu de données) appelé Ventes et budget Europe basé sur le jeu de données Power BI Ventes et budget publié par votre collègue, en y apportant des modifications ou en y ajoutant des extensions, vous ajoutez en fait un rapport et un jeu de données à une chaîne de 3 éléments, qui commence par le modèle Azure Analysis Services Ventes et se termine par votre jeu de données Power BI Ventes et budget Europe. L’image suivante illustre ce processus de chaînage.

Processus de chaînage de jeux de données

La chaîne de l’image précédente se compose de trois éléments, ce qui correspond à la longueur maximale pendant cette période de préversion. L’extension d’une chaîne au-delà de trois éléments n’est pas prise en charge et génère des erreurs.

Avertissement de sécurité

L’utilisation de la fonctionnalité DirectQuery pour les jeux de données Power BI et Azure Analysis Services (AAS) affiche une boîte de dialogue d’avertissement de sécurité, comme le montre l’image suivante.

Avertissement de sécurité

Les données peuvent être envoyées d’une source de données vers une autre, ce qui génère le même avertissement de sécurité pour combiner DirectQuery et importer des sources dans un modèle de données. Pour en savoir plus sur ce comportement, consultez Utilisation de modèles composites dans Power BI Desktop.

Fonctionnalités et scénarios à essayer

La liste suivante fournit des suggestions sur la façon dont vous pouvez explorer DirectQuery pour les jeux de données Power BI et Azure Analysis Services (AAS) pour votre cas personnel :

  • Connexion à des données de différentes sources : Importer (par exemple des fichiers), jeux de données Power BI, Azure Analysis Services
  • Création de relations entre différentes sources de données
  • Écriture de mesures qui utilisent des champs de différentes sources de données
  • Création de nouvelles colonnes pour des tables de jeux de données Power BI d’Azure Analysis Services
  • Création de visuels utilisant des colonnes de différentes sources de données

À compter de la version d’avril 2021 de Power BI Desktop, vous pouvez également vous connecter à une perspective quand vous établissez une connexion DirectQuery à un modèle Azure Analysis Services, si une perspective est disponible.

À partir de la version d’octobre 2021 de Power BI Desktop, vous avez davantage de contrôle sur vos connexions :

  • Vous pouvez supprimer une table de votre modèle à partir de la liste des champs. Cela vous aide à conserver les modèles aussi concis que possible (si vous vous connectez à une perspective, vous ne pouvez pas supprimer les tables du modèle)
  • Vous pouvez choisir les tables à charger, plutôt que de charger toutes les tables, lorsque vous avez uniquement besoin d’un sous-ensemble spécifique de tables
  • Vous pouvez spécifier les tables qui devront être ensuite ajoutées au jeu de données après l’établissement de la connexion dans votre modèle
  • Avec la version d’octobre 2021, les performances ont été améliorées par l’exécution parallèle des requêtes de modèle et la mise en cache intelligente

Considérations et limitations

Il existe quelques points à prendre en compte lorsque vous utilisez DirectQuery pour les jeux de données Power BI et Azure Analysis Services (AAS)  :

  • Si vous actualisez vos sources de données et que des erreurs apparaissent au niveau des noms de champs ou de tables en conflit, Power BI résout les erreurs pour vous.

  • Les utilisateurs ont besoin d’autorisations « Générer » sur tous les jeux de données de la chaîne pour accéder à un rapport utilisant cette fonctionnalité.

  • Pour générer des rapports dans le service Power BI sur un modèle composite basé sur un autre jeu de données, toutes les informations d’identification doivent être définies. Dans la page d’actualisation des paramètres des informations d’identification, pour les sources Azure Analysis Services, l’erreur suivante s’affiche, même si les informations d’identification ont été définies :

    Avertissement relatif à de fausses informations d’identification

  • Comme ce message est confus et incorrect, nous nous en occuperons très prochainement.

  • Pour pouvoir établir une connexion DirectQuery à un jeu de données Power BI, votre locataire doit avoir l’option « Autoriser les points de terminaison XMLA et l’analyse dans Excel avec les jeux de données locaux » activée.

  • Pour les capacités Premium, le « point de terminaison XMLA » doit être défini sur « Lecture seule » ou « Lecture/écriture ».

  • Si vous utilisez un espace de travail classique avec cette fonctionnalité, la définition d’autorisations sur le jeu de données lui-même n’est pas suffisante. Pour les espaces de travail classiques, tous les utilisateurs qui accèdent aux rapports utilisant cette fonctionnalité doivent être membres de l’espace de travail. Mettez à niveau les espaces de travail classiques vers les nouveaux espaces de travail pour éviter cette situation.

  • Des règles RLS seront appliquées à la source sur laquelle elles sont définies, mais elles ne seront pas appliquées à d’autres jeux de données du modèle. Les règles RLS définies dans le rapport ne seront pas appliquées aux sources distantes, et celles définies sur des sources distantes ne seront pas appliquées à d’autres sources de données.

  • Les dossiers d’affichage, les indicateurs de performance clés, les tables de dates, la sécurité au niveau des lignes et les traductions ne seront pas importés à partir de la source dans cette préversion. Vous pouvez néanmoins créer des dossiers d’affichage dans le modèle local.

  • Vous risquez de constater un comportement inattendu lors de l’utilisation d’une hiérarchie de dates. Pour résoudre ce problème, utilisez plutôt une colonne de date. Après avoir ajouté une hiérarchie de dates à un visuel, vous pouvez basculer vers une colonne de date en cliquant sur la flèche vers le bas dans le nom du champ, puis en cliquant sur le nom de ce champ au lieu d’utiliser Hiérarchie de dates :

    Comportement inattendu de la hiérarchie de dates

    Pour plus d’informations sur l’utilisation de colonnes de date par rapport à des hiérarchies de dates, consultez cet article.

  • Des messages d’erreur inutiles peuvent s’afficher lorsque vous utilisez des fonctionnalités IA avec un modèle qui établit une connexion DirectQuery à Azure Analysis Services.

  • Utiliser ALLSELECTED avec une source DirectQuery entraîne des résultats incomplets.

  • Filtres et relations :

    • Un filtre appliqué d’une source de données à une table d’une autre source DirectQuery ne peut être défini que sur une seule colonne

    • Le filtrage croisé de deux tables dans une source DirectQuery en les filtrant avec une table en dehors de la source n’est pas une méthode recommandée et n’est pas prise en charge.

    • Un filtre ne peut s’appliquer qu’une seule fois à une table. L’application à deux reprises du même filtre à une table par le biais d’une ou de plusieurs tables situées en dehors de la source DirectQuery, n’est pas prise en charge.

  • Pendant la préversion, la longueur maximale d’une chaîne de modèles est de trois éléments. L’extension de la chaîne au-delà de trois éléments n’est pas prise en charge et génère des erreurs.

  • Un indicateur de type décourager le chaînage peut être défini sur un modèle pour empêcher la création ou l’extension d’une chaîne. Pour plus d’informations, consultez Gérer les connexions DirectQuery à un jeu de données publié.

  • Comme pour toutes les connexions DirectQuery, la connexion à un jeu de données Power BI n’est pas montrée dans Power Query.

Il existe également quelques limitations dont vous devez tenir compte :

  • Les paramètres pour les noms de base de données et de serveur sont actuellement désactivés.

  • La définition de la sécurité au niveau des tables (RLS) d’une source distante n’est pas prise en charge.

  • L’utilisation d’une des sources suivantes comme source DirectQuery n’est pas prise en charge :

  • L’utilisation de DirectQuery sur des jeux de données à partir de « Mon espace de travail » n’est pas prise en charge actuellement.

  • L’utilisation de Power BI Embedded avec des jeux de données qui incluent une connexion DirectQuery à des jeux de données Power BI ou un modèle Azure Analysis Services n’est pas prise en charge actuellement.

  • Les groupes de calcul sur des sources distantes ne sont pas pris en charge, avec des résultats de requête non définis.

  • Les tables calculées ne sont pas prises en charge dans le service qui utilise cette fonctionnalité.

  • Le tri par colonne n’est pas pris en charge à ce stade.

  • L’actualisation automatique de la page (APR) est prise en charge uniquement pour certains scénarios, en fonction du type de source de données. Pour plus d’informations, consultez l’article Actualisation automatique des pages dans Power BI.

  • La prise en charge d’un jeu de données qui utilise la fonctionnalité DirectQuery sur d’autres jeux de données n’est actuellement pas prise en charge.

  • Comme pour toute source de données DirectQuery, les hiérarchies définies dans un modèle Azure Analysis Services ou un jeu de données Power BI ne s’affichent pas lors de la connexion au modèle ou au jeu de données en mode DirectQuery à l’aide d’Excel.

Considérations relatives aux locataires

Tout modèle avec une connexion DirectQuery à un jeu de données Power BI ou à Azure Analysis Services doit être publié dans le même locataire, ce qui est particulièrement important en cas d’accès à un jeu de données Power BI ou à un modèle Azure Analysis Services avec des identités d’invité B2B, comme illustré dans le diagramme suivant. Consultez Utilisateurs invités pouvant modifier et gérer du contenu pour rechercher l’URL de locataire en vue de la publication.

Observez le diagramme suivant. Les étapes numérotées dans le diagramme sont décrites dans les paragraphes qui suivent.

Diagramme d’absence de connexion entre les locataires

Dans le diagramme, Ash utilise Contoso et accède aux données fournies par Fabrikam. Avec Power BI Desktop, Ash crée une connexion DirectQuery à un modèle Azure Analysis Services hébergé dans le locataire de Fabrikam.

Pour s’authentifier, Ash utilise une identité d’utilisateur invité B2B (étape 1 dans le diagramme).

Si le rapport est publié sur le service Power BI de Contoso (étape 2), le jeu de données publié dans le locataire Contoso ne peut pas s’authentifier avec succès auprès du modèle Azure Analysis Services de Fabrikam (étape 3). Le rapport ne fonctionne donc pas.

Dans ce scénario, le modèle Azure Analysis Services utilisé étant hébergé dans le locataire de Fabrikam, le rapport doit également être publié dans ce locataire. Une fois la publication effectuée dans le locataire de Fabrikam (étape 4), le jeu de données peut accéder au modèle Azure Analysis Services (étape 5) et le rapport fonctionne correctement.

Modèles composites avec connexion DirectQuery à des modèles sources protégés par une sécurité au niveau des objets

Lorsqu’un modèle composite obtient des données d’un jeu de données Power BI ou d’Azure Analysis Services via DirectQuery, et que ce modèle source est sécurisé par une sécurité au niveau des objets, les consommateurs du modèle composite peuvent remarquer des résultats inattendus. La section suivante explique comment ces résultats peuvent être obtenus.

La sécurité au niveau des objets (OLS) permet aux créateurs de modèles de masquer les objets qui composent le schéma de modèle (à savoir, les tables, colonnes, métadonnées, etc.) pour les consommateurs de modèles (par exemple, un générateur de rapports ou l’auteur d’un modèle composite). Lors de la configuration d’OLS pour un objet, l’auteur du modèle crée un rôle, puis supprime l’accès à l’objet pour les utilisateurs disposant de ce rôle. Du point de vue de ces utilisateurs, l’objet masqué n’existe tout simplement pas.

OLS est défini pour le modèle source et s’applique à celui-ci. Il ne peut pas être défini pour un modèle composite basé sur le modèle source.

Lorsqu’un modèle composite est créé sur un jeu de données Power BI protégé par OLS ou un modèle Azure Analysis Services via une connexion DirectQuery, le schéma de modèle du modèle source est copié dans le modèle composite. Ce qui est copié dépend de ce que l’auteur du modèle composite est autorisé à voir dans le modèle source conformément aux règles d’OLS qui s’y appliquent. Les données elles-mêmes ne sont pas copiées dans le modèle composite. Elles sont toujours récupérées via DirectQuery à partir du modèle source si nécessaire. En d’autres termes, l’extraction de données renvoie toujours au modèle source, où les règles d’OLS s’appliquent.

Étant donné que le modèle composite n’est pas sécurisé par les règles d’OLS, les objets que les consommateurs du modèle composite voient sont ceux que l’auteur du modèle composite peut voir dans le modèle source plutôt que ceux auxquels ils peuvent avoir accès. Cela peut entraîner les situations suivantes

  • Une personne qui consulte le modèle composite peut voir les objets qui sont masqués dans le modèle source par OLS.
  • À l’inverse, il est possible qu’elle ne voie PAS un objet dans le modèle composite qu’elle PEUT voir dans le modèle source, car cet objet a été masqué par les règles d’OLS qui contrôlent l’accès au modèle source.

Un point important est que, malgré le cas décrit dans la première puce, les consommateurs du modèle composite ne verront jamais les données réelles qu’ils ne sont pas censés voir, car les données ne se trouvent pas dans le modèle composite. Au lieu de cela, grâce à DirectQuery, ce qui est nécessaire est récupéré dans le jeu de données source, où OLS bloque l’accès non autorisé.

En sachant cela, prenez en considération le scénario suivant.

Diagramme montrant ce qui se passe lorsqu’un modèle composite se connecte à un modèle source protégé par une sécurité au niveau des objets via DirectQuery.

  1. Admin_user a publié un modèle sémantique d’entreprise à l’aide d’un jeu de données Power BI ou d’un modèle Azure Analysis Services qui contient une table Customer et une table Territory. Admin_user publie le jeu de données dans le service Power BI et définit des règles d’OLS ayant les effets suivants :

    • Les utilisateurs du service financier ne peuvent pas voir la table Customer
    • Les utilisateurs du service marketing ne peuvent pas voir la table Territory
  2. Finance_user publie un jeu de données nommé « Finance dataset » et un rapport nommé « Finance report » qui se connecte via DirectQuery au modèle sémantique d’entreprise publié à l’étape 1. Le rapport financier comprend un visuel qui utilise une colonne de la table Territory.

  3. Marketing_user ouvre le rapport financier. Le visuel qui utilise la table Territory s’affiche, mais retourne une erreur, car lorsque le rapport est ouvert, DirectQuery essaie de récupérer les données du modèle source à l’aide des informations d’identification de Marketing_user, qui ne peut pas voir la table Territory conformément aux règles d’OLS définies sur le modèle sémantique d’entreprise.

  4. Marketing_user crée un rapport nommé « Marketing report » qui utilise le jeu de données Finance comme source. La liste des champs affiche les tables et les colonnes auxquelles Finance_user a accès. La table Territory apparaît donc dans la liste des champs, mais pas la table Customer. Toutefois, lorsque Marketing_user tente de créer un visuel qui utilise une colonne de la table Territory, une erreur est retournée, car à ce stade, DirectQuery essaie de récupérer des données du modèle source à l’aide des informations d’identification de Marketing_user, et les règles d’OLS s’appliquent à nouveau et bloquent l’accès. La même chose se produit lorsque Marketing_user crée un jeu de données et un rapport qui se connecte au jeu de données Finance avec une connexion DirectQuery. Il voit la table Territory dans la liste des champs, car c’est ce que Finance_user peut voir, mais lorsqu’il essaie de créer un visuel qui utilise cette table, il est bloqué par les règles d’OLS sur le modèle sémantique d’entreprise.

  5. Supposons à présent que Admin_user met à jour les règles d’OLS sur le modèle sémantique d’entreprise pour empêcher le service financier de voir la table Territory.

  6. Les règles d’OLS mises à jour sont reflétées uniquement lorsque le jeu de données Finance est actualisé. Ainsi, lorsque Finance_user actualise le jeu de données Finance, la table Territory n’apparaît plus dans la liste des champs, et le visuel dans le rapport financier qui utilise une colonne de la table Territory retourne une erreur pour Finance_user, car il n’est désormais plus autorisé à accéder à la table Territory.

Pour résumer :

  • Les consommateurs d’un modèle composite voient les résultats des règles d’OLS qui s’appliquaient à l’auteur du modèle composite lors de la création du modèle. Ainsi, lorsqu’un nouveau rapport est créé sur la base du modèle composite, la liste des champs affiche les tables auxquelles l’auteur du modèle composite avait accès lors de la création du modèle, indépendamment de ce à quoi l’utilisateur actuel a accès dans le modèle source.
  • Les règles d’OLS ne peuvent pas être définies sur le modèle composite lui-même.
  • Le consommateur d’un modèle composite ne verra jamais les données réelles qu’il n’est pas censé voir, car les règles d’OLS pertinentes sur le modèle source les bloquent lorsque DIrectQuery essaie de récupérer les données à l’aide de leurs informations d’identification.
  • Si le modèle source met à jour ses règles d’OLS, ces modifications n’affectent que le modèle composite lorsqu’il est actualisé.

Étapes suivantes

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