Dataverse et Microsoft Fabric : l'analytique sur les données Dynamics 365 sans ETL

De l'analytique sur Dataverse sans construire de pipeline

Pendant des années, produire des rapports sur les données de Dynamics 365 Customer Engagement revenait à choisir entre trois options : Power BI connecté directement à Dataverse, avec ses limites, un export nocturne qu'il fallait surveiller, ou un projet d'entrepôt de données plus long que la mise en œuvre CRM elle-même. Link to Microsoft Fabric change la donne. La fonctionnalité rend vos tables Dataverse disponibles dans OneLake, le data lake intégré à Fabric, sans que vous deviez construire ni exploiter de pipeline ETL. Microsoft la présente dans la vue d'ensemble de Link to Microsoft Fabric.

J'ai déjà mis en place des liens Fabric pour plusieurs environnements CE, et la fonctionnalité est réellement utile. Elle est aussi très facile à activer sans réfléchir à qui verra les données, à ce qu'elle coûte en capacité Dataverse et aux usages pour lesquels elle est vraiment adaptée. Cet article explique le fonctionnement du lien, le compare à Azure Synapse Link et au point de terminaison TDS, et passe en revue les questions de sécurité et de coût que je pose avant de l'activer.

Fonctionnement de Link to Fabric

Lorsque vous créez un lien Fabric, Dataverse maintient une réplique optimisée des tables sélectionnées au format Delta Parquet, le format natif de Fabric et de OneLake. Cette réplique est stockée dans un espace géré par Dataverse, dans la même région que votre environnement, de sorte que les requêtes analytiques n'affectent pas votre activité opérationnelle. Fabric accède ensuite aux données via des raccourcis OneLake (shortcuts) : des pointeurs vers les données, et non une copie supplémentaire.

Ce que l'assistant crée pour vous

• Un lakehouse Fabric : un lakehouse par lien, avec un raccourci pour chaque table Dataverse liée.
• Un SQL analytics endpoint : un accès T-SQL en lecture seule aux mêmes tables, utilisable depuis SQL Server Management Studio, Azure Data Studio ou tout client SQL prenant en charge Microsoft Entra ID.
• Un modèle sémantique : un point de départ pour les rapports Power BI, qui peuvent exploiter le mode Direct Lake directement sur les tables Delta.
• Une connexion de données : la connexion utilisée par Fabric pour dialoguer avec Dataverse, que vous pouvez basculer vers une workspace identity ou un principal de service plutôt qu'un compte personnel.

Les modifications effectuées dans Dataverse sont propagées en continu vers le lakehouse, mais pas en temps réel. Microsoft indique qu'un délai pouvant aller jusqu'à une heure est possible, et la synchronisation initiale des grandes tables prend davantage de temps. La synchronisation à faible latence est déployée progressivement et activée automatiquement ; les liens existants restent sur l'ancien moteur tant que vous ne supprimez pas puis recréez le lien (avec une resynchronisation complète). Elle écrit directement en Delta Parquet, utilise des horodatages INT64 et des vecteurs de suppression, et retire createdonpartition de OptionsetMetadata. Vérifiez la documentation avant de promettre des tableaux de bord quasi temps réel.

Mettre en place le lien

La configuration se fait via un assistant dans Power Apps (make.powerapps.com) : sélectionnez Link data dans la navigation de gauche, puis + New link et l'option Fabric. Vous pouvez aussi démarrer depuis la zone Tables via Analyze > Analyze in Fabric. L'assistant est rapide ; ce sont les prérequis qui ralentissent généralement un projet.

1. Vous devez disposer du rôle System Administrator dans l'environnement Dataverse.
2. Vous devez être administrateur de l'espace de travail Fabric (Power BI) cible.
3. L'espace de travail doit être hébergé sur une capacité Fabric ou Power BI Premium ; une capacité d'essai suffit pour une preuve de concept.
4. Un administrateur Fabric doit autoriser, dans les paramètres du tenant, la création d'éléments et d'espaces de travail ainsi que l'accès aux données OneLake depuis des applications extérieures à Fabric.
5. Décidez de l'authentification dès le départ. Microsoft recommande la workspace identity, qui doit être ajoutée comme utilisateur d'application dans Dataverse avec un rôle approprié.
6. Vérifiez la sélection des tables. Par défaut, toutes les tables non système dont l'option Track changes est activée sont sélectionnées. Retirez ce dont vous n'avez pas besoin avant de terminer.

Tous les prérequis et options sont décrits dans la documentation de configuration pas à pas de Microsoft.

Link to Fabric, Azure Synapse Link ou point de terminaison TDS ?

Link to Fabric n'est pas le seul moyen d'amener des données CE vers une plateforme analytique. En pratique, je le compare à Azure Synapse Link for Dataverse (désormais appelé Link to Data lake dans l'interface Power Apps) et au point de terminaison TDS (SQL) en lecture seule. Ils répondent à des besoins différents.

Ma règle empirique

• Choisissez Link to Fabric lorsque l'organisation utilise déjà Fabric (ou s'y oriente) et que vous souhaitez placer les données CE à côté des données financières, web ou produit sans pipeline à maintenir.
• Choisissez Azure Synapse Link lorsqu'une plateforme de données Azure est déjà en place, lorsque les données doivent atterrir dans un compte de stockage appartenant au client, ou lorsque les outils en aval lisent directement des fichiers. Utilisez l'option Delta/Parquet : les profils CSV ne peuvent pas être liés à Fabric par la suite.
• Utilisez le point de terminaison TDS pour des analyses ponctuelles et des rapports modestes, lorsque le respect de la sécurité Dataverse de chaque utilisateur compte davantage que le volume. Les requêtes sont soumises à un délai d'expiration et aux limites de protection du service.
• Conservez les exports et intégrations pour les échanges de données opérationnels. Fabric sert à l'analytique ; si un autre système a besoin des données CE pour exécuter un processus, mettez en place une véritable intégration plutôt que de lire le lakehouse.

Pour le détail des alternatives, consultez la documentation sur Azure Synapse Link for Dataverse et sur le point de terminaison TDS (SQL).

Exploiter les données

Une fois la synchronisation initiale terminée, les tables apparaissent dans le lakehouse sous leurs noms logiques Dataverse (account, opportunity, incident, etc.). Les analystes peuvent les interroger en T-SQL via le SQL analytics endpoint, avec Spark dans un notebook, ou via le modèle sémantique dans Power BI.

T-SQL sur le SQL analytics endpoint

Les colonnes de choix ne contiennent que la valeur numérique. Les libellés se trouvent dans des tables de métadonnées distinctes (OptionsetMetadata pour les choix locaux, GlobalOptionsetMetadata pour les choix globaux, ainsi que StateMetadata et StatusMetadata). L'exemple ci-dessous associe un choix local personnalisé de la table account à son libellé anglais et totalise le pipeline ouvert par segment.

-- Open pipeline per customer segment (custom local choice crx_segment on account)
SELECT
    COALESCE(seg.LocalizedLabel, 'No segment') AS Segment,
    COUNT(o.opportunityid)                     AS OpenOpportunities,
    SUM(o.estimatedvalue)                      AS Pipeline
FROM opportunity AS o
INNER JOIN account AS a
    ON a.accountid = o.parentaccountid
LEFT JOIN OptionsetMetadata AS seg
    ON  seg.EntityName = 'account'
    AND seg.OptionSetName = 'crx_segment'
    AND seg.[Option] = a.crx_segment
    AND seg.LocalizedLabelLanguageCode = 1033
WHERE o.statecode = 0          -- Open
GROUP BY COALESCE(seg.LocalizedLabel, 'No segment')
ORDER BY Pipeline DESC;

PySpark dans un notebook Fabric

Pour des transformations plus lourdes, attachez un notebook au lakehouse et travaillez directement sur les tables Delta. Un schéma courant consiste à écrire les résultats retravaillés dans un lakehouse distinct que vous gérez, plutôt que de modifier celui géré par Dataverse.

# Fabric notebook with the Dataverse lakehouse attached as default
from pyspark.sql import functions as F

cases = spark.read.table("incident")

monthly = (
    cases
    .where(F.col("statecode") == 1)   # Resolved
    .withColumn("month", F.date_trunc("month", F.col("createdon")))
    .groupBy("month", "prioritycode")
    .agg(F.count("incidentid").alias("resolved_cases"))
)

# Write to your own curated lakehouse, not the one Dataverse manages.
# saveAsTable with a lakehouse name only works when that lakehouse is attached
# to this notebook; otherwise write to its abfss:// OneLake path with .save().
monthly.write.mode("overwrite").format("delta") \
    .saveAsTable("curated_lakehouse.case_volume_monthly")

Considérez le lakehouse lié comme une couche source en lecture seule. Construisez à côté votre propre couche retravaillée, afin qu'une nouvelle liaison ou un changement de schéma dans Dataverse ne casse pas tous les rapports d'un coup. Le schéma des tables de métadonnées de choix est décrit dans la documentation sur les libellés de choix.

Sécurité : les rôles Dataverse ne suivent pas les données

C'est le point que je soulève dans chaque projet. Dans Dataverse, ce qu'un utilisateur voit dépend des rôles de sécurité, des unités commerciales, de la propriété par équipe, du partage et de la sécurité au niveau des colonnes. Le lien lit Dataverse avec l'identité de la connexion, qui dispose généralement du rôle System Administrator. Dans Fabric, l'accès est régi par les rôles d'espace de travail et la sécurité OneLake, et non par les privilèges Dataverse de l'utilisateur.

Mon approche

• Limitez les rôles d'espace de travail : réservez les rôles Admin, Member et Contributor à l'équipe data. Les consommateurs de rapports reçoivent un accès aux rapports ou aux applications, pas à l'espace de travail.
• Utilisez la sécurité OneLake pour l'accès aux données : lorsque des analystes ont besoin d'un accès direct, définissez des rôles sur le lakehouse ou sur des tables précises au lieu de tout ouvrir.
• Reconstruisez la sécurité au niveau des lignes dans le modèle sémantique : si les rapports doivent respecter la propriété ou l'unité commerciale, modélisez-le explicitement dans Power BI. Rien n'est hérité de Dataverse.
• Soyez sélectif avec les tables sensibles : les colonnes protégées par la sécurité au niveau des colonnes dans Dataverse méritent la même vigilance ici. Si une table n'est pas nécessaire à l'analyse, ne la liez pas.
• Pensez au RGPD : la réplique contient des données personnelles. Intégrez-la à votre registre des activités de traitement et vérifiez comment les suppressions et durées de conservation de Dataverse se répercutent dans les couches retravaillées que vous construisez en aval.

Le modèle de sécurité propre à Fabric est expliqué dans la vue d'ensemble de la sécurité OneLake.

Considérations de coût

Link to Fabric est présenté comme « sans ETL », ce qui est exact, mais il n'est pas gratuit. Deux compteurs entrent en jeu.

• Capacité de base de données Dataverse : la réplique Delta Parquet est comptabilisée dans votre capacité de base de données Dataverse et apparaît dans les rapports de capacité du centre d'administration Power Platform. Les grandes tables, comme les activités, les e-mails ou des tables personnalisées volumineuses, pèsent vite lourd.
• Capacité Fabric : chaque requête, exécution de notebook, actualisation de modèle sémantique et interaction avec un rapport consomme des unités de capacité. Une charge Power BI soutenue sur une petite capacité sera limitée.
• Sélection des tables : seules les tables liées consomment du stockage. Comme l'assistant sélectionne par défaut toutes les tables avec suivi des modifications, l'optimisation la moins chère consiste simplement à retirer celles dont personne n'a besoin.
• Stratégie d'environnements : lier chaque sandbox double le stockage pour un bénéfice limité. Dans la plupart des projets, je lie la production et un seul environnement hors production pour le développement des rapports.

Avant d'activer le lien en production, vérifiez la consommation actuelle de capacité de base de données, estimez la taille des tables à lier et convenez de qui finance la capacité Fabric. Cette discussion est bien plus simple avant l'arrivée de l'alerte de stockage.

Les pièges que j'ai rencontrés

La plupart des problèmes ne sont pas des bogues, mais des comportements documentés faciles à manquer.

• Track changes non activé : les tables sans suivi des modifications ne peuvent pas être liées. Activez-le sur vos tables personnalisées dans votre solution, et non manuellement en production.
• Modification du type de données d'une colonne : changer le type ou la précision d'une colonne synchronisée (par exemple d'entier à décimal) casse définitivement la synchronisation delta de cette table ; supprimer puis recréer la colonne sous le même nom ne règle pas le problème. La solution consiste à retirer puis rajouter la table, ce qui déclenche une resynchronisation complète.
• Nouvelles colonnes invisibles : après l'ajout de colonnes, utilisez Refresh Fabric tables sur le lien ; la modification apparaît lors du prochain changement de données dans la table.
• Suppression du lien avec des dépendances : supprimer le lien supprime le lakehouse, et Fabric refuse de supprimer un lakehouse tant que des pipelines ou des modèles sémantiques y font référence. Identifiez d'abord les éléments dépendants via la vue de traçabilité (lineage).
• Nom du lakehouse codé en dur : Microsoft avertit explicitement que le format du nom généré peut changer. Référencez l'espace de travail et le lakehouse par leur ID.
• Espaces de travail verrouillés : les espaces de travail qui limitent le trafic entrant aux liaisons privées ou à des réseaux sélectionnés ne peuvent pas être utilisés avec Link to Fabric. Impliquez l'équipe réseau dès le départ.
• Attendre du temps réel : pour des tableaux de bord opérationnels qui doivent refléter les dernières minutes, interrogez directement Dataverse ou utilisez le point de terminaison TDS.

Bon nombre de ces limites figurent dans la FAQ de Link to Fabric.

Conclusion

Link to Fabric supprime l'essentiel de la tuyauterie qui séparait autrefois Dynamics 365 Customer Engagement d'une véritable plateforme analytique. Pour les organisations qui investissent déjà dans Fabric, c'est aujourd'hui ma recommandation par défaut pour le reporting CE à grande échelle.

Traitez-le comme une décision d'architecture et non comme une case à cocher : choisissez l'espace de travail en connaissance de cause, verrouillez les accès puisque la sécurité Dataverse ne suit pas les données, surveillez la capacité Dataverse et construisez votre propre couche retravaillée au-dessus du lakehouse lié. Vous obtiendrez ainsi de l'analytique CE sans pipeline à maintenir.