Sélectionner des fichiers avec une requête Power BI ou SQL

En cours de développement

Le Source Type Dynamic BI data query peut être choisi dans la boîte de dialogue de la tâche, et ses champs sont affichés pour que vous puissiez voir ce qui arrive. Ils ne peuvent pas encore être remplis, et une tâche utilisant cette source ne peut pas s'exécuter : elle n'est jamais validée, et n'atteint donc jamais l'état Prêt. Cette rubrique décrit la fonctionnalité telle qu'elle est en cours de conception.

À quoi sert une requête sur les données BI

L'analyse enregistre chaque fichier qu'elle trouve dans la base de données de reporting que SMART Migration tient à jour pour le rapport Power BI : son nom, son chemin, sa taille, ses dates, son nombre de versions et ses colonnes de métadonnées. Une requête sur ces données sélectionne les fichiers selon ce qu'ils sont, et non selon l'endroit où ils se trouvent :

Produire un rapport sur ces fichiers précisément

Exécutez la requête comme tâche Analyse : le rapport Power BI n'affiche alors que les fichiers correspondants, sur l'ensemble des sources.

Les migrer à nouveau

Exécutez-la comme tâche Migration pour transférer une nouvelle fois exactement les fichiers correspondants — une deuxième passe, une correction, la demande d'un responsable métier — sans créer une tâche par bibliothèque.

Une copie DORA des fichiers critiques

Dans les quelques bibliothèques dont dépend une fonction critique, marquez les documents critiques à l'aide d'une colonne de métadonnées et conservez une copie de ces seuls documents en un même endroit, actualisée chaque nuit — pour y accéder en cas d'urgence.

La requête constitue la sélection : la tâche n'a ni bibliothèque, ni partage, ni OneDrive qui lui soit propre, et chaque fichier est lu là où il se trouve.

Une copie qui suit les documents, pour DORA

Une requête n'est jamais plus à jour que les données BI qu'elle lit. Maintenez ces données à jour grâce à une analyse incrémentielle des bibliothèques dont dépend une fonction critique, et une tâche par requête réplique dynamiquement leurs documents critiques : tout ce qui correspond ce soir est copié ce soir, où que ce soit dans ces bibliothèques, sans que personne ait à modifier une tâche ou à exporter une liste.

1. Analyser les bibliothèques protégées, de façon incrémentielle

   Attribuez à chaque bibliothèque du périmètre protégé — les quelques bibliothèques qui contiennent ce dont les fonctions critiques ont besoin, jamais l'ensemble du tenant — une tâche Analyse récurrente, quotidienne, avec l'option Incrémentiel (uniquement les fichiers modifiés depuis la dernière exécution réussie) activée. Après la première analyse complète, chaque exécution ne lit que ce qui a été créé ou modifié depuis, de sorte que les données BI suivent les documents chaque nuit pour un coût bien moindre : nouveaux fichiers, nouvelles versions, métadonnées modifiées.

2. Indiquer ce qui est critique

   Marquez les documents critiques d'une manière que les données BI enregistrent : une colonne de métadonnées telle que Critical, un type de contenu, un site, un nombre de versions — ce que le métier utilise déjà.

3. Interroger les fichiers critiques

   Créez une tâche Migration récurrente avec le Source Type Dynamic BI data query et une requête qui sélectionne ces fichiers, vers l'unique emplacement prévu pour la copie. Planifiez-la après les tâches d'analyse — analyse à 01:00, copie à 03:00 — afin qu'elle lise les données actualisées pendant la nuit.

4. La copie se tient elle-même à jour

   Chaque exécution prend les fichiers qui correspondent à ce moment-là. Un document marqué critique aujourd'hui est copié ce soir ; un document critique modifié aujourd'hui est copié à nouveau ; une bibliothèque ajoutée au périmètre protégé est prise en compte dès que son analyse a été exécutée.

Ce qui se passe à la source	Ce que font les exécutions suivantes
Un document est nouvellement marqué critique	L'analyse enregistre la modification, la requête sélectionne le fichier et la copie le prend
Un document critique est modifié	L'analyse enregistre la nouvelle version, et la copie la reprend selon la règle Ajouter les nouveaux, écraser les existants si plus récents
Un document n'est plus marqué critique	La requête ne le sélectionne plus ; la copie réalisée précédemment est laissée telle quelle, car une migration ne supprime jamais rien à la destination
Une bibliothèque est ajoutée au périmètre protégé	Attribuez-lui une tâche d'analyse récurrente, et la requête l'atteint dès la nuit suivante

Réplication dynamique pour DORA

La copie est définie par ce que sont les documents, et non par l'endroit où ils se trouvent : où qu'un document critique soit créé, déplacé ou modifié, les exécutions de la nuit suivante le trouvent et le copient. L'analyse ne lit que ce qui a changé, de sorte que le cycle complet reste assez court pour être répété chaque nuit, et l'historique d'exécution enregistre chaque actualisation — les fichiers pris et la façon dont elle s'est terminée —, soit la preuve que demande un auditeur.

Une copie DORA de bibliothèques sélectionnées, et non une sauvegarde

Microsoft 365 limite les lectures lourdes et fréquentes, si bien qu'aucune tâche récurrente ne peut maintenir un tenant entier synchronisé. À titre indicatif, limitez le périmètre récurrent — tâches d'analyse et copie confondues — à moins de 20 bibliothèques de moins de 50 000 fichiers chacune, et jamais plus d'environ 50 bibliothèques au total. Ce dispositif est une copie de résilience de bibliothèques sélectionnées, à laquelle accéder en cas d'urgence. Ce n'est pas une sauvegarde de SharePoint Online, de SharePoint Server ou de partages de fichiers vers Nextcloud : la sauvegarde d'un tenant entier ou d'un serveur de fichiers relève d'un produit de sauvegarde conçu à cet effet, et le contenu situé hors du périmètre protégé est migré une seule fois ou laissé en place.

Une analyse complète de temps en temps

Une exécution incrémentielle prend ce qui a été ajouté ou modifié depuis la précédente. Pour aligner entièrement les données BI sur les sources — y compris les fichiers qui y ont été supprimés ou déplacés —, réinitialisez de temps en temps la From Date des tâches d'analyse, par exemple tous les mois, afin que l'exécution suivante soit une analyse complète.

En savoir plus : Exécutions incrémentielles : uniquement les fichiers modifiés depuis la dernière exécution · Résilience opérationnelle numérique (DORA) — sa section Choisir ce qu'il faut protéger · Estimer le volume et la durée · Planifier et mener une migration, vague par vague · Planification, récurrence et priorité

Pour un rapport ou une migration ponctuelle, une requête peut atteindre toutes les sources qu'une tâche Analyse ponctuelle a enregistrées, quel qu'en soit le nombre : il s'agit d'une passe unique, et non d'une copie maintenue synchronisée. Voir Choisir les fichiers qu'une tâche prend

Deux façons d'écrire la requête

Langage de requête	Comment l'écrire	Idéal pour
Requête DAX depuis Power BI	Filtrez un visuel du rapport Power BI sur les fichiers souhaités, enregistrez sa requête avec l'Analyseur de performances, et laissez Convertir en SQL la transformer en SQL	Les critères que vous combinez déjà en quelques clics dans Power BI : segments, filtres, mesures
Clause SQL WHERE	Écrivez vous-même les conditions, sous la forme de la clause WHERE d'un select sur les données BI — version_count > 100 AND my_column = 'abc'	Les critères que le rapport n'affiche pas, ou les conditions portant sur plusieurs colonnes

Comment SMART Migration exécute la requête

La tâche transmet à SMART Migration des conditions, et non une requête complète. Lorsqu'il prend en charge la tâche, SMART Migration reçoit la clause WHERE et l'ajoute à son propre select des fichiers sur les données BI, évalué à nouveau à chaque exécution.

• Seuls des fichiers peuvent être renvoyés. Le select, ses tables et ce qu'il renvoie appartiennent à SMART Migration ; la clause ne fait que le restreindre, de sorte qu'une requête ne peut jamais modifier des données ni lire quoi que ce soit d'autre.
• Un seul langage à l'exécution. Une requête DAX enregistrée dans Power BI est convertie en cette même clause WHERE avant l'enregistrement de la tâche, si bien que SMART Migration lit toujours des conditions SQL.
• Toujours à jour. La clause est appliquée aux données BI telles qu'elles sont au moment de l'exécution de la tâche, jamais à un instantané pris lors de son enregistrement.

Enregistrer une requête DAX dans Power BI Desktop

Power BI écrit une requête DAX pour chaque visuel qu'il affiche, et l'Analyseur de performances la montre.

1. Filtrer une table de fichiers

   Ouvrez SMART BI.pbix dans Power BI Desktop et filtrez une table de fichiers pour ne garder que ceux que vous souhaitez — par exemple VersionCount supérieur à 100, ou une colonne de métadonnées égale à abc.

2. Démarrer l'Analyseur de performances

   Dans le ruban Optimiser (ou Affichage dans les versions plus anciennes), ouvrez Analyseur de performances, cliquez sur Démarrer l'enregistrement, puis sur Actualiser les éléments visuels.

3. Copier la requête du visuel

   Développez l'entrée de la table dans le volet Analyseur de performances et cliquez sur Copier la requête.

4. La coller dans la tâche

   Dans la boîte de dialogue de la tâche, choisissez Dynamic BI data query comme Source Type et DAX query from Power BI comme Query language, collez la requête dans DAX query et cliquez sur Convertir en SQL.

Convertir en SQL avec Claude

Convertir en SQL enverra la requête DAX à Claude, avec la clé d'aide IA de l'application, et placera la clause WHERE qu'il rédige dans le champ, pour que vous la lisiez et la vérifiiez avant d'enregistrer la tâche.

• Seule la requête est envoyée — aucune donnée de tâche, d'exécution, de fichier ou de client, comme pour l'aide IA.
• Vous avez le dernier mot : la clause est affichée dans le champ, et la tâche exécute ce qui y est enregistré, et non ce que Claude a répondu.
• Sans l'aide IA, vous écrivez vous-même la clause WHERE.

En savoir plus dans Panneau d'aide et aide IA

Exemples de requêtes sur les données BI

Vous voulez	La requête sélectionne
Les fichiers ayant un long historique de versions	Les fichiers comptant plus de 100 versions
Les documents d'un projet	Les fichiers dont la colonne de métadonnées contient le code du projet
Les fichiers volumineux que personne n'a ouverts depuis des années	Les fichiers dépassant une certaine taille, modifiés pour la dernière fois avant une date
Les documents critiques pour une copie DORA	Les fichiers marqués critiques dans une colonne de métadonnées, dans les bibliothèques protégées

Une requête ou une liste de fichiers

Une tâche Liste de fichiers CSV sélectionne elle aussi des fichiers précis dans de nombreuses sources, mais à partir d'une liste figée : exportée une seule fois depuis Power BI et limitée à 30 000 lignes par exportation. Une requête est évaluée à chaque exécution de la tâche ; une tâche récurrente prend donc toujours les fichiers qui correspondent à ce moment-là, y compris les nouvelles correspondances, sans exportation intermédiaire ni limite de lignes.

Préservez l'intégralité des données BI

Une requête ne peut trouver que ce que l'Analyse a enregistré. Exécutez l'Analyse sur chaque source que la requête doit atteindre et conservez les lignes de l'Historique d'exécution : les supprimer retire leurs données des données BI que lit la requête.

Important : les chiffres du Tableau de bord ne changent qu'une fois que SMART Migration a purgé les exécutions. Actualisez le rapport lorsque l'en-tête Power BI du Tableau de bord affiche un À jour vert au lieu d'une marque rouge. Voir Historique d'exécution

Voir aussi

• Migrer une liste de fichiers depuis un fichier CSV
• Choisir les fichiers qu'une tâche prend
• Informatique décisionnelle avec Power BI
• Résilience opérationnelle numérique (DORA)