Dataverse en Microsoft Fabric: analyses op Dynamics 365-data zonder ETL

Analyses op Dataverse zonder een pipeline te bouwen

Jarenlang betekende rapportering op Dynamics 365 Customer Engagement-data een van drie dingen: Power BI rechtstreeks op Dataverse, met alle beperkingen van dien, een nachtelijke exportjob die iemand moest opvolgen, of een datawarehouseproject dat langer duurde dan de CRM-implementatie zelf. Link to Microsoft Fabric verandert die afweging. De functie maakt uw Dataverse-tabellen beschikbaar in OneLake, het data lake dat in Fabric is ingebouwd, zonder dat u een ETL-pipeline moet bouwen of beheren. Microsoft beschrijft de functie in het overzicht van Link to Microsoft Fabric.

Ondertussen heb ik Fabric-links opgezet voor verschillende CE-omgevingen, en de functie is echt nuttig. Ze is ook gemakkelijk aan te zetten zonder stil te staan bij wie de data te zien krijgt, wat ze kost aan Dataverse-capaciteit en voor welke toepassingen ze eigenlijk geschikt is. In dit artikel bespreek ik hoe de link werkt, hoe ze zich verhoudt tot Azure Synapse Link en het TDS-endpoint, en welke vragen over beveiliging en kosten ik stel voor ik ze activeer.

Hoe Link to Fabric werkt

Wanneer u een Fabric-link aanmaakt, onderhoudt Dataverse een geoptimaliseerde replica van de geselecteerde tabellen in Delta Parquet-formaat, het native formaat van Fabric en OneLake. Die replica staat in opslag die Dataverse beheert, in dezelfde regio als uw omgeving, zodat analytische query's uw operationele werking niet beïnvloeden. Fabric ziet de data vervolgens via OneLake-shortcuts: verwijzingen naar de data, geen bijkomende kopie.

Wat de wizard voor u aanmaakt

• Een Fabric-lakehouse: één lakehouse per link, met een shortcut voor elke gekoppelde Dataverse-tabel.
• Een SQL analytics endpoint: alleen-lezen T-SQL-toegang tot dezelfde tabellen, bruikbaar vanuit SQL Server Management Studio, Azure Data Studio of elke SQL-client die Microsoft Entra ID ondersteunt.
• Een semantisch model: een vertrekpunt voor Power BI-rapporten, die in Direct Lake-modus rechtstreeks op de Delta-tabellen kunnen werken.
• Een dataverbinding: de verbinding waarmee Fabric met Dataverse praat. U kunt die omschakelen naar een workspace identity of een service principal in plaats van een persoonlijk account.

Wijzigingen in Dataverse stromen continu door naar het lakehouse, maar dat is geen realtime. Microsoft documenteert dat het tot een uur kan duren voor wijzigingen zichtbaar zijn, en de eerste synchronisatie van grote tabellen duurt langer. Een sync-engine met lage latentie wordt per regio uitgerold en automatisch ingeschakeld; bestaande links blijven op de oude engine tot u ontkoppelt en opnieuw koppelt (met een volledige hersynchronisatie). De nieuwe engine schrijft rechtstreeks Delta Parquet, gebruikt INT64-tijdstempels en deletion vectors, en laat de kolom createdonpartition weg uit OptionsetMetadata. Controleer dus hoe het daarmee staat in de regio van uw omgeving voor u iemand bijna-realtime dashboards belooft.

De link opzetten

De configuratie zelf is een wizard in Power Apps (make.powerapps.com): kies Link data in de linkernavigatie, vervolgens + New link en de Fabric-optie. U kunt ook starten vanuit Tables via Analyze > Analyze in Fabric. De wizard is snel doorlopen; het zijn de voorwaarden die een project doorgaans vertragen.

1. U hebt de rol System Administrator nodig in de Dataverse-omgeving.
2. U moet beheerder zijn van de doelworkspace in Fabric (Power BI).
3. De workspace moet op een Fabric-capaciteit of Power BI Premium-capaciteit staan; voor een proof of concept volstaat een trialcapaciteit.
4. Een Fabric-beheerder moet in de tenantinstellingen het aanmaken van items en workspaces toestaan, evenals toegang tot OneLake-data vanuit apps buiten Fabric.
5. Beslis vooraf over de authenticatie. Microsoft raadt een workspace identity aan; die moet als application user in Dataverse worden toegevoegd met een gepaste rol.
6. Controleer de tabelselectie. Standaard wordt elke niet-systeemtabel met Track changes geselecteerd. Haal weg wat u niet nodig hebt voor u afrondt.

Alle voorwaarden en opties staan in de stapsgewijze configuratiedocumentatie van Microsoft.

Link to Fabric vs. Azure Synapse Link vs. het TDS-endpoint

Link to Fabric is niet de enige manier om CE-data in een analyseplatform te krijgen. In de praktijk weeg ik de functie af tegen Azure Synapse Link for Dataverse (in de Power Apps-interface intussen Link to Data lake genoemd) en het alleen-lezen TDS-endpoint (SQL). Ze lossen verschillende problemen op.

Mijn vuistregel

• Kies Link to Fabric wanneer de organisatie Fabric al gebruikt (of ernaartoe beweegt) en u CE-data naast financiële, web- of productdata wilt zetten zonder een pipeline te moeten onderhouden.
• Kies Azure Synapse Link wanneer er een uitgebouwd Azure-dataplatform is, wanneer data moet landen in een storage account dat de klant zelf bezit, of wanneer downstream-tools rechtstreeks bestanden lezen. Gebruik de Delta/Parquet-optie; CSV-profielen kunnen later niet aan Fabric worden gekoppeld.
• Gebruik het TDS-endpoint voor ad-hoconderzoek en bescheiden rapporten waarbij het respecteren van de Dataverse-beveiliging van elke gebruiker belangrijker is dan volume. Query's zijn onderworpen aan een time-out en aan de service protection limits.
• Behoud exports en integraties voor operationele gegevensuitwisseling. Fabric dient voor analyse; als een ander systeem CE-data nodig heeft om een proces uit te voeren, gebruik dan een echte integratie in plaats van uit het lakehouse te lezen.

Meer details over de alternatieven vindt u in de documentatie over Azure Synapse Link for Dataverse en het TDS-endpoint (SQL).

Met de data werken

Zodra de eerste synchronisatie klaar is, verschijnen de tabellen in het lakehouse met hun logische Dataverse-namen (account, opportunity, incident enzovoort). Analisten kunnen ze bevragen met T-SQL via het SQL analytics endpoint, met Spark in een notebook, of via het semantisch model in Power BI.

T-SQL op het SQL analytics endpoint

Keuzekolommen bevatten enkel de numerieke waarde. De labels staan in aparte metadatatabellen (OptionsetMetadata voor lokale keuzes, GlobalOptionsetMetadata voor globale, plus StateMetadata en StatusMetadata). Het voorbeeld hieronder koppelt een eigen lokale keuzekolom op account aan het Engelse label en vat de openstaande pipeline per segment samen.

-- 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 in een Fabric-notebook

Voor zwaardere transformaties koppelt u een notebook aan het lakehouse en werkt u rechtstreeks met de Delta-tabellen. Een gangbaar patroon is de bewerkte resultaten weg te schrijven naar een apart lakehouse dat u zelf beheert, in plaats van het lakehouse te wijzigen dat Dataverse beheert.

# 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")

Behandel het gekoppelde lakehouse als een alleen-lezen bronlaag. Bouw ernaast uw eigen bewerkte laag, zodat een herkoppeling of een schemawijziging in Dataverse niet alle rapporten tegelijk breekt. Het schema van de metadatatabellen voor keuzes staat beschreven in de documentatie over keuzelabels.

Beveiliging: Dataverse-rollen volgen de data niet

Dit punt breng ik in elk project ter sprake. In Dataverse bepalen beveiligingsrollen, business units, teameigendom, delen en beveiliging op veldniveau wat een gebruiker ziet. De link zelf leest Dataverse via de identiteit van de verbinding, die doorgaans de rol System Administrator heeft. In Fabric wordt de toegang geregeld door workspacerollen en OneLake-beveiliging, niet door de Dataverse-rechten van de gebruiker.

Hoe ik het aanpak

• Beperk de workspacerollen: houd de rollen Admin, Member en Contributor voor het datateam. Rapportgebruikers krijgen toegang tot rapporten of apps, niet tot de workspace.
• Gebruik OneLake-beveiliging voor datatoegang: waar analisten rechtstreekse toegang nodig hebben, definieert u rollen op het lakehouse of op specifieke tabellen in plaats van alles open te zetten.
• Bouw row-level security opnieuw op in het semantisch model: als rapporten eigenaarschap of business unit moeten respecteren, modelleert u dat expliciet in Power BI. Het wordt niet overgenomen uit Dataverse.
• Wees selectief met gevoelige tabellen: kolommen die in Dataverse met beveiliging op veldniveau beschermd zijn, verdienen hier dezelfde aandacht. Hebt u een tabel niet nodig voor analyse, koppel ze dan niet.
• Denk aan de GDPR: de replica bevat persoonsgegevens. Neem ze op in uw register van verwerkingsactiviteiten en controleer hoe verwijderingen en bewaartermijnen in Dataverse doorwerken in de bewerkte lagen die u downstream bouwt.

Het beveiligingsmodel van Fabric zelf wordt uitgelegd in het overzicht van OneLake-beveiliging.

Kostenoverwegingen

Link to Fabric wordt voorgesteld als 'zonder ETL', en dat klopt, maar gratis is het niet. Er spelen twee meters.

• Dataverse-databasecapaciteit: de Delta Parquet-replica telt mee voor uw Dataverse-databasecapaciteit en is zichtbaar in de capaciteitsrapporten van het Power Platform-beheercentrum. Grote tabellen zoals activiteiten, e-mail of omvangrijke eigen tabellen tellen snel op.
• Fabric-capaciteit: elke query, notebookrun, vernieuwing van een semantisch model en interactie met een rapport verbruikt capaciteitseenheden. Een drukke Power BI-workload op een kleine capaciteit wordt afgeremd.
• Tabelselectie: alleen gekoppelde tabellen verbruiken opslag. Omdat de wizard standaard elke tabel met change tracking selecteert, is de goedkoopste optimalisatie gewoon de tabellen weghalen die niemand nodig heeft. Houd ook rekening met de limiet van 2.000 actieve tabellen en met de limiet van 200 MiB per record, die vooral bij e-mail- en activiteitentabellen opduikt.
• Omgevingsstrategie: elke sandbox koppelen verdubbelt de opslag voor weinig voordeel. In de meeste projecten koppel ik productie en één niet-productieomgeving voor de ontwikkeling van rapporten.

Controleer voor u de link in productie activeert het huidige verbruik van de databasecapaciteit, schat de omvang van de tabellen die u wilt koppelen en spreek af wie de Fabric-capaciteit betaalt. Dat gesprek is een stuk eenvoudiger vóór de opslagwaarschuwing binnenkomt.

Valkuilen die ik tegenkwam

De meeste problemen zijn geen bugs, maar gedocumenteerd gedrag dat gemakkelijk over het hoofd wordt gezien.

• Track changes niet ingeschakeld: tabellen zonder change tracking kunnen niet worden gekoppeld. Schakel het in op uw eigen tabellen als onderdeel van uw solution, niet manueel in productie.
• Datatypes van kolommen wijzigen: het type of de precisie van een gesynchroniseerde kolom wijzigen (bijvoorbeeld van geheel getal naar decimaal) breekt de deltasynchronisatie van die tabel, en die fout herstelt zich niet vanzelf. Ook de kolom verwijderen en opnieuw aanmaken met dezelfde naam lost het niet op. De enige oplossing is de tabel uit de link verwijderen en opnieuw toevoegen, wat een volledige hersynchronisatie uitlokt.
• Nieuwe kolommen verschijnen niet: gebruik na het toevoegen van kolommen Refresh Fabric tables op de link; de wijziging verschijnt bij de volgende datawijziging in die tabel.
• Ontkoppelen met afhankelijkheden: ontkoppelen verwijdert het lakehouse, en Fabric verwijdert geen lakehouse zolang pipelines of semantische modellen ernaar verwijzen. Zoek de afhankelijke items eerst op via de lineage-weergave.
• De naam van het lakehouse hardcoderen: Microsoft waarschuwt uitdrukkelijk dat het formaat van de gegenereerde naam kan wijzigen. Verwijs naar de workspace en het lakehouse via hun ID.
• Afgeschermde workspaces: workspaces die inkomend verkeer beperken tot private links of geselecteerde netwerken, kunnen niet met Link to Fabric worden gebruikt. Betrek het netwerkteam tijdig.
• Realtime data verwachten: voor operationele dashboards die de laatste minuten moeten weerspiegelen, bevraagt u Dataverse rechtstreeks of gebruikt u het TDS-endpoint.

Veel van deze beperkingen staan in de FAQ over Link to Fabric.

Conclusie

Link to Fabric haalt het grootste deel van het loodgieterswerk weg dat vroeger tussen Dynamics 365 Customer Engagement en een volwaardig analyseplatform zat. Voor organisaties die al in Fabric investeren, is het vandaag mijn standaardaanbeveling voor CE-rapportering op schaal.

Behandel het als een architectuurbeslissing en niet als een vinkje: kies de workspace bewust, houd de toegang strikt omdat de Dataverse-beveiliging niet met de data meereist, volg de Dataverse-capaciteit op en bouw bovenop het gekoppelde lakehouse uw eigen bewerkte laag. Dan krijgt u CE-analyses zonder een pipeline die u moet onderhouden.