[{"content":"Vous connaissez SQL. KQL (Kusto Query Language) repose sur un principe différent : une table en entrée, puis une suite d\u0026rsquo;opérateurs chaînés par des barres verticales |, chacun transformant le résultat du précédent. Pas de SELECT ... FROM ... WHERE imbriqué, mais un flux de gauche à droite.\nCherchez ci-dessous le motif SQL que vous avez l\u0026rsquo;habitude d\u0026rsquo;écrire. Il sert pour Microsoft Fabric (KQL databases, Real-Time Intelligence), Azure Data Explorer, Microsoft Sentinel et Azure Monitor. Tapez / pour aller directement à la recherche.\n\u0026times; Tout effacer Mode entraînement Aucune correspondance. Effacer les filtres.\nLes équivalences couvrent les cas fréquents ; certaines requêtes n'ont pas de traduction directe terme à terme. KQL est sensible à la casse pour les opérateurs et les noms de colonnes. Tapez / pour la recherche, Échap pour l'effacer. Le lien de la page garde votre recherche en mémoire.\n","permalink":"https://www.techniir.com/ressources/sql-vers-kql/","summary":"Aide-mémoire interactif : cherchez le motif SQL que vous écrivez d\u0026rsquo;habitude, voyez son équivalent en KQL. Filtres par catégorie, recherche plein texte, copie en un clic.","title":"SQL vers KQL : le traducteur visuel"},{"content":" Série : Industrialiser Microsoft Fabric · article 3 sur 4 Git integration Fabric : les 5 actions Source Control Déployer Fabric via Azure DevOps et Service Principal Les DMV de Fabric Warehouse : le temps réel, et ce que SQL Server retire Query Insights dans Fabric Warehouse : six vues, et ce que leurs noms cachent Le point de départ Fabric Warehouse expose un sous-ensemble des DMV (Dynamic Management Views) héritées de SQL Server : sys.dm_exec_connections, sys.dm_exec_sessions, sys.dm_exec_requests. Elles répondent à une seule question : qu\u0026rsquo;est-ce qui tourne maintenant, et qui bloque qui. Quand on vient de SQL Server, le réflexe est de les interroger comme avant. C\u0026rsquo;est précisément là que les écarts apparaissent, et ils sont rarement documentés de façon frontale.\nCet article couvre le temps réel. L\u0026rsquo;analyse de l\u0026rsquo;historique (les vues queryinsights) fait l\u0026rsquo;objet d\u0026rsquo;un article séparé.\nRègle suivie ici : chaque affirmation est vérifiée en lab avant d\u0026rsquo;être écrite, et quand un résultat contredit l\u0026rsquo;intuition SQL Server il est signalé comme tel. Les captures proviennent d\u0026rsquo;un warehouse de test (lh_dp700_sandbox) chargé avec le jeu de données d\u0026rsquo;exemple de Fabric, en charge faible et mono-utilisateur : certaines absences observées plus bas sont des artefacts de ce contexte, pas des limites de la plateforme.\nAprès cette lecture, on saura :\nrépartir un besoin de diagnostic entre les trois DMV et leur hiérarchie ; reconnaître les fonctions SQL Server absentes de Fabric Warehouse et leurs contournements ; éviter les pièges de la colonne command et du libellé « Submitter » ; anticiper le RBAC des DMV et le modèle de concurrence, tous deux différents de SQL Server on-premises. Prérequis : un Fabric Warehouse accessible, des notions de DMV SQL Server, et l\u0026rsquo;éditeur SQL du portail Fabric (ou SSMS / Azure Data Studio connecté à l\u0026rsquo;endpoint T-SQL).\n1. DMV ou Query Insights : lequel pour quoi Repère à poser avant tout le reste : ce sont deux mécanismes complémentaires, pas deux chemins vers la même information.\nCritère DMV (cet article) Query Insights (article dédié) Nature État courant, en mémoire Historique persistant Question type \u0026ldquo;Qu\u0026rsquo;est-ce qui tourne maintenant, qui bloque qui ?\u0026rdquo; \u0026ldquo;Quelles requêtes ont été lentes cette semaine ?\u0026rdquo; Persistance Aucune. L\u0026rsquo;information disparaît avec la session Conservée dans les vues queryinsights.* (30 jours) Chercher un historique dans les DMV, ou un instantané temps réel dans Query Insights, mène à une impasse.\nÀ retenir : DMV pour diagnostiquer l\u0026rsquo;instant présent, Query Insights pour analyser une tendance.\n2. Les trois DMV et leur hiérarchie Les trois vues s\u0026rsquo;emboîtent, du réseau vers l\u0026rsquo;exécution :\nDMV Niveau Répond à sys.dm_exec_connections Réseau Comment le client s\u0026rsquo;est connecté (protocole, adresse, authentification) sys.dm_exec_sessions Session Qui est connecté, depuis quand, avec quelle application sys.dm_exec_requests Exécution Ce qui s\u0026rsquo;exécute à cet instant précis Une connexion porte une ou plusieurs sessions ; une session peut avoir une requête active à un instant donné. Commençons par sys.dm_exec_sessions seule, filtrée sur les sessions utilisateur :\nSELECT session_id, login_name, host_name, program_name, login_time FROM sys.dm_exec_sessions WHERE is_user_process = 1;La même requête, lancée à trois moments du lab, ne renvoie pas le même nombre de lignes :\nPremier passage : une seule session utilisateur active.\nQuelques minutes plus tard : trois sessions, avec des session_id et des login_time différents.\nÀ un autre moment : cinq sessions. Une DMV est un instantané, elle reflète l\u0026rsquo;état à la milliseconde près et ne conserve rien. Deux détails à noter : host_name est masqué ici volontairement, et program_name affiche DMS_user pour toutes les sessions, une valeur interne au moteur distribué de Fabric et non le nom de l\u0026rsquo;outil client. Ne pas s\u0026rsquo;y fier pour identifier la provenance d\u0026rsquo;une session.\nEn joignant les trois vues, on obtient une image complète connexion vers session vers requête :\nSELECT connections.connection_id, sessions.session_id, sessions.login_name, sessions.login_time, requests.command, requests.start_time, requests.total_elapsed_time FROM sys.dm_exec_connections AS connections INNER JOIN sys.dm_exec_sessions AS sessions ON connections.session_id = sessions.session_id INNER JOIN sys.dm_exec_requests AS requests ON requests.session_id = sessions.session_id WHERE requests.status = \u0026#39;running\u0026#39; ORDER BY requests.total_elapsed_time DESC; La jointure fonctionne sans adaptation : le modèle relationnel connexion, session, requête se comporte comme sur SQL Server classique. Attention toutefois : sys.dm_exec_connections est réservé à l\u0026rsquo;Admin du workspace (voir section 6), donc cette jointure échoue pour un rôle Member, Contributor ou Viewer.\nÀ retenir : la hiérarchie des trois DMV est identique à SQL Server. Ce sont les colonnes, pas la structure, qui réservent des surprises.\n3. Ce que SQL Server offre et que Fabric Warehouse retire sys.dm_exec_sql_text, la fonction qui restitue le texte complet d\u0026rsquo;une requête à partir d\u0026rsquo;un sql_handle, n\u0026rsquo;est pas documentée pour Fabric Warehouse : elle ne figure pas dans le périmètre d\u0026rsquo;application de la référence T-SQL (contrairement à sys.dm_exec_requests), et le guide de monitoring Fabric ne l\u0026rsquo;utilise jamais. Le schéma habituel (joindre sys.dm_exec_requests à sys.dm_exec_sql_text pour lire la requête en cours) ne s\u0026rsquo;applique pas ici.\nC\u0026rsquo;est l\u0026rsquo;une des raisons d\u0026rsquo;être de queryinsights : le texte des requêtes se récupère dans l\u0026rsquo;historique, pas dans les DMV temps réel.\nÀ retenir : pas de texte de requête en temps réel dans Fabric Warehouse. Pour lire le SQL exécuté, on passe par queryinsights.exec_requests_history.\n4. La colonne command ne contient pas la requête Dans sys.dm_exec_requests, la colonne command ne porte pas le texte SQL. Elle porte un type de commande : SELECT, INSERT, CREATE TABLE, etc. Piège classique pour qui s\u0026rsquo;attend, par habitude, à y lire la requête complète.\nDeux observations de lab sur cette même DMV :\nUn SELECT DISTINCT status FROM sys.dm_exec_requests a renvoyé trois valeurs (background, running, sleeping) sur les six documentées. Les trois autres (rollback, runnable, suspended) étaient simplement absentes faute de contention au moment du test ; suspended en particulier signale un blocage réel. À un instant donné, la vue contenait plus d\u0026rsquo;une centaine de lignes command = 'TASK MANAGER', toutes au même horodatage. Ce sont des threads de maintenance interne du moteur, probablement liés à un réveil de capacité, pas des requêtes utilisateur. Il faut les filtrer explicitement pour isoler l\u0026rsquo;activité réelle. À retenir : command en DMV = catégorie d\u0026rsquo;instruction. Et il existe un bruit interne (TASK MANAGER) à exclure de toute analyse.\n5. \u0026ldquo;Submitter\u0026rdquo; : un libellé d\u0026rsquo;interface, pas une colonne Le portail (Data Warehouse Monitor) affiche une colonne Submitter. Elle n\u0026rsquo;existe pas en T-SQL, ni dans les DMV, ni dans queryinsights. \u0026ldquo;Submitter\u0026rdquo; est un libellé d\u0026rsquo;interface ; la colonne réelle à interroger est login_name.\nÀ retenir : avant de chercher une colonne vue dans le portail, vérifier qu\u0026rsquo;elle porte le même nom côté T-SQL. Souvent non.\n6. RBAC des DMV : qui voit quoi Deux couches de permission distinctes, souvent confondues. L\u0026rsquo;écran du portail, longtemps appelé « Query Activity », s\u0026rsquo;appelle désormais Data Warehouse Monitor :\nRôle DMV en T-SQL Data Warehouse Monitor (portail) Admin Les trois DMV, toutes les sessions du workspace ; commande KILL Accès complet Member / Contributor sys.dm_exec_sessions et sys.dm_exec_requests, ses propres requêtes uniquement ; pas de sys.dm_exec_connections, pas de KILL Aucun accès, réservé aux Admins Viewer Idem Member / Contributor Aucun accès, réservé aux Admins Un Contributor peut donc interroger sys.dm_exec_requests en T-SQL pour ses propres requêtes, mais ne peut même pas ouvrir Data Warehouse Monitor dans le portail. Conséquence pratique : sys.dm_exec_connections étant réservé à l\u0026rsquo;Admin, la jointure des trois DMV de la section 2 ne fonctionne que pour un Admin.\nÀ retenir : l\u0026rsquo;accès T-SQL aux DMV est plus permissif que Data Warehouse Monitor. Deux modèles séparés.\n7. Modèle de concurrence : Snapshot imposé SET TRANSACTION ISOLATION LEVEL n\u0026rsquo;a aucun effet dans Fabric Warehouse : l\u0026rsquo;instruction est acceptée mais ignorée à l\u0026rsquo;exécution. La raison : le warehouse impose Snapshot Isolation, sans possibilité d\u0026rsquo;en changer, cohérent avec une plateforme pensée pour l\u0026rsquo;analytique concurrente plutôt que pour de l\u0026rsquo;OLTP.\nConséquences concrètes :\nun lecteur n\u0026rsquo;est pas bloqué par un écrivain non validé, contrairement au modèle pessimiste de SQL Server on-premises ; le verrouillage s\u0026rsquo;applique au niveau de la table entière, pas de la ligne. À retenir : on ne règle pas l\u0026rsquo;isolation dans Fabric Warehouse, on compose avec Snapshot et un verrouillage table-level.\n8. Un faux positif IntelliSense qui fait perdre du temps Écrire BEGIN TRANSACTION dans l\u0026rsquo;éditeur SQL du portail déclenche un soulignement rouge (\u0026ldquo;no viable alternative at input\u0026rdquo;). L\u0026rsquo;instinct est de conclure que la syntaxe est invalide. En réalité c\u0026rsquo;est un faux positif cosmétique : la commande s\u0026rsquo;exécute normalement (\u0026ldquo;1 records affected\u0026rdquo; en lab), et BEGIN TRANSACTION / COMMIT / ROLLBACK sont bien pris en charge.\nÀ retenir : l\u0026rsquo;éditeur peut se tromper avant le moteur. Tester l\u0026rsquo;exécution avant de conclure qu\u0026rsquo;une fonctionnalité manque.\n9. Ce qui reste ouvert Point testé mais pas tranché avec certitude : le comportement de @@TRANCOUNT dans un batch groupé (plusieurs instructions envoyées en une seule exécution). Renvoie-t-il toujours 1 après BEGIN TRANSACTION, ou cela dépend-il de la structure du batch ? À vérifier avec un test dédié avant d\u0026rsquo;en faire une affirmation.\nRécapitulatif anti-pièges Piège Ce qu\u0026rsquo;il faut retenir sys.dm_pdw_exec_requests Synapse dédié (PDW), pas Fabric sys.dm_exec_sql_text Hors périmètre Fabric Warehouse : passer par queryinsights.exec_requests_history command (DMV) Type de commande, pas le texte command = 'TASK MANAGER' Bruit de maintenance interne, à filtrer program_name Vaut DMS_user, valeur moteur, pas l\u0026rsquo;outil client submitter Libellé du portail, en T-SQL c\u0026rsquo;est login_name sys.dm_exec_connections Réservé à l\u0026rsquo;Admin ; la jointure des trois DMV échoue pour un non-Admin KILL Réservé à l\u0026rsquo;Admin SET TRANSACTION ISOLATION LEVEL Accepté mais ignoré à l\u0026rsquo;exécution, Snapshot Isolation imposée Data Warehouse Monitor (portail) Réservé aux Admins, contrairement aux DMV en T-SQL Pourquoi ça compte au-delà de l\u0026rsquo;examen Pour l\u0026rsquo;examen DP-700 (domaine \u0026ldquo;Monitor and optimize an analytics solution\u0026rdquo;), ces nuances séparent une réponse solide d\u0026rsquo;une intuition approximative héritée de SQL Server.\nEn production, l\u0026rsquo;enjeu est plus direct : savoir que sys.dm_exec_sql_text est absent, ou que sys.dm_exec_connections est réservé à l\u0026rsquo;Admin, évite de bâtir un diagnostic sur une fonctionnalité ou un accès qui n\u0026rsquo;existe pas pour l\u0026rsquo;identité qui l\u0026rsquo;exécutera. Mieux vaut le découvrir avant l\u0026rsquo;incident.\nEn résumé Les trois DMV de Fabric Warehouse gardent la structure de SQL Server, mais :\npas de texte de requête en temps réel (sys.dm_exec_sql_text hors périmètre) ; command est un type d\u0026rsquo;instruction, pas du SQL, et un bruit interne (TASK MANAGER) est à filtrer ; sys.dm_exec_connections et KILL sont réservés à l\u0026rsquo;Admin ; un seul modèle de concurrence, non négociable : Snapshot Isolation et verrouillage table-level. Pour l\u0026rsquo;historique et les agrégats, voir Query Insights dans Fabric Warehouse.\nSources officielles Monitor connections, sessions, and requests by using DMVs : les trois DMV de cycle de vie et leur hiérarchie ; RBAC (Admin voit tout et peut KILL ; Member, Contributor et Viewer ne voient que leurs propres sessions et requêtes et ne peuvent pas exécuter sys.dm_exec_connections). sys.dm_exec_requests (view=fabric) : la colonne command porte un type de commande ; les six valeurs de status (background, rollback, running, runnable, sleeping, suspended) ; note précisant que sys.dm_pdw_exec_requests est réservé au pool SQL dédié Synapse / PDW. sys.dm_exec_sql_text (view=fabric) : le périmètre « Applies to » ne mentionne ni Warehouse ni SQL analytics endpoint dans Fabric, contrairement à sys.dm_exec_requests. Transactions in Fabric Data Warehouse : Snapshot Isolation imposée sur toutes les transactions, changement d\u0026rsquo;isolation via T-SQL ignoré, verrouillage au niveau table, lecteurs et écrivains ne se bloquent pas mutuellement. Performance guidelines in Fabric Data Warehouse : BEGIN TRANSACTION / COMMIT / ROLLBACK pris en charge ; « Attempts to change the isolation level via T-SQL are ignored ». Monitor T-SQL queries (Data Warehouse Monitor) : l\u0026rsquo;écran (ex-« Query Activity ») est réservé aux Admins. Share your data and manage permissions et Workspace roles in Fabric Data Warehouse : permission Monitor pour interroger les DMV, et détail des rôles de workspace. ","permalink":"https://www.techniir.com/posts/dmv-fabric-warehouse-temps-reel/","summary":"Les trois DMV de cycle de vie de Fabric Warehouse ressemblent à celles de SQL Server, jusqu\u0026rsquo;au moment où on les utilise exactement pareil. Ce qui manque, ce qui trompe, et le modèle de concurrence qui change tout, vérifié en lab.","title":"Les DMV de Fabric Warehouse : le temps réel, et ce que SQL Server retire"},{"content":" Série : Industrialiser Microsoft Fabric · article 4 sur 4 Git integration Fabric : les 5 actions Source Control Déployer Fabric via Azure DevOps et Service Principal Les DMV de Fabric Warehouse : le temps réel, et ce que SQL Server retire Query Insights dans Fabric Warehouse : six vues, et ce que leurs noms cachent Le point de départ Là où les DMV répondent à « qu\u0026rsquo;est-ce qui tourne maintenant », queryinsights répond à « qu\u0026rsquo;est-ce qui s\u0026rsquo;est passé ». C\u0026rsquo;est un schéma de vues auto-générées, présent dans chaque Warehouse et chaque SQL analytics endpoint, qui conserve l\u0026rsquo;historique des requêtes terminées et quelques agrégats prêts à l\u0026rsquo;emploi.\nCet article couvre l\u0026rsquo;historique. Le temps réel (les DMV sys.dm_exec_*, le modèle de concurrence) fait l\u0026rsquo;objet d\u0026rsquo;un article séparé.\nRègle suivie ici : chaque affirmation est vérifiée en lab avant d\u0026rsquo;être écrite. Les captures proviennent d\u0026rsquo;un warehouse de test (lh_dp700_sandbox) chargé avec le jeu de données d\u0026rsquo;exemple de Fabric, en charge faible. Certaines observations (une vue vide, is_pool_under_pressure toujours à 0) sont des artefacts de ce contexte mono-utilisateur, pas des limites de la plateforme.\nAprès cette lecture, on saura :\nchoisir la bonne vue queryinsights pour un besoin donné ; lire l\u0026rsquo;agrégation par forme de requête (query_hash) sans se tromper sur ce qu\u0026rsquo;elle mesure ; éviter les pièges de nommage entre DMV et queryinsights (login_time vs session_start_time, etc.) ; savoir ce que contient réellement sql_pool_name, et combien de temps l\u0026rsquo;historique est conservé. Prérequis : un Fabric Warehouse (ou SQL analytics endpoint) avec un rôle Contributor ou supérieur, et l\u0026rsquo;éditeur SQL du portail ou un client T-SQL.\n1. Les six vues queryinsights queryinsights regroupe six vues. Chacune répond à un besoin distinct :\nVue Grain Sert à exec_requests_history Une ligne par exécution Retrouver une requête précise, son texte, sa durée exec_sessions_history Une ligne par session terminée Reconstituer qui était connecté et quand long_running_queries Agrégat par query_hash Repérer les requêtes récurrentes les plus lentes (médiane) frequently_run_queries Agrégat par query_hash Repérer les requêtes les plus fréquentes sql_pool_insights Journalisation événementielle Suivre la pression sur le pool de calcul external_api_call_stats Une ligne par fonction externe appelée Diagnostiquer les requêtes qui appellent des API externes via les fonctions IA On les trouve dans l\u0026rsquo;Explorer du warehouse, sous Schemas \u0026gt; queryinsights \u0026gt; Views. Elles n\u0026rsquo;existent que dans un Warehouse ou un SQL analytics endpoint.\nRétention : 30 jours. D\u0026rsquo;après la documentation Microsoft, Query Insights conserve 30 jours d\u0026rsquo;historique et d\u0026rsquo;agrégats. Ce point conditionne directement la profondeur d\u0026rsquo;analyse possible ; il n\u0026rsquo;a pas été mesuré en lab.\nDélai d\u0026rsquo;apparition : jusqu\u0026rsquo;à 15 minutes. Une requête terminée n\u0026rsquo;apparaît pas immédiatement dans queryinsights, et le délai croît avec la concurrence. Si une requête de test ne retourne rien, réessayer quelques minutes plus tard avant de conclure.\nLes quatre vues détaillées ci-dessous sont testées en lab. frequently_run_queries et external_api_call_stats ne l\u0026rsquo;ont pas été : la première suit la même logique d\u0026rsquo;agrégation par query_hash que long_running_queries, triée par fréquence plutôt que par durée ; la seconde ne concerne que les requêtes utilisant des fonctions IA.\n2. exec_requests_history : l\u0026rsquo;historique détaillé D\u0026rsquo;abord, la preuve que la colonne command contient bien, ici, le texte complet de la requête (contrairement à la DMV sys.dm_exec_requests, où command n\u0026rsquo;est qu\u0026rsquo;un type d\u0026rsquo;instruction) :\nSur une fenêtre de 60 minutes, command affiche le SQL réel : SELECT session_id, login_name, ..., SET LOCK_TIMEOUT 5000;, DECLARE @IncludeDefinition BIT = 0;. On y voit aussi les requêtes système émises par l\u0026rsquo;éditeur du portail lui-même.\nRequête typique : top 10 des plus lentes sur sept jours, hors bruit interne.\nSELECT TOP 10 login_name, command, start_time, total_elapsed_time_ms FROM queryinsights.exec_requests_history WHERE start_time \u0026gt;= DATEADD(DAY, -7, GETUTCDATE()) AND command \u0026lt;\u0026gt; \u0026#39;TASK MANAGER\u0026#39; ORDER BY total_elapsed_time_ms DESC; Le filtre command \u0026lt;\u0026gt; 'TASK MANAGER' fonctionne, mais révèle autre chose : command contient aussi des instructions PRINT (PRINT \u0026quot;Trip batch 10/10 completed (1000 records)\u0026quot;) issues du script de chargement du jeu d\u0026rsquo;exemple, découpé en lots de 1000 lignes.\nPiège de nommage : en DMV, la durée s\u0026rsquo;appelle total_elapsed_time. Ici, total_elapsed_time_ms. Même notion, nom différent selon la couche.\n3. exec_sessions_history : l\u0026rsquo;historique des sessions SELECT TOP 10 session_id, login_name, session_start_time, session_end_time FROM queryinsights.exec_sessions_history ORDER BY session_start_time DESC;Piège de nommage : en DMV (sys.dm_exec_sessions), la date de début s\u0026rsquo;appelle login_time. Ici, session_start_time, accompagnée de session_end_time. Une session encore active y apparaît avec session_end_time = 1900-01-01.\nEn lab, cette requête s\u0026rsquo;exécute sans erreur mais renvoie 0 ligne :\nRésultat vide alors que des sessions ont clairement existé pendant le lab.\nLa documentation apporte deux éléments qui vont dans le sens d\u0026rsquo;une explication : la vue est décrite comme couvrant les sessions terminées, et l\u0026rsquo;apparition dans queryinsights peut prendre jusqu\u0026rsquo;à 15 minutes. Le lab n\u0026rsquo;a pas rejoué le test pour trancher lequel des deux jouait ici : soit les sessions étaient encore ouvertes, soit la propagation n\u0026rsquo;avait pas eu lieu. À revérifier avec un test dédié.\n4. long_running_queries : l\u0026rsquo;agrégation par similarité SELECT TOP 10 query_hash, median_total_elapsed_time_ms, number_of_runs FROM queryinsights.long_running_queries ORDER BY median_total_elapsed_time_ms DESC; La première ligne affiche number_of_runs = 10 et une médiane de 28 464,5 ms : le moteur a regroupé dix exécutions d\u0026rsquo;une même requête sous un seul query_hash et calculé une durée médiane, au lieu de dix lignes séparées. Les autres lignes sont à number_of_runs = 1, cohérent avec des requêtes de test lancées une seule fois.\nL\u0026rsquo;agrégation se fait sur la forme de la requête : deux requêtes qui ne diffèrent que par leurs littéraux (les valeurs d\u0026rsquo;un WHERE, par exemple) partagent le même query_hash.\nÀ retenir : long_running_queries répond à \u0026ldquo;quelle forme de requête coûte cher de façon répétée\u0026rdquo;, pas \u0026ldquo;quelle exécution individuelle a été lente\u0026rdquo;. Pour cette dernière, c\u0026rsquo;est exec_requests_history.\n5. sql_pool_insights : la santé du pool SELECT TOP 10 sql_pool_name, timestamp, is_pool_under_pressure FROM queryinsights.sql_pool_insights WHERE timestamp \u0026gt;= DATEADD(HOUR, -24, GETUTCDATE()) ORDER BY timestamp DESC; Surprise : sql_pool_name ne contient pas un nom de ressource mais SELECT ou NONSELECT. Fabric Warehouse isole les ressources entre deux pools par défaut, l\u0026rsquo;un pour les SELECT, l\u0026rsquo;autre pour le reste (INSERT, UPDATE, DELETE), et c\u0026rsquo;est cette catégorie qui apparaît ici. Les lignes arrivent par paires SELECT / NONSELECT à des horodatages espacés d\u0026rsquo;environ une minute (20:19:16, 20:18:16, 20:17:16), ce qui correspond à une journalisation événementielle : la vue enregistre un événement quand la configuration du pool, la capacité du workspace ou l\u0026rsquo;état de pression change, les changements de pression étant retenus au pas minimal d\u0026rsquo;une minute, et uniquement quand le warehouse est actif. is_pool_under_pressure reste à 0, cohérent avec la faible charge du lab.\nÀ retenir : ne pas supposer qu\u0026rsquo;un nom de colonne fait ce que son nom suggère. Ici, sql_pool_name répond à \u0026ldquo;quelle catégorie de charge\u0026rdquo;, pas \u0026ldquo;quel pool physique\u0026rdquo;. Vérifier le contenu réel avant de bâtir une alerte dessus.\n6. frequently_run_queries : non testée ici Même structure d\u0026rsquo;agrégat que long_running_queries (query_hash, number_of_runs), orientée fréquence. Utile pour identifier les requêtes candidates à une optimisation, un cache ou une vue matérialisée. À documenter avec un test dédié.\n7. external_api_call_stats : non testée ici Diagnostics au niveau fonction pour les requêtes qui appellent des API externes via les fonctions IA de Fabric : une ligne par fonction externe distincte utilisée par une requête. Hors périmètre de ce lab.\n8. RBAC : le texte des requêtes n\u0026rsquo;est pas visible par tous Le texte complet des requêtes dans queryinsights n\u0026rsquo;est visible que pour les rôles Admin, Member et Contributor. Un Viewer accède aux vues mais pas au texte des commandes.\nL\u0026rsquo;écran Data Warehouse Monitor du portail (ex-« Query Activity »), qui présente les mêmes informations sans écrire de T-SQL, est quant à lui réservé aux Admins. Détail traité dans l\u0026rsquo;article sur les DMV.\nEnfin, la colonne T-SQL derrière le libellé « Submitter » du portail est login_name, dans exec_requests_history comme dans les DMV.\n9. Ce qui reste ouvert Points testés mais pas tranchés avec certitude :\npourquoi queryinsights.exec_sessions_history renvoie 0 ligne alors que des sessions ont existé : sessions encore ouvertes, ou propagation non terminée ? le comportement de frequently_run_queries sous charge réelle ; la rétention effective sur un tenant donné (la doc annonce 30 jours). Chacun mérite un test dédié avant d\u0026rsquo;en faire une affirmation.\nRécapitulatif anti-pièges Piège Ce qu\u0026rsquo;il faut retenir Nombre de vues Six : les cinq usuelles + external_api_call_stats (fonctions IA) command (queryinsights) Texte complet, peut inclure des PRINT internes total_elapsed_time vs total_elapsed_time_ms Même notion, nom différent DMV / queryinsights login_time vs session_start_time Même notion, nom différent DMV / queryinsights exec_sessions_history Sessions terminées uniquement ; délai jusqu\u0026rsquo;à 15 min sql_pool_name Catégorie de charge (SELECT / NON SELECT), pas un identifiant de pool long_running_queries / frequently_run_queries Agrégats par forme de requête (query_hash), pas par exécution Rétention 30 jours d\u0026rsquo;après la documentation Texte complet des requêtes Visible pour Admin / Member / Contributor seulement Data Warehouse Monitor (portail) Réservé aux Admins Pourquoi ça compte au-delà de l\u0026rsquo;examen Pour l\u0026rsquo;examen DP-700 (domaine \u0026ldquo;Monitor and optimize an analytics solution\u0026rdquo;), savoir quelle vue répond à quelle question évite les réponses approximatives.\nEn production, l\u0026rsquo;enjeu est de construire un monitoring qui tient : ne pas bâtir une alerte sur sql_pool_name en croyant y lire un nom de ressource, ne pas attendre d\u0026rsquo;une vue d\u0026rsquo;agrégats le détail d\u0026rsquo;une exécution, et savoir que l\u0026rsquo;historique s\u0026rsquo;arrête à 30 jours. Mieux vaut le cadrer avant l\u0026rsquo;architecture que pendant l\u0026rsquo;incident.\nEn résumé queryinsights est l\u0026rsquo;outil d\u0026rsquo;analyse historique de Fabric Warehouse :\nsix vues, dont deux d\u0026rsquo;agrégats par forme de requête (query_hash) et une, external_api_call_stats, souvent oubliée ; des noms de colonnes qui glissent depuis les DMV (login_time / session_start_time, total_elapsed_time / total_elapsed_time_ms) ; sql_pool_name qui porte une catégorie de charge (SELECT / NON SELECT), pas un identifiant de pool ; 30 jours de rétention, et jusqu\u0026rsquo;à 15 minutes de délai avant qu\u0026rsquo;une requête n\u0026rsquo;y apparaisse. Pour le temps réel et le modèle de concurrence, voir Les DMV de Fabric Warehouse.\nSources officielles Query insights in Fabric Data Warehouse : rétention de 30 jours ; six vues queryinsights ; texte complet des requêtes visible pour les rôles Admin, Member et Contributor ; agrégation par forme de requête (query_hash) ; délai d\u0026rsquo;apparition jusqu\u0026rsquo;à 15 minutes. queryinsights.exec_requests_history (view=fabric) : colonne command avec le texte complet, colonne total_elapsed_time_ms. queryinsights.exec_sessions_history (view=fabric) : vue des sessions terminées ; colonnes session_start_time / session_end_time (une session encore active est affichée avec session_end_time = 1900-01-01). queryinsights.sql_pool_insights (view=fabric) : sql_pool_name vaut SELECT ou NON SELECT (deux pools par défaut, isolation des ressources) ; journalisation événementielle, changements de pression retenus au pas minimal d\u0026rsquo;une minute, uniquement quand le warehouse est actif. Performance guidelines in Fabric Data Warehouse : « Query Execution History (30 days) » et liste des vues de métadonnées de requête. Monitor T-SQL queries (Data Warehouse Monitor) : l\u0026rsquo;écran (ex-« Query Activity ») est réservé aux Admins ; les requêtes historiques peuvent mettre jusqu\u0026rsquo;à 15 minutes à apparaître. Share your data and manage permissions : permission Monitor pour interroger les DMV et les vues Insights. ","permalink":"https://www.techniir.com/posts/query-insights-fabric-warehouse/","summary":"queryinsights regroupe six vues pour analyser l\u0026rsquo;historique des requêtes d\u0026rsquo;un Fabric Warehouse. Grain, rétention, agrégation par forme de requête, et des noms de colonnes qui glissent d\u0026rsquo;une couche à l\u0026rsquo;autre, vérifié en lab.","title":"Query Insights dans Fabric Warehouse : six vues, et ce que leurs noms cachent"},{"content":" Série : Industrialiser Microsoft Fabric · article 1 sur 4 Git integration Fabric : les 5 actions Source Control Déployer Fabric via Azure DevOps et Service Principal Les DMV de Fabric Warehouse : le temps réel, et ce que SQL Server retire Query Insights dans Fabric Warehouse : six vues, et ce que leurs noms cachent Le point de départ Git integration dans Microsoft Fabric a l\u0026rsquo;air simple en surface : on connecte un workspace à un dépôt, on committe, on synchronise. En pratique, le panneau Source Control propose cinq actions dont les noms se ressemblent mais dont le comportement diverge radicalement, et confondre l\u0026rsquo;une avec l\u0026rsquo;autre peut littéralement effacer du contenu sans avertissement suffisant.\nCet article documente ce qu\u0026rsquo;on découvre seulement en testant, pas en lisant la documentation en diagonale.\nDeux fournisseurs, deux mécanismes d\u0026rsquo;authentification Premier piège classique : Azure DevOps et GitHub ne s\u0026rsquo;authentifient pas de la même façon, et l\u0026rsquo;examen (comme la réalité) aime confondre les deux.\nFournisseur Authentification Champs de connexion Azure DevOps Identité Microsoft Entra ID (SSO) Organisation → Projet → Dépôt → Branche GitHub Personal Access Token (PAT) URL du dépôt (+ PAT) Aucun token à gérer côté Azure DevOps : c\u0026rsquo;est ton identité connectée qui sert de preuve. Côté GitHub, c\u0026rsquo;est l\u0026rsquo;inverse : un PAT généré manuellement, aucune notion d\u0026rsquo;organisation/projet dans l\u0026rsquo;écran de connexion.\nLe prérequis qu\u0026rsquo;on oublie facilement Avant même de penser à une branche, deux conditions doivent être réunies au niveau du tenant et de la capacité :\nLe tenant setting générique de synchronisation Git doit être activé (attention : un réglage spécifique GitHub existe séparément, l\u0026rsquo;activer seul ne suffit pas pour Azure DevOps, et vice-versa). Le workspace doit être assigné à une vraie capacité Fabric (F-SKU ou Premium). Une licence PPU (Premium Per User), malgré son nom, ne suffit pas : PPU concerne la personne, pas le workspace. Les tenant settings scindés depuis mi-2025 : un réglage générique, un réglage spécifique par fournisseur, le même schéma se retrouve pour Git integration que pour les Service Principals.\nUn piège géographique découvert en le vivant Sur un tenant récent, une tentative de connexion peut échouer avec un message \u0026ldquo;This workspace is in a different region\u0026rdquo;. La cause : quand le workspace Fabric et l\u0026rsquo;organisation Azure DevOps résident dans des régions différentes, un tenant setting séparé (\u0026ldquo;Users can export items to Git repositories in other geographical locations\u0026rdquo;) doit être activé explicitement.\nLe réglage tel qu\u0026rsquo;on le trouve au départ : désactivé pour l\u0026rsquo;ensemble de l\u0026rsquo;organisation, dans Admin portal → Tenant settings.\nUne fois activé, la bascule ne suffit pas immédiatement. Une notification rappelle que le changement met du temps à se propager :\nAprès activation, Fabric prévient explicitement que les changements de tenant settings peuvent prendre jusqu\u0026rsquo;à 15 minutes avant de s\u0026rsquo;appliquer, un délai facile à oublier quand on retente une connexion immédiatement après et qu\u0026rsquo;elle échoue encore.\nPoint notable : cette contrainte ne s\u0026rsquo;applique qu\u0026rsquo;à Azure DevOps. GitHub n\u0026rsquo;est pas concerné par cette restriction géographique.\nLes cinq actions du panneau Source Control C\u0026rsquo;est le cœur du sujet. Chacune répond à un besoin précis, et les confondre est le piège le plus fréquent.\nAction Sens du flux Portée Destructif ? Commit Workspace → Git Items sélectionnés Non Updates Git → Workspace (même branche) Items modifiés côté Git uniquement Non (incrémental) Switch branch Git → Workspace (autre branche) Tous les items Oui (remplace tout) Checkout new branch N/A Aucun changement de contenu Non Branch out to workspace Git → Nouveau workspace Tous ou sélection Non (workspace séparé) flowchart LR Git[(\u0026#34;Dépôt Git\u0026lt;br/\u0026gt;Azure DevOps / GitHub\u0026#34;)] WS[\u0026#34;Workspace Fabric\u0026#34;] NewWS[\u0026#34;Nouveau workspace\u0026#34;] WS --\u0026gt;|\u0026#34;Commit\u0026#34;| Git Git --\u0026gt;|\u0026#34;Updates (incrémental)\u0026#34;| WS Git -.-\u0026gt;|\u0026#34;Switch branch (remplace tout)\u0026#34;| WS Git --\u0026gt;|\u0026#34;Branch out to workspace\u0026#34;| NewWS style Git fill:#0f3038,stroke:#2ec7c2,color:#eafffb style WS fill:#0f3038,stroke:#eafffb,color:#eafffb style NewWS fill:#0f3038,stroke:#6ee7d8,color:#eafffbLe test qui rend ça concret En pratique : créer un item sur une branche, puis faire Switch branch vers main (où cet item n\u0026rsquo;existe pas) le fait disparaître immédiatement du workspace, sans confirmation autre qu\u0026rsquo;un avertissement générique au moment de l\u0026rsquo;action.\nL\u0026rsquo;avertissement est clair une fois qu\u0026rsquo;on le lit : \u0026ldquo;all items in this workspace will be replaced with the items in the target Git branch\u0026rdquo;, mais il est facile de cliquer vite sans en mesurer la portée la première fois.\nÀ l\u0026rsquo;inverse, Updates ramène uniquement ce qui a changé côté Git, sans toucher au reste, beaucoup plus sûr pour un usage courant.\nLe workflow professionnel complet Ces actions individuelles prennent tout leur sens une fois assemblées dans un vrai cycle de développement :\nBranch out to workspace : isoler son travail dans un workspace dédié, connecté à une nouvelle branche Développer et tester dans cet environnement isolé Commit les changements vers la branche de fonctionnalité Pull Request côté fournisseur Git (Azure DevOps ou GitHub) : revue et fusion, pas dans Fabric Une fois mergé, le workspace d\u0026rsquo;équipe utilise Updates pour récupérer les changements, de façon incrémentale, sans tout écraser flowchart LR A[\u0026#34;Branch out to workspace\u0026lt;br/\u0026gt;(nouvelle branche)\u0026#34;] --\u0026gt; B[\u0026#34;Développer \u0026amp; tester\u0026#34;] B --\u0026gt; C[\u0026#34;Commit vers la branche\u0026#34;] C --\u0026gt; D[\u0026#34;Pull Request\u0026lt;br/\u0026gt;Azure DevOps / GitHub\u0026#34;] D --\u0026gt; E[\u0026#34;Merge dans main\u0026#34;] E --\u0026gt; F[\u0026#34;Updates\u0026lt;br/\u0026gt;(workspace d\u0026#39;équipe)\u0026#34;] Le merge se passe entièrement côté Azure DevOps. Fabric n\u0026rsquo;intervient qu\u0026rsquo;après, via Updates, pour synchroniser le workspace.\nC\u0026rsquo;est un vrai pattern GitOps, pas une improvisation propre à Fabric, la nouveauté est dans la façon dont Fabric matérialise chaque étape via son propre panneau Source Control.\nCe que ça implique pour l\u0026rsquo;industrialisation Au-delà de la préparation à la certification, ces mécanismes posent les bases d\u0026rsquo;une vraie stratégie de release management sur Fabric, la discipline qui contrôle comment un changement passe du développement à la production, de façon prévisible :\nLes branches et Pull Requests contrôlent le passage du code au niveau du dépôt Les pipelines de déploiement (Dev → Test → Prod) contrôlent le passage du contenu au niveau des workspaces Ce sont deux portes de contrôle indépendantes mais complémentaires. Un item peut être mergé dans main sans avoir été déployé vers Test ou Prod.\nEn résumé Cinq actions, cinq comportements distincts, un seul principe à retenir : est-ce que l\u0026rsquo;action pousse (Commit), tire de façon incrémentale (Updates), remplace tout (Switch branch), ou crée un nouvel espace séparé (Branch out) ? Une fois ce principe ancré, plus aucune de ces actions n\u0026rsquo;est surprenante, seulement des outils différents pour des besoins différents.\nSources officielles Get started with Git integration : une capacité Fabric (ou Premium) est requise ; connexion Azure DevOps via l\u0026rsquo;identité Microsoft Entra connectée (« Automatic Git credential »), URL au format https://dev.azure.com/{organization}/{project}/_git/{repository}, authentification OAuth2 ou Service Principal. Understand Microsoft Fabric licenses and capacity : « Premium Per User (PPU) doesn\u0026rsquo;t provision a Fabric capacity » ; il faut une capacité F (ou Trial) pour les items Fabric non-Power BI. Git integration tenant settings : « Users can synchronize workspace items with their Git repositories » activé par défaut ; « Users can sync workspace items with GitHub repositories » désactivé par défaut ; « Users can export items to Git repositories in other geographical locations » pour le cas cross-géo (Azure DevOps uniquement, seules les métadonnées sont exportées, non applicable à GitHub). Basic concepts in Git integration : les cinq actions Source Control (Commit, Update, Switch branch, Checkout new branch, Branch out) et leurs rôles requis ; Switch branch « overrides all items in the workspace with the content of the selected branch » ; Checkout new branch « doesn\u0026rsquo;t change the workspace content » ; Update synchronise toute la branche et ne permet pas de choisir les items ; Commit permet de choisir les items ; la restriction cross-géo ne s\u0026rsquo;applique pas à GitHub ; limites de taille de commit (25 Mo ADO + Service Principal, 125 Mo ADO + SSO, 50 Mo GitHub) ; Azure DevOps non pris en charge si « IP Conditional Access policy validation » est activé. Automate git integration with a service principal in Azure DevOps : « Automatic Git credential » vs « Configured credential » (OAuth 2.0 ou Service Principal). Fabric CI/CD concepts and best practices : connecteur « Azure DevOps - Source control » (identité Entra, user ou Service Principal) vs connecteur « GitHub - Source control » (PAT : token fine-grained avec permission Contents lecture/écriture, ou token classique avec scope repo). About tenant settings : « It can take up to 15 minutes for a setting change to take effect. » ","permalink":"https://www.techniir.com/posts/git-integration-switch-branch-updates-fabric/","summary":"Cinq actions du panneau Source Control de Fabric se ressemblent sur le papier mais font des choses radicalement différentes. Retour d\u0026rsquo;expérience pratique, avec les pièges rencontrés en testant chacune.","title":"Git integration Fabric : les 5 actions Source Control"},{"content":" Série : Industrialiser Microsoft Fabric · article 2 sur 4 Git integration Fabric : les 5 actions Source Control Déployer Fabric via Azure DevOps et Service Principal Les DMV de Fabric Warehouse : le temps réel, et ce que SQL Server retire Query Insights dans Fabric Warehouse : six vues, et ce que leurs noms cachent Le scénario Un pipeline de déploiement Microsoft Fabric doit être déclenché depuis un pipeline CI/CD externe (Azure DevOps), sans intervention humaine. La question qui se pose systématiquement : quel mécanisme d\u0026rsquo;authentification utiliser entre un système externe et l\u0026rsquo;API Fabric ?\nRéponse courte : un Service Principal (identité Microsoft Entra ID dédiée à l\u0026rsquo;application, pas un compte utilisateur). Cet article documente comment le mettre en place de bout en bout, avec les erreurs réellement rencontrées, pas seulement le chemin heureux.\nCe qu\u0026rsquo;on construit Un Service Principal Microsoft Entra ID Deux workspaces Fabric reliés par un pipeline de déploiement (stages Development / Test) Un pipeline Azure DevOps qui authentifie ce Service Principal et déclenche le déploiement via l\u0026rsquo;API REST Fabric flowchart LR ADO[\u0026#34;Azure DevOps\u0026lt;br/\u0026gt;tâche Bash@3\u0026#34;] --\u0026gt;|\u0026#34;1. client_credentials\u0026#34;| Entra[\u0026#34;Microsoft Entra ID\u0026#34;] Entra --\u0026gt;|\u0026#34;2. access_token\u0026#34;| ADO ADO --\u0026gt;|\u0026#34;3. POST /deploy (Bearer token)\u0026#34;| Fabric[\u0026#34;API REST Fabric\u0026#34;] Fabric --\u0026gt; Pipe[\u0026#34;Pipeline de déploiement\u0026#34;] Pipe --\u0026gt;|\u0026#34;4. déclenche\u0026#34;| Dev[\u0026#34;Stage Development\u0026#34;] Dev --\u0026gt;|\u0026#34;5. promotion\u0026#34;| Test[\u0026#34;Stage Test\u0026#34;]Étape 1. Le Service Principal Dans Microsoft Entra ID, une App Registration classique suffit : un client_id, un tenant_id, et un secret. Trois éléments à bien distinguer :\ntenant_id identifie l\u0026rsquo;annuaire Microsoft Entra client_id identifie l\u0026rsquo;application elle-même (l\u0026rsquo;équivalent d\u0026rsquo;un nom d\u0026rsquo;utilisateur) client_secret prouve son identité (l\u0026rsquo;équivalent d\u0026rsquo;un mot de passe) Côté Azure DevOps, ces trois valeurs se configurent dans une Service Connection dédiée : Project Settings → Pipelines → Service connections → New service connection → Azure Resource Manager, puis authentification Service principal (manual) :\nLes champs à renseigner : Application (client) ID, Directory (tenant) ID, et le Client secret (credential \u0026ldquo;Service principal key\u0026rdquo;). Un clic sur \u0026ldquo;Verify\u0026rdquo; avant de sauvegarder confirme que les identifiants sont valides.\nQuelques points d\u0026rsquo;attention :\nChoisir l\u0026rsquo;authentification manuelle, pas automatique : ce Service Principal n\u0026rsquo;a pas nécessairement de rôle sur un abonnement Azure, seulement les permissions Fabric configurées plus loin. Nommer la connexion de façon explicite (ici sc-fabric-sp) pour la retrouver facilement dans les tâches du pipeline et dans les journaux d\u0026rsquo;audit. Sous Security, ne pas cocher \u0026ldquo;Grant access permission to all pipelines\u0026rdquo; par défaut : autoriser explicitement chaque pipeline qui en a besoin limite le rayon d\u0026rsquo;exposition du secret. Étape 2. Activer les Service Principals côté tenant Fabric Depuis mi-2025, Microsoft a scindé un ancien réglage unique en deux réglages distincts dans l\u0026rsquo;Admin Portal Fabric (Tenant settings → Developer settings) :\nLes deux réglages tenant scindés depuis mi-2025 : \u0026ldquo;Service principals can call Fabric public APIs\u0026rdquo; (entouré) contrôle les appels API génériques, tandis que le réglage juste au-dessus gère spécifiquement la création de workspaces, connexions et pipelines de déploiement.\nLe second réglage, plus spécifique, contrôle la création de workspaces, connexions et pipelines de déploiement :\nLe second réglage, spécifique aux pipelines de déploiement : sans lui activé, le Service Principal n\u0026rsquo;apparaît pas dans la recherche \u0026ldquo;Add people\u0026rdquo; des workspaces, même si le premier réglage (appels API génériques) est déjà activé.\nService principals can call Fabric public APIs : activé par défaut sur les nouveaux tenants Service principals can create workspaces, connections, and deployment pipelines : désactivé par défaut, à activer explicitement Sans le second réglage, le Service Principal reste invisible dans la recherche \u0026ldquo;Add people\u0026rdquo; des workspaces.\nÉtape 3. Le piège le plus instructif : deux modèles de permissions séparés C\u0026rsquo;est le point qui a le plus surpris pendant l\u0026rsquo;implémentation. Ajouter le Service Principal comme Admin sur les deux workspaces ne suffit pas : le pipeline de déploiement a son propre système de permissions, totalement indépendant des rôles de workspace.\nflowchart TB SP[\u0026#34;Service Principal\u0026#34;] SP --\u0026gt;|\u0026#34;rôle Admin\u0026#34;| WSDev[\u0026#34;Workspace Dev\u0026#34;] SP --\u0026gt;|\u0026#34;rôle Admin\u0026#34;| WSTest[\u0026#34;Workspace Test\u0026#34;] SP -.-\u0026gt;|\u0026#34;accès manquant par défaut\u0026#34;| PipeAccess[\u0026#34;Pipeline de déploiement\u0026lt;br/\u0026gt;Manage access\u0026#34;] PipeAccess --\u0026gt;|\u0026#34;condition requise pour\u0026#34;| ListAPI[\u0026#34;API List Deployment Pipelines\u0026#34;] style PipeAccess stroke:#ef4444,stroke-width:2px,stroke-dasharray: 4 2 Le \u0026ldquo;Manage access\u0026rdquo; du pipeline de déploiement lui-même (pas des workspaces) : c\u0026rsquo;est ici, et seulement ici, qu\u0026rsquo;il faut ajouter le Service Principal avec le rôle Admin pour qu\u0026rsquo;il puisse lister et déclencher des déploiements, une permission totalement séparée des rôles accordés sur les workspaces Development et Test.\nSans l\u0026rsquo;accès \u0026ldquo;Admin\u0026rdquo; explicitement accordé sur le pipeline lui-même (via son \u0026ldquo;Manage access\u0026rdquo; dédié), l\u0026rsquo;API List Deployment Pipelines ne renvoie même pas le pipeline pour ce Service Principal, silencieusement, sans message d\u0026rsquo;erreur explicite sur la cause.\nC\u0026rsquo;est un piège facile à reproduire en entreprise : un Service Principal peut avoir toutes les permissions nécessaires sur les workspaces et échouer quand même, parce que la permission manquante se trouve ailleurs.\nÉtape 4. Le bon outil pour le bon flux d\u0026rsquo;authentification Premier réflexe naturel dans Azure DevOps : utiliser la tâche AzureCLI@2, couplée à une Service Connection Azure Resource Manager. Mauvais choix : cette tâche présuppose un contexte Azure Resource Manager valide et tente automatiquement un az account set sur un abonnement Azure, ce qui échoue si le Service Principal n\u0026rsquo;a aucun rôle ARM (normal, il n\u0026rsquo;en a pas besoin pour parler à Fabric).\nL\u0026rsquo;API Fabric n\u0026rsquo;a rien à voir avec ARM. Une simple tâche Bash@3, avec des appels curl bruts et un token OAuth2 obtenu via le flux client credentials, suffit, sans dépendance artificielle à un abonnement Azure :\nTOKEN=$(curl -s -X POST \\ \u0026#34;https://login.microsoftonline.com/$TENANT_ID/oauth2/v2.0/token\u0026#34; \\ -H \u0026#34;Content-Type: application/x-www-form-urlencoded\u0026#34; \\ -d \u0026#34;grant_type=client_credentials\u0026#34; \\ -d \u0026#34;client_id=$CLIENT_ID\u0026#34; \\ -d \u0026#34;client_secret=$CLIENT_SECRET\u0026#34; \\ -d \u0026#34;scope=https://api.fabric.microsoft.com/.default\u0026#34; \\ | jq -r \u0026#39;.access_token\u0026#39;)Étape 5. Retrouver dynamiquement le pipeline de déploiement et ses stages Plutôt que de coder en dur des GUID fragiles, le script liste les pipelines de déploiement et les stages disponibles, puis filtre par nom :\ncurl -s -X GET \u0026#34;https://api.fabric.microsoft.com/v1/deploymentPipelines\u0026#34; \\ -H \u0026#34;Authorization: Bearer $TOKEN\u0026#34; | \\ jq -r --arg NAME \u0026#34;deployPipeline1\u0026#34; \u0026#39;.value[] | select(.displayName==$NAME) | .id\u0026#39;Étape 6. Déclencher le déploiement, et comprendre la réponse curl -s -X POST \u0026#34;https://api.fabric.microsoft.com/v1/deploymentPipelines/$PIPELINE_ID/deploy\u0026#34; \\ -H \u0026#34;Authorization: Bearer $TOKEN\u0026#34; \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#34;{\\\u0026#34;sourceStageId\\\u0026#34;: \\\u0026#34;$SOURCE_STAGE_ID\\\u0026#34;, \\\u0026#34;targetStageId\\\u0026#34;: \\\u0026#34;$TARGET_STAGE_ID\\\u0026#34;}\u0026#34; Le pipeline Azure DevOps complet, toutes les étapes en succès : authentification, listing du pipeline de déploiement, listing des stages, déclenchement du déploiement.\nPoint important : la réponse est un 202 Accepted, pas un succès final. L\u0026rsquo;API Fabric expose ici un pattern de Long Running Operation : le déploiement continue en arrière-plan, et son statut réel doit être vérifié séparément via l\u0026rsquo;en-tête x-ms-operation-id retourné.\nCe qui manque encore pour une vraie mise en production Ce mécanisme fonctionne, mais il ne constitue pas à lui seul une solution industrialisée. Pour aller plus loin :\nRemplacer le client_secret par une Workload Identity Federation (élimine la gestion et la rotation de secrets) Ajouter une porte d\u0026rsquo;approbation avant tout déploiement vers un stage sensible Vérifier réellement le statut final de l\u0026rsquo;opération (Succeeded/Failed) plutôt que de s\u0026rsquo;arrêter au 202 Étendre à un vrai modèle à 3 stades (Dev/Test/Production) Résultat final dans le workspace Test : tous les items déployés (Lakehouse, environnement, notebooks) ont le Service Principal comme Owner (pas un compte utilisateur), la preuve que le déploiement automatisé a bien fonctionné sans aucune intervention humaine.\nEn résumé L\u0026rsquo;authentification par Service Principal est la bonne réponse technique, mais la mettre en œuvre correctement révèle des subtilités qu\u0026rsquo;aucune documentation ne couvre entièrement : la séparation des permissions pipeline/workspace, le bon choix d\u0026rsquo;outil CI/CD selon le flux d\u0026rsquo;authentification réel, et la nature asynchrone des déploiements Fabric.\nSources officielles Service principals in Fabric Data Warehouse : un Service Principal est une identité Microsoft Entra applicative ; accès accordé via Manage access au niveau du workspace ; jeton d\u0026rsquo;accès expirant en ~1 h ; obtention d\u0026rsquo;un jeton Fabric avec az account get-access-token --resource https://api.fabric.microsoft.com. Service principals in Fabric Data Warehouse - Limitations : « Service principals are not supported for Git APIs. SPN support exists only for Deployment pipeline APIs. » Developer tenant settings : « Service principals can call Fabric public APIs » est activé par défaut pour les nouveaux clients ; « Service principals can create workspaces, connections, and deployment pipelines » est désactivé par défaut et couvre les API Create Workspace, Create Connection et Create Deployment Pipeline. Identity support (Fabric REST API) : chaque page d\u0026rsquo;API indique la prise en charge des Service Principals ; un appel échoue si une API ou un item dépendant ne prend pas en charge l\u0026rsquo;identité appelante. Deployment Pipelines - Deploy Stage Content : POST /v1/deploymentPipelines/{id}/deploy avec sourceStageId et targetStageId ; réponse 202 Accepted avec en-têtes Location, x-ms-operation-id, deployment-id, Retry-After ; l\u0026rsquo;appelant doit avoir le rôle admin sur le pipeline de déploiement et être au moins contributor sur les workspaces source et cible ; scope Pipeline.Deploy ; maximum 300 items. Long running operations (Fabric REST API) : modèle asynchrone à suivre après un 202. The deployment pipelines process - Permissions : le rôle pipeline admin est distinct des rôles de workspace. Set a service principal as a pipeline owner : jeton expirant ~1 h, endpoint api.fabric.microsoft.com, Contributor minimum sur le workspace. Tutorial: End-to-end automation in Fabric : Service Principal, capacité et Azure DevOps de bout en bout. ","permalink":"https://www.techniir.com/posts/service-principal-deployment-pipeline-fabric/","summary":"Retour d\u0026rsquo;expérience pas à pas : authentifier Azure DevOps auprès de l\u0026rsquo;API Fabric via un Service Principal, et déclencher un déploiement Dev → Test, avec les pièges rencontrés en conditions réelles.","title":"Déployer Fabric via Azure DevOps et Service Principal"}]