Contenidos
Jusqu'à récemment, vous n'aviez pas passé beaucoup de temps à créer des solutions de reporting Power BI qui SharePoint Online en tant que source de données (Cet article fait spécifiquement référence à SharePoint Online, mais je suis sûr que l'expérience est la même avec SharePoint en local.) Depuis un mois, je travaille avec certains clients utilisant SharePoint pour stocker des fichiers source dans des bibliothèques de documents. À première vue, il semble être une excellente idée d'exploiter SharePoint comme emplacement de stockage pour les fichiers CSV et Excel.
- Tout le monde a un accès facile aux fichiers pour l'édition et le stockage.
- SharePoint gère le contrôle de version, l'archivage, l'extraction, etc.
- SharePoint peut faciliter l'édition partagée des fichiers
- Vous pouvez créer un rapport Power BI qui sera mis à jour en ligne sans avoir besoin d'installer une passerelle.
Malheureusement, malgré les avantages, l'expérience n'est pas géniale. Les performances de Power BI avec SharePoint comme source de données sont tout simplement terribles. En fin de compte, les problèmes se résument à la performance dans 2 domaines.
Problème 1: vitesse de mise à jour
Tout d'abord, il y a les performances de mise à jour. SharePoint possède une API OData qui n'est pas très puissante (en fait, il en va de même pour la plupart des API OData). Lorsque vous essayez de mettre à jour dans SharePoint, vous constaterez que la mise à jour sera lente. Cela ne veut pas dire que cela ne fonctionne pas, car la mise à jour se produit en arrière-plan, après tout. Dans mon expérience pratique et de test, les performances de mise à niveau de SharePoint diminuent rapidement dès que vous créez une série de sous-dossiers dans une bibliothèque de documents. En d'autres termes, si vous avez vos fichiers dans le dossier principal de votre bibliothèque de documents, les performances ne sont pas si mauvaises, mais dès que vous créez des branches de sous-dossiers, les performances chutent rapidement. Un classeur Power BI avec plusieurs sources semble prendre 4 à 5 fois plus de temps à mettre à jour que le même classeur pointant vers un serveur de fichiers.
Problème 2: Vitesse d'édition / maintenance des requêtes
Ce deuxième problème est beaucoup plus important que le premier. Lorsque vous avez de nombreuses connexions SharePoint dans votre fichier PBIX, l'expérience d'édition des requêtes est malheureuse. Power Query propose quelques astuces pour améliorer l'expérience, telles que la conservation d'une copie en cache des données à des fins de prévisualisation. Malgré cela, j'ai constaté que la modification des requêtes connectées à SharePoint est si lent c'est littéralement irréalisable par rapport au travail avec des fichiers locaux sur votre PC.
En fait, il existe un paramètre dans Power Query que vous pouvez modifier et qui peut améliorer un peu la situation.
Accédez aux options de fichier et aux options de paramètres
Accédez au téléchargement des données du fichier actuel (1 ci-dessous) et désactivez les données d'arrière-plan (2 ci-dessous).
Cela vaut vraiment la peine, mais d'après mon expérience, cela n'a pas résolu le problème de performances de SharePoint. J'ai perdu tellement de temps à essayer de créer des requêtes avec des connexions SharePoint que je devais juste trouver un autre moyen.
Synchronisez plutôt les fichiers locaux
La meilleure alternative à laquelle je puisse penser est de synchroniser les fichiers SharePoint sur un serveur de fichiers à l'aide de OneDrive.
- Utilisez OneDrive pour synchroniser une copie de vos fichiers SharePoint sur un serveur de fichiers accessible via une passerelle. Il peut s'agir du même serveur que celui utilisé pour votre passerelle ou d'un serveur de fichiers sur le réseau.
- OneDrive conserve une copie locale sur le serveur de fichiers en synchronisation avec SharePoint.
- Téléchargez des fichiers à partir d'un PC local au lieu de SharePoint.
C'est la meilleure option, mais elle comporte de nouveaux problèmes.
- L'un des avantages du stockage de vos fichiers dans SharePoint Online est que vous n'avez pas besoin d'une passerelle. Si vous adoptez cette approche, vous devrez peut-être organiser une installation de passerelle.
- Si vous répliquez les fichiers sur la machine de la passerelle, vous devrez probablement avoir un emplacement de fichier différent sur votre PC pour le développement, puis modifier le chemin du fichier lorsque vous le déployez.
- Troisièmement, il existe un problème (sinon un bogue) où vous ne pouvez pas connecter Power Query au dossier racine d'un dossier OneDrive synchronisé à partir de SharePoint.
par exemple, si vous synchronisez SharePoint avec votre PC en tant que
C: Utilisateurs R Marketing R Marketing Pty Ltd R Marketing Pty Ltd Team Site - Documents
vous pouvez connecter Power Query à
C: Utilisateurs R Marketing R Marketing Pty Ltd R Marketing Pty Ltd Team Site - Documents Sous-dossier
mais vous ne pouvez pas vous connecter à
C: Utilisateurs R Marketing R Marketing Pty Ltd R Marketing Pty Ltd Team Site - Documents
Gardez cela à l'esprit: j'ai perdu environ une heure à essayer de comprendre pourquoi cela ne fonctionnait pas.
Remarque également: si les fichiers doivent être stockés sur un serveur de fichiers, vous devez utiliser le chemin d'accès réseau complet aux fichiers, et non la version du lecteur mappé. Par exemple, quelque chose comme \ file server nom de dossier de service au lieu de n: nom de dossier de service
Il y a une autre façon
Il existe une autre façon de résoudre le problème de SharePoint. C'est un sujet plus large et je le couvrirai la semaine prochaine. Pour l'instant, je voulais juste vous assurer que "ce n'est pas seulement vous".
