Gateway Power BI kezako ? Vous passez du temps à créer votre rapport Power BI et à vous connecter à des données locales comme des fichiers Excel, CSV, TXT, sur votre machine ou un serveur physique. Une fois finalisé, vous décidez de le publier sur le service et d’en planifier l’actualisation. Tout semble bien se passer… jusqu’à ce que vous réalisiez que Microsoft ne le permet pas ! Reprenons depuis le début pour comprendre pourquoi.
Comment se connecte-t-on à des données dans Power BI ?
Lorsque vous connectez vos données via Power Query dans Power BI, vous accédez :
- A de la donnée locale sur votre machine et donc au sein de votre environnement de sécurité,
- A un autre environnement physique tel qu’un serveur auquel cas vous avez fourni un login et mot de passe,
- A un environnement Cloud et là aussi , login et mot de passe requis.
Cependant, lorsque vous publiez sur Power BI Service, vous publiez à l’extérieur sur les serveurs de Microsoft.
Prenons donc un exemple pour mieux comprendre :
Vous venez de prendre une location de maison pour vos vacances et vous ne vous demandez pas pourquoi le propriétaire ne vous envoie pas les clés par la poste. Vous comprenez qu’il a certainement installé une boite à clé sécurisée près du logement et qu’il vous enverra un code pour l’ouvrir au moment voulu… Bon eh bien voilà notre gateway ou passerelle de données !
Plus précisément pour les puristes ; Une On-premises data gateway.
Pour récupérer les données à chaque actualisation, votre rapport sur les serveurs de Microsoft devra passer par la gateway, récupérer l’autorisation de connexion à vos données pour pouvoir les remonter vers ses serveurs où se trouve votre rapport publié.
Pourquoi n’a-t-on pas besoin d’une gateway sur des données Cloud ?
Dans le cas d’une connexion à de la donnée hébergée sur un cloud type Sharepoint, One Drive, serveur cloud ou autres, le connecteur Power Query concerné vous demande de vous authentifier avec le login et mot de passe d’accès au service cloud. Se faisant, il les garde en mémoire lui permettant ainsi une connexion Cloud à Cloud sans besoin de passerelle.
Pour résumer, si votre donnée est hébergée en local, vous aurez besoin d’une gateway Power BI.
Si elle est hébergée en cloud, vous n’en aurez pas besoin.
A noter : Pour optimiser au maximum les performances de la gateway, installez-la à proximité immédiate de vos données.
Les types de gateway avec Power BI
A ce jour, nous noterons 3 types de gateway :
- En mode personnel : Permet à un seul utilisateur de s’y connecter pour un accès à des sources multiples et locales (On-premise)
- En mode standard : Permet à plusieurs utilisateurs de s’y connecter pour un accès également multi-sources
- En réseau virtuel : Plusieurs utilisateurs , plusieurs sources mais cette fois-ci en réseau virtuel
Ce qui va nous intéresser dans la plupart des cas, c’est la gateway en mode standard sur laquelle vous et/ou des collègues pourront être administrateurs et y connecter un ou plusieurs rapports.
Les paramétrages de la gateway Power BI
Nous vous laissons le soin de prendre connaissance, sur Microsoft learn, des prérequis minimums de la machine ou du serveur sur lequel sera installé votre gateway.
Prenez tout de même en considération les 3 points importants que sont la mémoire, l’espace disque et la qualité du réseau internet. Ils impacteront fortement l’efficacité et les performances de votre gateway.
Evitez également d’installer votre passerelle sur une machine qui pourrait passer en veille ou être éteinte par n’importe qui.
Pour bien comprendre les points qui vont suivre, votre passerelle sera sollicitée via des ports de votre machine par différents services Microsoft. Il faudra donc surtout vous assurer avec votre service informatique que rien n’empêche cette communication au risque de faire face à des erreurs d’actualisation de vos rapports. Et il en existe un nombre considérable en fonction du type de problèmes rencontrés.
Les ports de votre gateway Power BI
La passerelle communique sur les ports sortants suivants : TCP 443, 5671, 5672 et de 9350 à 9354
Afin de s’assurer que tous les ports sont ouverts, lancez un test des ports depuis la console de la passerelle et récupérez le résultat du test
Onglet Diagnostics / Network ports test -> Start new test
En cas de port bloqué, contrôlez que votre Firewall autorise les connexions sortantes à ces ports pour votre gateway.
Les points de terminaison de votre gateway Power BI
Pour fonctionner, votre gateway est en communication avec certains services extérieurs dont on notera notamment ceux d’Azure ou de Power BI via les ports mentionnés ci-dessus.
Sur le port 443 :
*.download.microsoft.com : permet à Microsoft de valider la version et la région de la passerelle
*.analysis.windows.net : permet d’identifier le cluster Power BI approprié
*.login.windows.net, login.live.com, aadcdn.msauth.net, login.microsoftonline.com, *.microsoftonline-p.com : Utilisés pour authentifier l’application passerelle pour Microsoft Entra ID et OAuth2
*.dc.services.visualstudio.com : Utilisé par AppInsights pour collecter les données de télémétrie
Sur les ports 5671 et 5672 :
*.servicebus.windows.net : Utilisé pour AMQP (Advanced Message Queuing Protocol)
Sur les ports 443 et 9350 à 9354 :
*.servicebus.windows.net : Écoute Azure Relay sur TCP. Le port 443 est requis pour obtenir des jetons Azure Access Control
Sur le port 80 :
*.msftncsi.com : Utilisé pour tester la connectivité Internet si le service Power BI ne peut pas atteindre la passerelle.
La plupart de ces services sont relatifs à la sécurisation de la connectivité et de la transmission de vos données, mais ils ne vont pas supplanter les sécurités déjà en place sur votre machine ou votre serveur (Firewall, Antivirus locaux ou sur votre éventuel serveur DNS)
Tester l’accès aux points de terminaison de votre gateway
Pour contrôler l’accès aux différents services, vous pouvez tester les connexions via console PowerShell
Envoyer : telnet analysis.windows.net 443 sur une commande PowerShell / cmd
Si ça échoue ; message : « Could not open connection »
Ou si telnet n’est pas installé : Test-NetConnection analysis.windows.net -Port 443
Si ça échoue ; message : « TcpTestSucceeded : False »
Dans le cas où votre test échoue, il vous faudra tester la résolution DNS en tapant .\nslookup suivi du service, vous devez obtenir une adresse IP sinon votre serveur DNS bloque l’accès au service.
Si c’est le cas, tester la connection via une IP publique type Google (8.8.8.8) : .\nslookup analysis.windows.net 8.8.8.8
Si le nom apparait, c’est que ça passe et que c’est donc bien votre serveur DNS qui bloque.
Dans ce cas de figure, il faudra contacter votre SI pour autoriser les différents services au niveau du serveur de domaine.
Enfin, assurez vous tout de même que le service de la gateway elle-même est bien lancé.
Vous voilà prêt à connecter votre gateway sur le service Power BI et programmer vos actualisations de rapports!
Dans cet article, nous avons évité au maximum de vous noyer dans trop de considérations techniques. Seuls les points les plus importants y sont abordés.
Si vous voulez en savoir plus, la documentation Microsoft (Learn) est très bien détaillée et répondra très certainement à vos questions.
Sinon toute l’équipe KPI Consulting se tient également à votre écoute pour y répondre 😉