De data was er. De rapporten waren leeg: een incident rond eigenaarschap in Fabric

door: Tiger An

Vandaag begon een van onze Fabric-pipelines in productie plotseling te falen met deze melding:

“Het ophalen van het MWC-token voor toegang tot de opslag is mislukt… Er is een probleem met het Microsoft Entra ID-token. Laat de eigenaar van het Warehouse opnieuw inloggen. Als die niet beschikbaar is, gebruik dan de overnamefunctie.”

De foutmelding in de pipeline

Op het eerste gezicht leek het een probleem met de pipeline of de Warehouse-verbinding. Dat was het echter niet en de manier waarop het misging, leerde me twee lessen.

Laag voor laag testen

Onze opzet is eenvoudig: Dynamics 365 F&O-data komt binnen in een Fabric Lakehouse. Een ETL-proces in het Warehouse leest die data via het SQL analytics endpoint van het Lakehouse om de rapportagetabellen opnieuw op te bouwen.

In plaats van “de pipeline is mislukt” als één probleem te behandelen, testte ik elke laag afzonderlijk:

• Bron → Lakehouse: de D365 F&O-data was binnengekomen.
• Lakehouse: ik kon het openen en de tabellen bekijken.
• Warehouse: query’s op het Warehouse zelf werkten normaal.
• SQL analytics endpoint: het opvragen van dezelfde Lakehouse-tabellen via T-SQL mislukte met de MWC-/Entra ID-tokenfout.

De data was er, en het Lakehouse was toegankelijk. Maar het SQL analytics endpoint kon de Lakehouse-opslag niet bereiken.

De aanwijzing: eigenaarschap

De foutmelding zelf gaf de aanwijzing: “laat de eigenaar opnieuw inloggen … gebruik de overnamefunctie.”
Het Lakehouse was eigendom van een andere gebruiker. In de modus voor gedelegeerde identiteit maakt het SQL analytics endpoint verbinding met OneLake met de identiteit van de eigenaar van het item, niet die van de persoon die de query uitvoert (Microsoft Learn). Wanneer het Entra ID-token van die eigenaar niet meer kan worden opgehaald, kan het endpoint het benodigde opslagtoken (MWC) niet verkrijgen — ook al kunnen anderen het Lakehouse nog zonder problemen in de browser openen.

Microsoft beschrijft de gebruikelijke aanleiding: als een eigenaar de organisatie verlaat of meer dan 90 dagen niet inlogt, kunnen items waarvan die persoon eigenaar is niet meer goed werken (Eigenaarschap van Fabric-items overnemen).

Daarom trad de fout op bij precies één querypad.

De oplossing

Neem het eigenaarschap van het Lakehouse over:

1. Open de instellingen van het Lakehouse
2. Ga naar het tabblad About
3. Selecteer de optie Take over.
4. Voer opnieuw een eenvoudige SELECT-query uit via het SQL analytics endpoint om te controleren of de toegang tot de opslag is hersteld.
5. Voer de pipeline opnieuw uit en controleer de rapportagetabellen.

Let op: Het is belangrijk om hierbij het bovenliggende Lakehouse over te nemen. Onderliggende onderdelen, zoals het SQL analytics endpoint, kunnen niet afzonderlijk worden overgenomen. Zij volgen het eigenaarschap van het Lakehouse.

Dit herstelt de toegang, maar lost het onderliggende ontwerpprobleem nog niet op. Met Take over wordt het eigenaarschap toegewezen aan de gebruiker die op dat moment is ingelogd. De afhankelijkheid wordt dus verplaatst naar een andere persoon.

Voor productieomgevingen is dat kwetsbaar. Eigenaarschap moet daarom bewust worden ingericht en beheerd, in plaats van toevallig bij één individuele gebruiker te liggen.

 

De grotere les: eerst TRUNCATE, dan lezen

Het eigenaarschapsprobleem verklaarde waarom de bron niet meer kon worden gelezen. Het verklaarde nog niet waarom de rapportagetabellen volledig leeg waren. Ons ETL-proces deed het volgende:

1. De doeltabellen leegmaken met TRUNCATE — ✅
2. De bron lezen via het SQL analytics endpoint — ❌
3. Data invoegen in de doeltabellen — nooit uitgevoerd.

Het resultaat: de rapportagetabellen in productie bleven leeg. Een tijdelijk authenticatieprobleem was een data-incident in productie geworden.

Een veiliger laadpatroon

Een veiliger patroon is om eerst vast te stellen dat de bron bereikbaar en leesbaar is. Daarna wordt de nieuwe data in een tijdelijke tabel of stagingomgeving geladen. Pas wanneer die stap volledig is geslaagd, worden de bestaande rapportagetabellen vervangen.

Vereenvoudigd ziet dit patroon er als volgt uit:

Als het lezen van de bron of het laden naar staging mislukt,, behouden de rapportagetabellen de data van gisteren in plaats van deze leeg te raken. Verouderde data is beter dan geen data.

Belangrijkste lessen

1. Onderzoek problemen in Fabric laag voor laag.
   Een mislukte pipeline is alleen het zichtbare eindresultaat. Test daarom ieder onderdeel afzonderlijk: Pipeline → Warehouse → SQL analytics endpoint → Lakehouse → OneLake. Dat het Lakehouse de data kan lezen, betekent niet automatisch dat het SQL analytics endpoint dat ook kan.
2. Behandel het eigenaarschap van items als een productieafhankelijkheid.
   Controleer wie eigenaar is van de Lakehouses en andere Fabric-items achter productierapportages. Productie-items die eigendom zijn van een persoonlijk account zullen uitvallen als die persoon 90 dagen niet inlogt of de organisatie verlaat. Om dezelfde reden pleitte ik in mijn artikel over Workspace Identity voor sleutelloze identiteiten die niet aan een persoon zijn gekoppeld.
3. Controleer de bron vóór elke stap die data verwijdert.
   Een TRUNCATE gevolgd door een mislukte leesactie is hoe een tijdelijke authenticatiefout je rapporten leegmaakt.

Data hebben is niet hetzelfde als toegang hebben
In moderne dataplatforms zijn beschikbaarheid van data en toegang tot data via een specifiek querypad niet hetzelfde.

Controleer daarom niet alleen of de data in Microsoft Fabric aanwezig is. Controleer ook:

• via welke identiteit productieprocessen de data benaderen;
• wie eigenaar is van de achterliggende Fabric-items;
• wat er met de bestaande rapportagedata gebeurt als een laadactie halverwege mislukt.

Wie is op dit moment eigenaar van de Lakehouses achter jouw productierapporten? Een controle van twee minuten meer dan waard.