Microsoft Fabric & OneLake – Integrationshandbuch

Version: Oktober 2026 (ab Release 1.3)
Zielgruppe: Datenbank-Entwickler, Data Engineers, Administratoren
Voraussetzung: Zugriff auf das MDM Lite als Admin oder Editor; Microsoft Fabric Workspace mit Contributor-Rolle

Inhaltsverzeichnis

1. Überblick & Integrationspfade
2. Der Tabellenvertrag
3. Voraussetzungen
4. Teil A – OneLake Shortcut (Delta-Export) 4a. Teil A2 – Direkt-Export nach OneLake (ohne Shortcut) 4b. Pro Umgebung einrichten
5. Teil B – MDM Lite → Fabric Pull (Connect to DWH)
6. Teil C – Fabric → MDM Lite Push (Upload from DWH)
7. Teil D – Bulk-Sync-Notebook
8. Einmalige Umstellung bestehender Tabellen 8a. Release-Note: Stabile Zeilen-IDs in API und MCP
9. Sicherheitshinweise 9a. Klassifizierung und Rückzug
10. Fehlerbehebung
11. API-Referenz (Bereitstellungs-Endpunkte)

1. Überblick & Integrationspfade

Das MDM Lite bietet fünf Wege, Referenzdaten mit Microsoft Fabric auszutauschen. Auf allen Wegen außer Teil C entsteht für dasselbe Dataset im selben Bereitstellungsmodus dieselbe Tabelle — Name, Spalten, Typen, Systemspalten und Zeilen sind identisch, unabhängig vom gewählten Weg (siehe Kapitel 2 – Der Tabellenvertrag).

Empfehlung: Teil B (Pull über die Bereitstellungstabelle) ist der empfohlene Weg für laufende DWH-Synchronisation. Zwischen Teil A und Teil A2 entscheidet vor allem, ob ein Service Principal mit Workspace-Schreibzugriff eingerichtet werden kann (dann A2 — kein Zwischen-Storage, kein Shortcut) oder nicht (dann A — funktioniert mit jedem ADLS-Gen2-Account). Teil A und Teil A2 schließen sich gegenseitig aus: pro Mandant ist immer nur einer der beiden aktiv (Einstellungen → Microsoft Fabric → Option B/C, siehe Abschnitt 4a).

2. Der Tabellenvertrag

Jede Bereitstellungstabelle — egal auf welchem Weg — folgt demselben Vertrag. Der Vertrag hat eine eigene Versionsnummer (mdmlite.contractVersion, aktuell 1); eine spätere Vertragsänderung schreibt alle Tabellen bei der nächsten Bereitstellung neu.

Tabellenname und Spalten

Der Tabellenname ist der technische Name des Datasets. Die Spaltenreihenfolge:

1. Fachliche Spalten — im Modus „Aktueller Stand" die Spalten des Schema-Snapshots der ausgelieferten Version, in Schema-Reihenfolge; im Modus „Vollständige Historie" die Vereinigung aller je bereitgestellten Spalten über die Auslieferungsfolge.
2. Systemspalten (siehe unten), in fester Reihenfolge hinter den fachlichen Spalten.

Spaltennamen, die (ohne Beachtung der Groß-/Kleinschreibung) mit rdm_ beginnen, sind für fachliche Spalten reserviert und werden beim Anlegen abgelehnt (422 column_name_reserved_prefix).

Datentypen

Ein Wert, der sich nicht in den Vertragstyp umwandeln lässt, bricht die Bereitstellung mit delivery_value_conversion_failed ab — er wird nie still zu null. Ändert eine Spalte im Verlauf der Historie ihren Typ, wird sie im Vertrag zu string (verlustfrei, kanonische Textform).

Systemspalten

Entfallen gegenüber früheren Tabellen: Die Spalte rdm_row_id gibt es im neuen Vertrag nicht mehr — sie war je Version neu und damit als stabiler Zeilen-Identifier ungeeignet. Views, die rdm_row_id gelesen haben, müssen auf rdm_record_id (stabil über Neuschreiben hinweg, solange sich der Datensatz inhaltlich nicht ändert) umgestellt werden. Details zur einmaligen Umstellung: Kapitel 8.

Zusätzlich trägt jede Tabelle die Tabelleneigenschaften mdmlite.contractVersion, mdmlite.datasetId, mdmlite.deliveryMode, mdmlite.deliveredVersion und mdmlite.deliveryCeiling (Delta: TBLPROPERTIES). mdmlite.deliveryCeiling nennt
höchste Klassifizierung für die Bereitstellung, mit der die Tabelle geschrieben wurde (public, internal, confidential oder restricted), also bis zu welcher Sensitivitätsstufe die Tabelle Spalten enthält; nach einer Änderung der höchsten Klassifizierung trägt die Tabelle den neuen Wert ab ihrer nächsten Bereitstellung, und Tabellen aus der Zeit vor dieser Eigenschaft erhalten sie ebenfalls bei der nächsten Bereitstellung. Im Modus „Vollständige Historie" kommen mdmlite.historyStartsAtVersion (erste ausgelieferte Version, die noch in der Tabelle steckt) und mdmlite.historyTruncated hinzu — Letztere ist immer gesetzt (true/false, nicht nur bei tatsächlich abgeschnittener Historie): false heißt „lückenlos bis zur ersten je ausgelieferten Version", true heißt „ältere Versionen wurden durch die Aufbewahrungsregel bereits entfernt". Beide Werte lassen sich mit SHOW TBLPROPERTIES <Tabelle> bzw. DESCRIBE DETAIL <Tabelle> prüfen.

Welche Spalte kommt in den Vertrag? Eine fachliche Spalte gehört zum Vertrag, sobald sie in mindestens einer Version der Auslieferungsfolge bereitgestellt war (ihre Sensitivitätsstufe lag in dieser Version bei oder unter
höchsten Klassifizierung für die Bereitstellung) — unabhängig davon, welche Stufe sie heute im aktuellen Schema hat. Im Modus „Aktueller Stand" umfasst die Auslieferungsfolge nur die heute ausgelieferte Version; die Regel wirkt dort wie eine einfache Prüfung gegen deren Stand. Diese Regel gilt für alle drei Modi identisch (auch „Aktueller Stand") — eine Spalte kann also nicht auf einem Weg erscheinen und auf einem anderen fehlen.

Beispiel-SQL je Modus

-- Aktueller Stand: heute fachlich gültige Zeilen
SELECT * FROM kostenstellen
WHERE rdm_valid_from <= current_date
  AND (rdm_valid_to IS NULL OR rdm_valid_to >= current_date)

-- Vollständige Historie: aktueller Stand, aus der Historie abgeleitet
SELECT * FROM kostenstellen_history WHERE rdm_is_current

-- Vollständige Historie: Stand zu einem beliebigen Zeitpunkt (z. B. Monatsabschluss)
SELECT * FROM kostenstellen_history
WHERE rdm_delivered_at <= '2026-06-30T23:59:00.000Z'
  AND (rdm_delivered_to IS NULL OR rdm_delivered_to > '2026-06-30T23:59:00.000Z')

Die drei Modi und ihre jeweilige Tabellenform am durchgehenden Beispiel: Benutzerhandbuch, „Die Modi am Beispiel". Wie Sie den Modus je Dataset einstellen: Benutzerhandbuch, „Den Bereitstellungsmodus wählen".

Alleiniger Schreiber: MDM Lite schreibt bei jeder Bereitstellung einen vollständigen Neuschreibe-Commit (kein MERGE/Append). Führen Sie auf diesen Tabellen keine eigenen OPTIMIZE- oder VACUUM-Jobs aus — ein fremder Commit lässt die nächste Bereitstellung mit einer klaren Fehlermeldung abbrechen, statt die Tabelle zu überschreiben oder zu beschädigen (siehe Fehlerbehebung). Der vorherige Tabellenstand bleibt nach jedem Neuschreiben noch 7 Tage per Delta-Zeitreise erreichbar — außer nach einem Rückzug klassifizierter Spalten: dann löscht MDM Lite die abgelösten Dateien sofort.

3. Voraussetzungen

MDM Lite

• Rolle Admin für die Konfiguration von Integrationen und API-Keys
• Rolle Editor (oder höher) zum Ausführen der Wizards und Generieren von Notebooks
• Feature-Flag FabricOneLake muss für Ihren Mandanten aktiviert sein (wenden Sie sich bei Bedarf an Ihren MDM-Lite-Administrator)

Microsoft Fabric / Azure

• Aktiver Microsoft Fabric Workspace mit mindestens Contributor-Rolle
• Für Teil A und D zusätzlich: Azure-Abonnement mit Berechtigung zum Anlegen oder Nutzen eines Storage Accounts
• Für Teil A2 stattdessen: aktive Fabric-Kapazität (F-SKU), ein schema-fähiges Lakehouse und ein Service Principal (App-Registration) mit Workspace-Rolle Contributor/Member bzw. OneLake-RBAC ReadWrite auf dieses Lakehouse — siehe Abschnitt 4a

Nicht benötigt

Teil B und Teil C (Notebook-Generierung und -Download) erfordern keinen Azure Storage Account — nur den API-Key und einen Fabric Workspace. Teil A2 erfordert ebenfalls keinen Storage Account (dafür aber einen Service Principal).

4. Teil A – OneLake Shortcut (Delta-Export)

Dieser Bereitstellungsweg schreibt die Bereitstellungstabelle des Datasets als Delta-Tabelle (Parquet-Datendatei plus _delta_log/-Transaktionsprotokoll) in einen Azure Data Lake Storage Gen2 Container. Der Zielordner trägt den technischen Namen des Datasets (nicht seine GUID) — siehe Technischer Tabellenname im Benutzerhandbuch. Über einen OneLake Shortcut auf diesen Ordner erscheint das Dataset in Fabric unter Tables/ als benannte, sofort abfragbare Tabelle — nicht nur als Datei unter Files/.

Fabric-Namensregeln (wichtig)

Microsoft Fabric erkennt einen Ordner nur dann als Tabelle, wenn jedes Pfadsegment unterhalb von Tables/ ein gültiger Bezeichner ist: nur [A-Za-z0-9_], keine Bindestriche, keine führende Ziffer. Verstößt auch nur ein Segment dagegen (Pfad-Präfix oder Ordnername), listet Fabric den gesamten Inhalt unter Tables → Unidentified statt als erkannte Tabelle — mit dem Hinweis "Unable to identify these objects as tables or views".

Das MDM Lite hält deshalb zwei Pfadsegmente strikt auf snake_case-kompatible Bezeichner:

• Technischer Name (Ordnername): ein eigenes, persistiertes Feld pro Dataset (Dataset.TechnicalName, Benutzerhandbuch) — Buchstaben, Ziffern und Unterstriche, darf nicht mit einer Ziffer beginnen, max. 64 Zeichen, je Mandant und Umgebung eindeutig (ohne Beachtung der Groß-/Kleinschreibung). Beim Anlegen schlägt MDM Lite ihn aus dem Dataset-Namen vor: Kleinschreibung, deutsche Umlaute transliteriert (ä→ae, ö→oe, ü→ue, ß→ss), jede Folge anderer Zeichen zu einem einzelnen _ zusammengefasst, führende/abschließende _ entfernt; beginnt das Ergebnis mit einer Ziffer, wird t_ vorangestellt. Anders als bis Mitte 2026 wird dieser Name nicht mehr bei jedem Export neu aus dem (jederzeit änderbaren) Dataset-Namen abgeleitet — er ist gespeichert und ändert sich nur, wenn ein Admin ihn im Tab „Integration" bewusst ändert.
• Pfad-Präfix (Schema): wird standardmäßig aus dem Mandantennamen abgeleitet (siehe A4) — ebenfalls nach denselben Regeln in einen gültigen Bezeichner umgewandelt.

Ein bereits gespeicherter Pfad-Präfix wird beim Bearbeiten immer respektiert; das MDM Lite validiert bei jedem Speichern, dass jedes durch / getrennte Segment dem Muster ^[a-z_][a-z0-9_]*$ entspricht, und weist ungültige Eingaben (z. B. Bindestriche) mit einer klaren Fehlermeldung zurück.

A1 – Azure Storage Account anlegen

1. Öffnen Sie das Azure Portal und navigieren Sie zu Storage accounts → Erstellen.

2. Wählen Sie folgende Einstellungen:

   Einstellung	Wert	Hinweis
   Performance	Standard	Premium nicht nötig
   Redundanz	LRS oder höher	LRS reicht für Exportdaten
   Hierarchischer Namespace	Aktiviert	Pflicht — macht den Account zu ADLS Gen2; ohne diese Einstellung funktionieren OneLake Shortcuts nicht
   Minimales TLS	1.2	MDM Lite erzwingt HTTPS

   Achtung: Der hierarchische Namespace kann nach der Erstellung des Accounts nicht mehr nachträglich aktiviert werden. Achten Sie darauf, ihn beim Erstellen einzuschalten.

3. Account erstellen und warten, bis er bereitgestellt ist.

A2 – Container erstellen

1. Im Storage Account: Container → + Container
2. Name vergeben, z. B. mdm-lite-exports
3. Öffentliche Zugriffsebene: Privat
4. Containernamen notieren — er wird im nächsten Schritt benötigt.

A3 – SAS-Token generieren

1. Im Storage Account links auf Shared access signature klicken.

2. Konfigurieren Sie das Token wie folgt:

   Einstellung	Wert
   Zulässige Dienste	Blob
   Zulässige Ressourcentypen	Container + Objekt
   Zulässige Berechtigungen	Lesen, Schreiben, Löschen, Auflisten, Hinzufügen, Erstellen, Aktualisieren
   Zulässige Protokolle	Nur HTTPS
   Ablaufdatum	Mindestens 1 Jahr in der Zukunft; vor Ablauf rotieren

3. SAS und Verbindungszeichenfolge generieren klicken.

4. Den Wert aus dem Feld SAS-Token kopieren (beginnt mit sv=).

   Wichtig: Der SAS-Token wird nur einmal angezeigt. Speichern Sie ihn sicher. Das MDM Lite verschlüsselt ihn und zeigt ihn nach dem Speichern nicht mehr im Klartext an.

A4 – OneLake-Integration im MDM Lite konfigurieren

Voraussetzung: Admin-Rolle

Navigation: Einstellungen → Integrationen → OneLake

Füllen Sie das Formular aus:

In einem schema-fähigen Lakehouse (Tables/<schema>/<tabelle>/) wird dieses Präfix zum Schemanamen — ein Präfix pro Mandant ergibt so ein sauberes Ein-Schema-pro-Mandant-Modell. Das Präfix muss (wie der Dataset-Slug) ein gültiger Fabric-Bezeichner je Pfadsegment sein; das MDM Lite lehnt Eingaben mit Bindestrichen oder führender Ziffer beim Speichern ab.

Klicken Sie auf Speichern. Das SAS-Token-Feld wird sofort nach dem Speichern maskiert.

A5 – Verbindung testen

Klicken Sie auf Verbindung testen. Das MDM Lite schreibt kurz in den Container und löscht den Test-Blob danach. Eine grüne Bestätigung zeigt an, dass die Zugangsdaten korrekt sind.

Häufige Fehlerursachen:

• Falscher Kontoname (nur der Name, keine vollständige URL)
• Tippfehler im Containernamen (achten Sie auf Groß-/Kleinschreibung — Container sind immer kleingeschrieben)
• SAS-Token abgelaufen oder fehlende Schreibberechtigung

A6 – Dataset exportieren

1. Öffnen Sie ein veröffentlichtes Dataset.

2. Klicken Sie auf Exportieren → Export to OneLake.

3. Das MDM Lite konvertiert die aktuelle Datasetversion in eine Snappy-komprimierte Parquet-Datei und schreibt eine vollständige Delta-Tabelle (Datendatei + _delta_log/-Commit) unter folgendem Ordner:

   https://<konto>.blob.core.windows.net/<container>/<pfad-präfix><technischer-name>/
     part-00000-<guid>.snappy.parquet
     _delta_log/00000000000000000000.json
   

   Der Ordnername ist der technische Name des Datasets — z. B. filialhierarchie oder t_100_percent_kostenstellen. Er ist gespeichert und je Mandant und Umgebung eindeutig; eine erneute Kollisionsauflösung beim Export findet nicht mehr statt. Jeder erneute Export schreibt einen neuen Delta-Commit (Voll-Snapshot, siehe Kapitel 2): Die vorherige Datendatei wird per remove-Aktion abgelöst, aber nicht sofort gelöscht — sie bleibt noch 7 Tage liegen (Delta-Zeitreise auf den vorherigen Stand), bevor ein späterer Bereitstellungslauf sie endgültig entfernt. Enthielt die Tabelle zurückgezogene, inzwischen höher eingestufte Spalten, stehen deren Werte in diesen Dateien noch bis zu 7 Tage — siehe Kapitel 9a. Die neue Datendatei wird per add-Aktion veröffentlicht — Fabric-Leser sehen nie einen halb geschriebenen Zustand. MDM Lite ist alleiniger Schreiber dieser Tabelle: Ein fremder Commit (z. B. durch OPTIMIZE/VACUUM) lässt den nächsten Export mit einer klaren Fehlermeldung abbrechen, statt die Tabelle zu überschreiben (siehe Fehlerbehebung).

   Umbenennen des Datasets ändert den Ordner nicht: Der Anzeigename und der technische Name sind getrennte Felder. Benennen Sie das Dataset um, exportiert MDM Lite weiterhin in denselben Ordner. Ändert stattdessen ein Admin bewusst den technischen Namen im Tab „Integration", schreibt der nächste Export in den neuen Ordner — der alte bleibt unverändert im Storage Account stehen und wird nicht automatisch gelöscht (siehe Technischer Tabellenname). Eine berechtigte Person muss ihn dort bei Bedarf manuell entfernen.

   Bestehende Exporte: Für Datasets, die bereits vor diesem Verhalten (Mitte 2026) per OneLake exportiert wurden, wurde der technische Name einmalig aus dem tatsächlichen Ordnernamen des letzten Exports übernommen (BlobPath) — der nächste Export schreibt also in denselben Ordner wie bisher, ohne Migration oder Umbenennung.

   Achtung — manuelle Bereinigung älterer Reste nötig: GUID-Ordner/data.parquet-Reste aus der Zeit vor #786 (vor Einführung der sprechenden Ordnernamen) sind dem MDM Lite nicht zugeordnet und werden nicht automatisch entfernt — sie müssen einmalig manuell im Storage Account gelöscht werden (Container durchsuchen nach GUID-benannten Ordnern mit einer einzelnen data.parquet-Datei ohne _delta_log/).

4. Das Statusbadge auf der Detailseite wechselt auf Exportiert mit Zeitstempel und Zeilenanzahl. Ist der Export älter als die aktuelle Datasetversion, wird er als veraltet markiert.

A7 – OneLake Shortcut in Fabric anlegen

1. Öffnen Sie Ihr Fabric Lakehouse.

2. Klicken Sie auf New shortcut → Azure Data Lake Storage Gen2.

3. Tragen Sie die Verbindungsdaten ein — die exakten Werte werden im Exportstatus-Panel des MDM Lites angezeigt:

   Feld	Wert
   URL (DFS-Endpunkt)	https://<konto>.dfs.core.windows.net
   Authentifizierung	Kontoschlüssel oder SAS-Token (empfohlen: separates, schreibgeschütztes SAS-Token für Fabric)
   Container	Ihr Containername
   Unterpfad	Den Ordnerpfad (Delta-Tabellenordner) aus dem MDM-Lite-Status-Panel, z. B. sales_de_100/filialhierarchie/

4. Den Shortcut direkt unterhalb von Tables/ anlegen (nicht unter Files/) — nur dort erkennt Fabric einen Delta-Ordner automatisch als Tabelle. In einem schema-fähigen Lakehouse landet der Shortcut dadurch unter Tables/<pfad-präfix>/<technischer-name>/; da das Pfad-Präfix ein gültiger Bezeichner ist (siehe Fabric-Namensregeln), wird es dort automatisch zum Schemanamen, und die Tabelle erscheint als <schema>.<tabelle> — sofort per SQL Endpoint / Semantic Model abfragbar (kein manueller Konvertierungsschritt nötig, anders als bei einem einzelnen Parquet-File unter Files/). Landet die Tabelle stattdessen unter Tables → Unidentified, enthält ein Pfadsegment einen ungültigen Bezeichner (Bindestrich oder führende Ziffer) — siehe Abschnitt 10, Fehlerbehebung.

Hinweis: Der Shortcut liest immer den zuletzt veröffentlichten Delta-Snapshot. Nach Dataset-Änderungen im MDM Lite wird der Export entweder automatisch aktualisiert (siehe A8 – Automatischer Export) oder muss manuell neu ausgelöst werden ("Export to OneLake" am Dataset bzw. "Sync now" in den Einstellungen).

A8 – Automatischer Export

Navigation: Einstellungen → Fabric OneLake → Automatischer Export

Damit der Shortcut ohne manuelles Nachtriggern aktuell bleibt, gibt es zwei kombinierbare Automatiken (beide standardmäßig aus):

Empfehlung: Für „die Datenplattform soll immer den aktuellen Stand haben" genügt die erste Option; ein Zeitplan ist dann nicht nötig. Ist keine der beiden Optionen aktiv, bleibt der Fabric-Stand auf dem letzten manuell ausgelösten Export stehen — Änderungen müssen dann über „Export to OneLake" bzw. „Sync now" nachgezogen oder per REST-API von der Datenplattform aktiv abgeholt werden (Pull).

Für beide Automatiken gilt:

• Es werden ausschließlich veröffentlichte Datasets exportiert (dasselbe Gate wie beim manuellen Export).
• Exportiert wird immer die Version, die auch die REST-API ausliefert: die neueste Version, die die Auslieferungs-Validierung bestanden hat und deren Stichtag erreicht ist. Eine fehlerhafte oder erst zukünftig wirksame („geplante") Version wird bewusst nicht exportiert — die Datenplattform behält den ausgelieferten Stand, und der geplante Stand wird automatisch am Stichtag exportiert.
• Bei Massenänderungen (Bulk-Bearbeitung, mehrstufiger Import) wird nicht pro Zwischenversion exportiert: der Hintergrundprozess wartet, bis das Dataset einige Sekunden unverändert geblieben ist, und schreibt dann einen Export mit dem Endstand.
• Jeder automatische Lauf schreibt einen regulären Export-Datensatz inkl. Status/Fehlermeldung und ein Audit-Event (onelake_exported) mit dem Auslöser im Payload: publish (Veröffentlichen), change (Änderung, Akteur system:auto-export) oder schedule (Zeitplan, Akteur system:scheduler).
• Ein fehlgeschlagener automatischer Export wird nicht endlos wiederholt: die nächste Wiederholung erfolgt nach einer Wartezeit (Standard 5 Minuten), bis sie gelingt.
• Wiederholte Läufe überschreiben deterministisch per Delta-Overwrite-Commit (neue Datendatei + remove der alten) — nie halb geschriebene Zustände.
• Jede Umgebung exportiert ausschließlich in ihr eigenes Ziel. Hat eine Umgebung kein Ziel, wird nichts übertragen. Siehe Pro Umgebung einrichten.
• Beim Ändern dieser Optionen muss das SAS-Token nicht erneut eingegeben werden; das gespeicherte Token bleibt erhalten, solange das Feld leer bleibt.

Automatischer Rückzug — auch ohne diese Optionen: Liegt in einer bereits bereitgestellten Tabelle eine Spalte, die inzwischen über
höchsten Klassifizierung für die Bereitstellung liegt (Spalte hochgestuft oder die höchste Klassifizierung abgesenkt), stellt derselbe Hintergrundprozess die Tabelle in der Regel innerhalb von 30 Sekunden ohne diese Spalte neu bereit und löscht die abgelösten Datendateien sofort — unabhängig davon, ob eine der beiden Automatiken aktiv ist (Auslöser retraction, Akteur system:retraction). Details, blockierte Fälle und Rückstände: Kapitel 9a.

Hinweis beim Einschalten: Beim ersten Scan nach dem Aktivieren holt der Hintergrundprozess alle veröffentlichten Datasets nach, deren Fabric-Stand veraltet ist (max. 50 pro Mandant und Scan) — danach nur noch tatsächliche Änderungen.

Betrieb/Konfiguration (Self-Hosting): Der änderungsgetriebene Prozess scannt standardmäßig alle 15 Sekunden (OneLake:ChangeExport:IntervalSeconds, Master-Switch OneLake:ChangeExport:Enabled); weitere Stellschrauben: OneLake:ChangeExport:DebounceSeconds (Ruhezeit vor dem Export, Standard 10), OneLake:ChangeExport:MaxDelaySeconds (höchste Klassifizierung für diese Wartezeit, Standard 600), OneLake:ChangeExport:FailureBackoffSeconds (Standard 300), OneLake:ChangeExport:BatchSize (Standard 50). Der zeitgesteuerte Prozess scannt standardmäßig alle 5 Minuten (OneLake:ScheduledExport:IntervalSeconds, Master-Switch OneLake:ScheduledExport:Enabled, max. Exporte pro Mandant und Scan OneLake:ScheduledExport:BatchSize).

4a. Teil A2 – Direkt-Export nach OneLake (ohne Shortcut)

Dieser Pfad schreibt dieselbe Delta-Tabelle wie Teil A — Snappy-Parquet-Datendatei plus _delta_log/-Transaktionsprotokoll — direkt in das OneLake Ihres Fabric-Workspace, statt in einen kundeneigenen ADLS-Gen2-Container. Die Tabelle erscheint dadurch sofort als managed table im gewählten Lakehouse: kein Zwischen-Storage, kein manueller Shortcut-Schritt, kein Konvertierungsschritt.

Technischer Hintergrund: OneLake ist selbst ein ADLS-Gen2-kompatibler Endpunkt. Der einzige echte Unterschied zu Teil A ist die Authentifizierung — OneLake akzeptiert keine SAS-Tokens, daher meldet sich das MDM Lite über einen Entra-ID-Bearer-Token via Service Principal an, statt ein SAS-Token in die Zugriffs-URL einzubetten.

Teil A und Teil A2 sind Alternativen, kein Sowohl-als-auch: Ein Mandant kann jeweils nur einen der beiden Fabric-Export-Wege aktiv haben. Aktivieren Sie A2, wird eine zuvor aktive Teil-A-Konfiguration automatisch deaktiviert (und umgekehrt) — beide Konfigurationen bleiben dabei gespeichert, sodass ein Wechsel jederzeit ohne erneute Eingabe aller Felder möglich ist.

A2.1 – Service Principal (App-Registration) anlegen

Kein Zugriff auf das Azure Portal des Kunden? Die Schritte A2.1 bis A2.3 erledigt dann die Kunden-IT. Die versandfertige Anleitung dafür: Kunden-IT: MDM Lite Schreibzugriff auf Ihr OneLake einrichten.

1. Im Azure Portal: Microsoft Entra ID → App-Registrierungen → Neue Registrierung.
2. Namen vergeben (z. B. mdm-lite-onelake-export), Standardeinstellungen für Kontotyp und Redirect-URI übernehmen.
3. Nach dem Anlegen: Zertifikate & Geheimnisse → Neuer Clientgeheimnisschlüssel — Ablaufdatum wählen, Wert sofort kopieren (wird nur einmal angezeigt).
4. Übersicht-Seite: Anwendungs-(Client-)ID und Verzeichnis-(Mandanten-)ID notieren.

A2.2 – Workspace-Rolle vergeben

1. Öffnen Sie Ihren Fabric-Workspace → Zugriffsverwaltung (Manage access).
2. Fügen Sie die App-Registration aus A2.1 als Mitglied hinzu, mit Rolle Contributor oder Member.
3. Alternativ (feingranularer): auf dem Ziel-Lakehouse selbst eine OneLake-Data-Access-Rolle mit ReadWrite für den Service Principal vergeben.

A2.3 – Fabric-Admin-Einstellung freigeben

In den Fabric-Mandanteneinstellungen (Admin Portal) muss "Service principals can use Fabric APIs" aktiviert sein — sonst schlägt jeder Zugriff des Service Principal mit 401/403 fehl, unabhängig von der Workspace-Rolle. Diese Einstellung liegt beim Fabric-Tenant-Admin Ihrer Organisation, nicht beim MDM Lite. In neueren Portalversionen heißt sie Service principals can call Fabric public APIs. Ist sie auf Sicherheitsgruppen beschränkt, muss der Service Principal Mitglied einer dieser Gruppen sein.

Zusätzlich muss unter OneLake settings die Einstellung "Users can access data stored in OneLake with apps external to Fabric" aktiviert sein (Standard: an). Ist sie aus, scheitert jeder Schreibzugriff von außerhalb Fabric, also auch der von MDM Lite.

A2.4 – Integration im MDM Lite konfigurieren

Voraussetzung: Admin-Rolle

Navigation: Einstellungen → Microsoft Fabric → Option C: Export via OneLake

Füllen Sie das Formular aus:

Wichtig: Workspace und Lakehouse müssen beide GUIDs oder beide Namen sein. OneLake lehnt gemischte Angaben ab (FriendlyNameSupportDisabled); das MDM Lite weist sie beim Speichern zurück.

Aktivieren Sie Option C und speichern Sie. Eine zuvor aktive Option B (Teil A) wird dabei serverseitig automatisch deaktiviert. Das Client-Secret-Feld wird sofort nach dem Speichern maskiert.

A2.5 – Verbindung testen

Klicken Sie auf Verbindung testen. Das MDM Lite löst über den Service Principal ein Zugriffstoken auf und schreibt/löscht damit kurz eine Testdatei unterhalb von Tables/ im Ziel-Lakehouse.

Häufige Fehlerursachen:

• 401/403: Fabric-Admin-Einstellung aus A2.3 nicht freigegeben, oder die Workspace-/OneLake-Rolle aus A2.2 fehlt bzw. ist zu niedrig.
• Workspace oder Lakehouse existieren nicht oder sind falsch geschrieben (Name oder GUID werden akzeptiert, aber nicht gemischt: Workspace und Lakehouse müssen dieselbe Form haben).
• Client Secret abgelaufen oder falsch kopiert.

A2.6 – Dataset exportieren

Identisch zu A6: Exportieren → Export to OneLake auf einem veröffentlichten Dataset. Der Zielpfad liegt jedoch direkt im OneLake des Workspace, unterhalb des Lakehouse-Artefakts:

https://onelake.dfs.fabric.microsoft.com/<workspace>/<lakehouse>.Lakehouse/Tables/<pfad-präfix><technischer-name>/           (Namen)
https://onelake.dfs.fabric.microsoft.com/<workspace-guid>/<lakehouse-guid>/Tables/<pfad-präfix><technischer-name>/         (GUIDs, ohne .Lakehouse-Suffix)
  part-00000-<guid>.snappy.parquet
  _delta_log/00000000000000000000.json

Namensbildung (technischer Name), Stabilität bei einer Umbenennung des Datasets und Overwrite-Commit-Semantik sind identisch zu Teil A (siehe A6) — nur das Ziel und die Authentifizierung unterscheiden sich. In einem schema-fähigen Lakehouse erscheint die Tabelle sofort als <pfad-präfix>.<technischer-name> — ohne einen Shortcut-Schritt wie in A7.

Automatischer Export (A8) funktioniert für Teil A2 identisch — dieselben Optionen "automatisch exportieren (Veröffentlichung & Änderungen)" und "zeitgesteuerter Export" gelten für die jeweils aktive Konfiguration (Teil A oder Teil A2).

Vergleich: Teil A vs. Teil A2

4b. Pro Umgebung einrichten

Jede Umgebung von MDM Lite hat ihr eigenes Bereitstellungsziel. Eine Umgebung liefert nur in ihr Ziel, nie in das einer anderen Umgebung und nie ersatzweise in das von Live. Hat eine Umgebung kein Ziel, überträgt MDM Lite für sie nichts. Die Konfiguration, das Secret, der automatische Export und der Zeitplan gelten ebenfalls je Umgebung.

Voraussetzungen: Rolle Admin, Entitlement FabricOneLake für den Mandanten und je Ziel die Azure- bzw. Fabric-Einrichtung aus Teil A oder Teil A2. Welche Rechte der Service Principal je Workspace braucht, steht im Leitfaden für die Kunden-IT.

In einer Umgebung ist höchstens ein Ziel aktiv: Storage Account (Option B) oder OneLake direkt (Option C). Aktivieren Sie das eine, deaktiviert MDM Lite das andere derselben Umgebung. Verschiedene Umgebungen dürfen verschiedene Arten verwenden, zum Beispiel „Entwicklung" mit Storage Account und „Produktion" mit OneLake direkt.

Variante 1: Je Umgebung ein eigenes Lakehouse (empfohlen)

Beispiel: drei Umgebungen „Entwicklung", „Test" und „Produktion" mit drei Lakehouses.

Gleiche Namen sind erlaubt, weil sich die Workspaces unterscheiden. Das Ziel ist die Kombination aus Workspace, Lakehouse und Pfad-Präfix.

1. Legen Sie in jedem Workspace ein schema-fähiges Lakehouse an und berechtigen Sie den Service Principal (siehe Kunden-IT-Leitfaden).
2. Wechseln Sie im Benutzermenü in die erste Umgebung, zum Beispiel „Entwicklung".
3. Öffnen Sie Einstellungen → Integrationen → Microsoft Fabric. Die Kontextzeile oben nennt die Umgebung.
4. Klicken Sie auf „Bereitstellung für „Entwicklung" einrichten" und füllen Sie das Formular wie in A2.4 (OneLake direkt) bzw. A4 (Storage Account) beschrieben aus. Verwenden Sie den Workspace dieser Umgebung.
5. Klicken Sie auf Speichern. Bei einer Umgebung, die nicht Live ist, bestätigen Sie beim ersten Aktivieren den Dialog „Bereitstellung in einer Nicht-Live-Umgebung aktivieren?" mit „Aktivieren und Daten übertragen". MDM Lite hält die Bestätigung im Änderungsprotokoll fest.
6. Klicken Sie auf Verbindung testen.
7. Wiederholen Sie die Schritte 2 bis 6 für „Test" und „Produktion".

Verifikation: Die Übersicht „Bereitstellung je Umgebung" auf derselben Seite zeigt eine Zeile je Umgebung mit Art, Ziel und dem Status „Aktiv". Veröffentlichen Sie ein Dataset in „Entwicklung". Die Tabelle erscheint nur im Lakehouse des Workspaces mdm-dev, in mdm-test und mdm-prod nicht.

Variante 2: Ein Lakehouse mit nicht verschachtelten Pfad-Präfixen

Wollen oder können Sie nur ein Lakehouse nutzen, trennen Sie die Umgebungen über das Pfad-Präfix. In einem schema-fähigen Lakehouse wird das Präfix zum Schemanamen.

Gehen Sie vor wie in Variante 1, tragen Sie aber überall dasselbe Lakehouse und je Umgebung ein eigenes Präfix ein. Die Präfixe dürfen nicht verschachtelt sein: dev/ neben test/ ist erlaubt, dev/ neben dev/archiv/ nicht, und ein leeres Präfix kollidiert mit jedem anderen. dev/ und dev2/ gelten als verschieden. Groß- und Kleinschreibung spielt keine Rolle, dev und dev/ sind dasselbe Präfix.

Achtung: Das Formular füllt das Pfad-Präfix beim ersten Öffnen aus dem Mandantennamen vor, in jeder Umgebung mit demselben Wert. Teilen sich zwei Umgebungen ein Lakehouse, lehnt MDM Lite das zweite Speichern ab (siehe unten). Passen Sie das Präfix je Umgebung an.

Zielschutz und Fehlermeldungen

MDM Lite verhindert, dass zwei Umgebungen in dieselben Tabellenordner schreiben und sich gegenseitig überschreiben. Der Schutz greift an zwei Stellen.

1. Beim Speichern: MDM Lite prüft alle aktiven Fabric-Konfigurationen der anderen Umgebungen desselben Mandanten. Ein Konflikt liegt vor, wenn dieselbe Ablage (Workspace und Lakehouse bzw. Konto und Container) verwendet wird und eines der beiden Pfad-Präfixe mit dem anderen beginnt.

2. Beim Schreiben einer Tabelle: Jede Bereitstellungstabelle trägt die Kennung ihres Datasets. Gehört der Ordner einem anderen Dataset, schreibt MDM Lite nichts.

Eine übernommene Tabelle, deren Dataset es in Ihrem Mandanten nicht mehr gibt, übernimmt MDM Lite selbstständig, wenn das Änderungsprotokoll belegt, dass das frühere Dataset zu Ihrem Mandanten gehörte (zum Beispiel nach dem endgültigen Löschen und Neuanlegen mit gleichem technischem Namen). Das Ereignis onelake_exported nennt dann adopted_from_dataset_id.

Ziel einer Umgebung ändern

Ändern Sie Workspace, Lakehouse, Konto, Container oder Pfad-Präfix, gilt das als neues Ziel. Nach dem Speichern zeigt MDM Lite: „Bereits bereitgestellte Tabellen bleiben im bisherigen Ziel. MDM Lite schreibt ab jetzt in das neue Ziel."

1. Speichern Sie das neue Ziel.
2. Warten Sie auf die nächste automatische Bereitstellung oder klicken Sie auf „Jetzt synchronisieren (Umgebung „…")". MDM Lite schreibt alle veröffentlichten Datasets der Umgebung ins neue Ziel.
3. Stellen Sie Lesezugriffe (Shortcuts, Views, Berichte) auf das neue Ziel um.
4. Löschen Sie die Tabellen im alten Ziel manuell. MDM Lite erreicht das alte Ziel nicht mehr. Ein dort ausstehender Rückzug von Spalten bleibt Rückstand.

Deaktivierte und gelöschte Umgebungen

• Deaktivierte Umgebung: Ihre Bereitstellung läuft weiter, auch der Rückzug von Spalten über der höchsten Klassifizierung. Einstellungen ändern und manuell exportieren können Sie nicht (409 environment_inactive). Um die Bereitstellung zu stoppen, reaktivieren Sie die Umgebung kurz, deaktivieren oder löschen die Integration und deaktivieren die Umgebung wieder.
• Gelöschte Umgebung: MDM Lite löscht ihre Integrationen und Secrets mit. Die Tabellen im Ziel bleiben bestehen und müssen dort entfernt werden. Der Lösch-Dialog weist darauf hin.
• Neu angelegte Umgebung: Sie startet ohne Integration.

Konfiguration aus der Zeit vor den Umgebungen

Eine Konfiguration, die noch keiner Umgebung zugeordnet ist, liefert nirgendwohin. Sie erscheint nur in Live, in der API mit environment_unassigned: true. Öffnen Sie in Live Einstellungen → Integrationen → Microsoft Fabric und klicken Sie auf Speichern. Damit gehört die Konfiguration zu Live und liefert wieder. Beim Start schreibt MDM Lite eine Warnung ins Betriebsprotokoll, solange solche Konfigurationen existieren.

Weitere Einstellungen je Umgebung

• MCP-Server (KI-Zugriff): In Nicht-Live-Umgebungen standardmäßig aus, Endpunkt /mcp/{Umgebungs-Slug}. Siehe MCP-Onboarding.
• Notebooks: Die Erzeugung ist in Nicht-Live-Umgebungen standardmäßig aus (Schalter unter Einstellungen → Integrationen → Notebooks).
• API-Keys: Ein Key kann auf eine Umgebung beschränkt werden (Feld Umgebung).

5. Teil B – MDM Lite → Fabric Pull (Connect to DWH)

Das MDM Lite generiert ein vorkonfiguriertes Fabric Notebook, das die Bereitstellungstabelle eines Datasets über die API abruft und als Delta Table in Ihrem Lakehouse überschreibt. Das Notebook kennt weder einen Bereitstellungsmodus noch eine Schlüsselspalte — es überträgt generisch genau die Tabelle, die der Endpunkt liefert (overwrite + overwriteSchema), byte-identisch zu OneLake.

B1 – API-Key anlegen

Navigation: Einstellungen → API-Keys → Neuen Key erstellen

• Name: Aussagekräftiger Name, z. B. fabric-pull-produktkategorien
• Ein für das Notebook angelegter Key erhält automatisch nur den Scope „read" — ausreichend, das Notebook schreibt nie zurück nach MDM Lite.
• Bei
  höchsten Klassifizierung für die Bereitstellung über „Intern" kann ein Lese-Key die Tabelle nicht abrufen — siehe Kapitel 9a. Der Assistent zeigt dazu vorab einen Hinweis.
• Den generierten Key sofort sicher speichern — er wird nur einmal angezeigt (43-stelliger Base64url-String, kein festes Präfix).

Den API-Key nicht im Klartext in das Notebook einfügen. Lesen Sie dazu Abschnitt 9 – Sicherheitshinweise.

B2 – Wizard öffnen

Navigation: Dataset-Detailseite → Connect to DWH

Das Modal öffnet sich mit drei Schritten.

Schritt 1 — Plattform: Microsoft Fabric auswählen.

B3 – Notebook konfigurieren

Schritt 2 — Konfiguration:

B4 – Notebook herunterladen

Schritt 3 — Ergebnis: Klicken Sie auf Download (.ipynb). Die Datei heißt sync_<tabellenname>.ipynb.

B5 – Notebook in Fabric importieren

1. Öffnen Sie Ihren Fabric Workspace.
2. + Neu → Notebook importieren und die heruntergeladene .ipynb-Datei hochladen.
3. Das Notebook erscheint in der Workspace-Übersicht.

B6 – API-Key sicher konfigurieren

Öffnen Sie das Notebook in Fabric. Die Parameterzelle (Zelle 1) enthält einen leeren Platzhalter für den API-Key:

# ===== PARAMETERS — fill in before running =====
RDM_API_BASE      = "https://your-rdm-instance.example.com/api"
# Use notebookutils.credentials.getSecret() or a Fabric secret — do NOT paste the key here
RDM_API_KEY       = ""
DATASET_ID        = "7f1c2a3e-..."   # already prefilled
TARGET_LAKEHOUSE  = "MyLakehouse"    # Lakehouse name
TARGET_TABLE      = "kostenstellen"  # already prefilled with the technical name
SYNC_MODE         = "auto"           # "auto" (skip via 304 if unchanged) or "full" (always rewrite)
WATERMARK_TABLE   = "_rdm_delivery_state"
REQUEST_TIMEOUT_S = 120
PAGE_LIMIT        = 10000
MAX_RETRIES       = 3

Passen Sie RDM_API_BASE, TARGET_LAKEHOUSE und den API-Key an. SYNC_MODE bestimmt nur noch die Übertragungstechnik, nie den Tabelleninhalt:

Der frühere Wert incremental (zeilenweises MERGE per Business Key) entfällt ersatzlos — jede Übertragung schreibt immer die vollständige, aktuelle Bereitstellungstabelle. Ein SYNC_MODE, der weder auto noch full ist, lässt das Notebook mit einem klaren ValueError abbrechen, bevor ein API-Aufruf stattfindet.

B7 – Notebook ausführen

1. Im Notebook-Editor: Explorer → Lakehouse hinzufügen — Ihr Ziellakehouse auswählen.
2. Run All klicken.

Das Notebook führt automatisch folgende Schritte aus:

• Zustandstabelle _rdm_delivery_state anlegen, falls sie noch nicht existiert
• Zuletzt gespeicherten ETag für dieses Dataset lesen
• Die Bereitstellungstabelle über GET …/delivery-table abrufen (alle Seiten; bei 304 in auto-Modus: Lauf ohne Übertragung beenden)
• Die Delta-Tabelle mit den typisierten Zeilen überschreiben (overwrite + overwriteSchema) und die Tabelleneigenschaften (mdmlite.*) setzen
• ETag, ausgelieferte Version und Bereitstellungsmodus in _rdm_delivery_state aktualisieren

B8 – Notebook planen (optional)

Klicken Sie im Fabric Notebook auf Planen. Empfohlene Häufigkeit: täglich zu Nebenzeiten oder stündlich bei häufigen Datenänderungen. Im Standardmodus auto überträgt ein geplanter Lauf ohnehin nur dann etwas, wenn sich die Bereitstellungstabelle seit dem letzten Lauf geändert hat.

6. Teil C – Fabric → MDM Lite Push (Upload from DWH)

Dieser Pfad ist das Gegenstück zu Teil B: Eine Fabric-Lakehouse-Tabelle ist die autoritative Quelle, und das MDM-Lite-Dataset wird regelmäßig damit aktualisiert.

Achtung: Das generierte Notebook schreibt Produktionsdaten in das MDM Lite. Eine falsche Konfiguration kann bestehende Referenzdaten überschreiben. Testen Sie den Ablauf zuerst mit einem Nicht-Produktions-Dataset.

C1 – API-Key mit Schreibzugriff anlegen

Legen Sie einen dedizierten Key pro Dataset an, um Widerrufe gezielt zu halten:

Navigation: Einstellungen → API-Keys → Neuen Key erstellen

Empfohlener Name: dwh-upload-<dataset-name>, z. B. dwh-upload-filialhierarchie

C2 – Wizard öffnen

Navigation: Dataset-Detailseite → Upload from DWH

Das Modal öffnet sich mit fünf Schritten. In Schritt 1 Microsoft Fabric wählen.

C3 – Quelle konfigurieren

Schritt 2 — Quelle:

C4 – Spaltenmapping definieren

Schritt 3 — Spaltenmapping:

Der Wizard zeigt das MDM-Lite-Schema des Datasets. Geben Sie für jede MDM-Lite-Spalte den entsprechenden Spaltennamen aus Ihrer Fabric-Quelltabelle ein:

Pflichtfelder ohne Mapping blockieren den Fortschritt. Nicht gemappte optionale Spalten und unbekannte Quellspalten werden ignoriert.

C5 – Import-Modus konfigurieren

Schritt 4 — Import-Konfiguration:

V1-Limit: Das Notebook sendet alle Zeilen in einem einzigen API-Aufruf. Empfohlenes Maximum: 50.000 Zeilen pro Lauf.

C6 – Notebook herunterladen und importieren

Schritt 5 — Ergebnis: Download (.ipynb) klicken. Dateiname: upload_<dataset_name>.ipynb.

Import in Fabric analog zu Schritt B5.

C7 – Parameterzelle anpassen und ausführen

# ===== PARAMETER =====
RDM_API_BASE     = "https://ihre-rdm-instanz.example.com/api"
RDM_API_KEY      = ""  # notebookutils.credentials.getSecret("kv-name", "rdm-api-key")
DATASET_ID       = "ds_abc123"           # vorbelegt durch Wizard
SOURCE_LAKEHOUSE = "VerkaufsLakehouse"
SOURCE_TABLE     = "dim_filiale"
IMPORT_MODE      = "FULL_REPLACE"        # oder "UPSERT"
WATERMARK_COL    = "geaendert_am"        # leer = immer Full Replace

# Spaltenmapping: MDM-Lite-Spaltenname → Quellspaltenname (vorbelegt durch Wizard)
COLUMN_MAPPING = {
    "filial_nr":   "filialnummer",
    "name":        "filialname",
    "gueltig_ab":  "gueltig_ab",
}

Lakehouse als Quelle im Notebook-Explorer hinzufügen und Run All klicken.

Das Notebook validiert das Spaltenmapping gegen das Live-MDM-Lite-Schema, bevor es die Quelltabelle liest. Fehlende Pflichtfelder führen zu einem Frühzeitfehler, ohne Daten zu übertragen.

7. Teil D – Bulk-Sync-Notebook

Ein einziges Notebook, das alle veröffentlichten, für den verwendeten API-Key lesbaren Datasets Ihres Mandanten über die Bereitstellungstabellen-Übersicht (GET /api/delivery-tables) entdeckt und die seit dem letzten Lauf geänderten parallel in ein Lakehouse überträgt. Wie beim Einzel-Notebook (Teil B) ist die Übertragung generischer Transport — der Modus je Dataset spielt für das Notebook keine Rolle, gemischte Bereitstellungsmodi verarbeitet es ohne Sonderfall.

Voraussetzung: Die OneLake-Speicherintegration muss nicht konfiguriert sein — nur ein API-Key und ein Ziel-Lakehouse.

D1 – Bulk-Sync-Notebook herunterladen

Navigation A: Einstellungen → Integrationen → OneLake → Bulk Sync Now
Navigation B: Dataset Explorer Aktionsleiste → Fabric Bulk-Sync

Ein vereinfachter Wizard mit zwei Schritten öffnet sich.

D2 – Notebook konfigurieren

Download rdm_bulk_sync.ipynb klicken.

D3 – In Fabric importieren und konfigurieren

Notebook in Fabric importieren (wie in Schritt B5).

Parameterzelle anpassen:

# ===== PARAMETERS — fill in before running =====
RDM_API_BASE      = "https://your-rdm-instance.example.com/api"
RDM_API_KEY       = ""   # notebookutils.credentials.getSecret("kv-name", "rdm-api-key")
TARGET_LAKEHOUSE  = "MyLakehouse"
SYNC_MODE         = "auto"   # "auto" (only changed datasets) or "full" (always rewrite all)
WATERMARK_TABLE   = "_rdm_delivery_state"
REQUEST_TIMEOUT_S = 120
PAGE_LIMIT        = 10000
MAX_WORKERS       = 4        # parallel dataset sync threads
MAX_RETRIES       = 3

D4 – Ablauf des Notebooks

1. Zustandstabelle _rdm_delivery_state anlegen, falls sie noch nicht existiert
2. Alle bereitstellbaren Datasets über GET /api/delivery-tables abrufen (alle Seiten); Datasets mit Status ≠ ok (z. B. ceiling_exceeds_key, no_deliverable_version) werden übersprungen und ausgegeben
3. Gegen die zuletzt gespeicherten ETags filtern: In auto-Modus werden nur Datasets mit geändertem ETag übertragen, in full-Modus alle
4. Jedes so gefundene Dataset parallel (bis MAX_WORKERS) über GET …/delivery-table abrufen und als Delta-Tabelle überschreiben, inkl. Tabelleneigenschaften
5. ETag, ausgelieferte Version und Bereitstellungsmodus je erfolgreich synchronisiertem Dataset in _rdm_delivery_state aktualisieren

D5 – Notebook planen

Im Fabric Notebook Planen klicken. Empfohlene Häufigkeit: täglich zu Nebenzeiten.

Im Standardmodus auto verarbeitet das Notebook pro Lauf nur Datasets, deren Bereitstellungstabelle sich tatsächlich geändert hat.

Fehlerverhalten: Schlägt die Übertragung eines einzelnen Datasets fehl, läuft der Gesamtlauf für die übrigen Datasets weiter; am Ende bricht das Notebook mit einer Fehlermeldung ab, die alle fehlgeschlagenen Datasets auflistet. Der Zustand (ETag) eines fehlgeschlagenen Datasets wird nicht aktualisiert — beim nächsten Lauf wird es automatisch erneut versucht, ohne dass zwischenzeitliche Änderungen verloren gehen.

8. Einmalige Umstellung bestehender Tabellen

Der Tabellenvertrag aus Kapitel 2 gilt seit dem Release von September 2026. Da zu diesem Zeitpunkt kein Kunde die Bereitstellung produktiv genutzt hat, gibt es dafür keine Übergangsfrist und keine Kompatibilitätsschicht — bestehende Tabellen werden beim nächsten Bereitstellungslauf mit dem neuen Schema überschrieben, nicht migriert.

Was sich ändert:

• Die Spalte rdm_row_id entfällt ersatzlos. Sie war je Version neu und deshalb als stabiler Zeilen-Identifier ungeeignet — verwenden Sie stattdessen rdm_record_id (stabil über Neuschreiben hinweg, solange sich der Datensatz inhaltlich nicht ändert).
• rdm_valid_from/rdm_valid_to sind jetzt vom Delta-Typ date statt string; Zahlen-Systemspalten sind long (64 Bit).
• Neue Systemspalten kommen hinzu (rdm_sort_order, rdm_version, rdm_delivered_at, im Modus „Vollständige Historie" zusätzlich rdm_version_to, rdm_delivered_to, rdm_is_current).
• Der frühere zeilenbezogene Änderungs-Feed (GET /api/datasets/{id}/changes) und der incremental-Wert für SYNC_MODE entfallen; siehe Kapitel 11 und die Notebook-Kapitel B/D.

Was Sie tun müssen:

1. OneLake (Teil A/A2): Nichts weiter — der nächste automatische oder manuell ausgelöste Export schreibt das neue Schema in denselben Ordner (Overwrite-Commit). Views, Power-BI-Modelle oder SQL-Abfragen, die rdm_row_id oder die alten Spaltentypen verwenden, müssen Sie danach manuell auf den neuen Vertrag umstellen.
2. Notebooks (Teil B/D): Bisher generierte Notebooks funktionieren nicht mehr (der alte zeilenweise Abruf antwortet 410). Öffnen Sie den jeweiligen Assistenten erneut und laden Sie ein neues Notebook herunter; der erste Lauf überschreibt die Zieltabelle vollständig (overwriteSchema). Der alte Watermark-Speicher (_rdm_watermarks, sofern vorhanden) bleibt ungenutzt liegen und kann manuell gelöscht werden.
3. Test- und Produktivumgebung: Beide stellen sich unabhängig voneinander automatisch um, sobald dort das nächste Mal bereitgestellt wird.

Details zu den einzelnen Spalten und Typen: Kapitel 2 – Der Tabellenvertrag.

8a. Release-Note: Stabile Zeilen-IDs in API und MCP

Diese Änderung betrifft nicht die Bereitstellungstabelle aus Kapitel 2 (dort heißt der stabile Zeilenschlüssel bereits rdm_record_id, siehe Kapitel 8). Sie betrifft die versionierten Lese-Endpunkte der REST-API (GET /current, GET /versions/{n}, GET /as-of, GET /versions/diff) und die entsprechenden MCP-Werkzeuge, falls Sie diese direkt statt der Bereitstellungstabelle nutzen — etwa für eigene ETL-Skripte oder Notebooks außerhalb von Teil B/D.

Was sich ändert: Das Feld id einer Zeile (im Diff row_id) war bisher je Version neu — dieselbe fachliche Zeile bekam bei jeder Version eine neue ID, selbst wenn sich ihr Inhalt nicht änderte. Seit diesem Release ist id eine Zustands-ID: Eine unveränderte Zeile behält ihre ID über Commits, Massenänderungen, Import (Upsert/FullReplace), Umgebungskopie und Plattform-Import/-Aktualisierung hinweg. Ändert sich ihr Inhalt, entsteht eine neue ID.

Was das für Sie bedeutet:

• Eindeutig über Versionen hinweg ist erst das Paar aus Versionsnummer und id, nicht id allein. Schreiben eigene Skripte oder Views mehrere Versionen in eine Historientabelle mit Unique-Key ausschließlich auf id, stellen Sie den Schlüssel auf (version_number, id) um.
• sys_created_at/sys_created_by bedeuten jetzt „seit wann existiert dieser Zeilenzustand unverändert" — eine unveränderte Zeile behält ihren ursprünglichen Zeitstempel auch über einen erneuten FullReplace-Import hinweg, statt bei jedem Neuschreiben den aktuellen Zeitpunkt zu bekommen.
• Response-Formate, Feldnamen und alle anderen Endpunkte bleiben unverändert — es handelt sich um eine additive Stabilitätsgarantie, kein Breaking Change am Wire-Format.

Kein Übergang nötig: Nach Entscheidung des Product Owners (27.09.2026) speichert kein Kunde Row-IDs versionsübergreifend als eigenen Schlüssel. Die neue Semantik gilt deshalb sofort, ohne Vorlauf und ohne Kompatibilitätsschicht.

Hintergrund und vollständige Spezifikation: design/delta-versioning-spec.md §13, design/api-spec.md → „ID-Format".

9. Sicherheitshinweise

API-Keys niemals in Notebooks einbetten

Notebooks werden im Fabric Workspace gespeichert und können geteilt oder versioniert werden. API-Keys dürfen nicht als Klartext in der Parameterzelle stehen.

Empfohlener Weg — Azure Key Vault:

import notebookutils
RDM_API_KEY = notebookutils.credentials.getSecret("<key-vault-name>", "rdm-api-key")

Hinterlegen Sie den API-Key als Azure Key Vault Secret und erteilen Sie der Managed Identity des Fabric Notebooks (oder Ihrem Entra-Dienstprinzipal) die Berechtigung Get auf dieses Secret.

SAS-Token-Hygiene

• Ablaufdatum maximal 1 Jahr; Kalendererinnerung vor Ablauf setzen
• SAS-Token nur auf den Exportcontainer beschränken (nicht auf das gesamte Storage Account)
• Für den OneLake Shortcut (Fabric liest) ein separates, schreibgeschütztes SAS-Token verwenden — Fabric benötigt nur Lese- und Auflistungsberechtigungen
• Verlorene SAS-Token: neues Token im Azure Portal generieren, in Einstellungen → Integrationen → OneLake ersetzen, Verbindung erneut testen

API-Key-Verwaltung

• Separate Keys für Pull-Notebooks (lesen) und Upload-Notebooks (schreiben)
• Keys nach Dataset benennen: fabric-pull-kostenstellen, fabric-upload-filialen
• Nicht mehr benötigte Keys sofort widerrufen: Einstellungen → API-Keys → Widerrufen (wirkt sofort)
• Vor dem Widerrufen eines genutzten Keys einen Ersatzkey anlegen und die Notebook-Konfiguration zuerst aktualisieren

Upload-Notebooks

Das Upload-Notebook (Teil C) kann Produktionsdaten überschreiben. Daher:

• Dedizierten Key pro Dataset anlegen, um Wirkungsbereich eines kompromittierten Keys zu begrenzen
• Upload-Notebooks zuerst gegen ein Test-Dataset validieren
• Bei Full Replace: Vor dem ersten Produktiveinsatz sicherstellen, dass alle Pflichtfelder korrekt gemappt sind

9a. Klassifizierung und Rückzug

Dieses Kapitel beschreibt, welche Spalten die Datenplattform erreichen und was zu tun ist, wenn eine Spalte nachträglich höher eingestuft wird. Die Bedienung (Einstellung, Dialoge, Hinweise in der Oberfläche) steht im Benutzerhandbuch; hier stehen die Auswirkungen auf die Integrationswege.

Eine Einstellung für alle Wege

Die höchste Klassifizierung für die Bereitstellung (Einstellungen → Allgemein) gilt mandantenweit für jeden Weg. Spalten, deren Sensitivitätsstufe darüber liegt, sind in der Bereitstellungstabelle nicht vorhanden — weder Name noch Werte, weder im OneLake-Export noch in GET /api/datasets/{id}/delivery-table.

Notebook-Weg und höchste Klassifizierung

Ein für das Notebook angelegter Lese-Key erreicht höchstens die Stufe „Intern". Daraus folgt:

Die Assistenten „Mit DWH verbinden" und Fabric-Sammel-Notebook zeigen bei einer höchsten Klassifizierung über „Intern" vorab den Hinweis: „Bei
höchsten Klassifizierung für die Bereitstellung über „Intern" kann ein Notebook mit Lese-Key die Tabelle nicht abrufen. Nutzen Sie OneLake direkt oder OneLake Shortcut."

Empfehlung: Nutzen Sie bei einer höchsten Klassifizierung über „Intern" den Weg OneLake direkt (Teil A2) oder OneLake Shortcut (Teil A). Diese Wege sind auf einen benannten Zielspeicher beschränkt und brauchen keinen API-Key.

Ausweg bei „Vertraulich" (nur wenn OneLake keine Option ist): Ein Admin kann unter Einstellungen → Sicherheit → API-Keys einen Key mit Schreibzugriff anlegen und im Notebook verwenden. Das ist mehr Recht, als das Notebook braucht: Der Key kann Daten in MDM Lite verändern. Die Assistenten schlagen das nie vor. Beachten Sie Abschnitt 9: Key nur über Key Vault einbinden, einen eigenen Key je Notebook verwenden und ihn sofort widerrufen, wenn er nicht mehr gebraucht wird. Bei „Eingeschränkt" gibt es keinen Ausweg über einen API-Key. Ein eigener, nur lesender Key-Typ für die Bereitstellung ist für ein späteres Release vorgesehen.

Ein bewusster Vollexport

Sollen alle Spalten auf die Datenplattform gehen, setzen Sie die höchste Klassifizierung auf Eingeschränkt (Schritte im Benutzerhandbuch). Prüfen Sie vorher die Zugriffsrechte im Fabric-Workspace und im Lakehouse: Ab dann liegt die Zugriffskontrolle für vertrauliche Werte bei Ihnen. Erwartetes Ergebnis nach der nächsten Bereitstellung: Die Spalten erscheinen in der Tabelle, und die Hinweisboxen in MDM Lite melden „Diese Bereitstellung enthält alle Spalten dieses Datasets, auch vertrauliche und eingeschränkte."

Rückzug: Was passiert, wenn eine Spalte höher eingestuft oder die höchste Klassifizierung gesenkt wird?

1. Automatischer Rückzugslauf: Ein Hintergrundprozess erkennt den ausstehenden Rückzug (retraction: pending) und stellt die Tabelle in der Regel innerhalb von etwa 30 Sekunden ohne die Spalte neu bereit — auch ohne Auto-Export und Zeitplan. Voraussetzung: aktive Fabric-Integration mit Berechtigung in der Umgebung des Datasets und Dataset veröffentlicht. Der Rückzug läuft auch in deaktivierten Umgebungen. Auslöser im Audit retraction, Akteur system:retraction. Wirkt die Änderung auf mehrere Datasets, schreibt jede Bereitstellung nur ihr eigenes Dataset neu (höchstens 50 je Mandant und Scan).
2. Abgelöste Datendateien werden sofort gelöscht: Direkt nach dem neuen, dauerhaft geschriebenen Commit löscht MDM Lite alle abgelösten Datendateien mit remove-Eintrag, auch ältere innerhalb der 7-Tage-Frist aus A6. Die Delta-Zeitreise auf die Stände davor ist danach nicht mehr möglich. Das gilt für jede Bereitstellung, die einen Rückzug schreibt, auch für einen manuellen Export. Die neue Datei und Dateien ohne remove (z. B. Reste abgebrochener Schreibvorgänge) bleiben unangetastet. Die aktuelle Tabelle verweist zu keinem Zeitpunkt auf eine gelöschte Datei; nur eine Abfrage, die in diesem Moment noch den Vorstand liest, kann abbrechen.
3. Scheitert das Löschen einzelner Dateien oder bricht der Prozess nach dem Commit ab, bleibt der Rückzug pending, und der nächste Lauf (bei einem Fehler nach 5 Minuten Wartezeit) schreibt erneut und löscht alle abgelösten Dateien.
4. Fabric-Notebook (Teil B/D): Das Notebook holt die Tabelle beim nächsten Lauf ohne die Spalte.

Erst hochgestuft, dann gelöscht: Beim Löschen einer Spalte hält MDM Lite ihre letzte Stufe fest (Klassifizierungs-Grabstein). Diese Stufe gilt für alle älteren Versionen, die noch Werte der Spalte enthalten, auf jedem Lesepfad und in beiden Bereitstellungsmodi. Lag sie über der höchsten Klassifizierung, meldet der Status retraction: pending, und der Rückzugslauf schreibt die Tabelle wie oben ohne diese Werte neu, auch wenn die Spalte gelöscht wurde, bevor ein Lauf die Hochstufung gesehen hat. Eine später neu angelegte Spalte gleichen Namens hat ihre eigene Stufe und wird in ihren eigenen Versionen normal bereitgestellt. Spalten, die vor dieser Funktion gelöscht wurden, hat MDM Lite beim Update nachgetragen. Erwartetes Ergebnis: Nach dem Rückzugslauf enthält weder die aktuelle Tabelle noch eine Datendatei im Ordner die Werte.

Klassifizierung und Rückzug: Status und Audit

GET /api/datasets/{id}/onelake-shortcut/status enthält den Block delivery_classification (auch vor der ersten Bereitstellung):

"delivery_classification": {
  "delivery_ceiling": "internal",
  "dataset_level": "restricted",
  "withheld_column_count": 2,
  "retraction": "pending",
  "retraction_blocked_reason": null
}

Jeder Leser des Datasets sieht den Block. Er enthält nur Zahlen und die abgeleitete Stufe.

Im Änderungsprotokoll trägt onelake_exported zusätzlich delivery_ceiling, withheld_column_count (bei fehlgeschlagenem Versuch null) und retraction (true, wenn vor der Bereitstellung ein Rückzug ausstand; im Zweifel true). Dazu kommt deleted_file_count: die Anzahl der Datendateien, die diese Bereitstellung gelöscht hat (nie Dateinamen). Namen zurückgehaltener Spalten stehen nie im Protokoll. Der Rückzugslauf schreibt den Auslöser retraction mit dem Akteur system:retraction.

Fehlerbehebung retraction: blocked

MDM Lite schreibt in diesen Fällen nichts; die Tabelle auf der Datenplattform bleibt stehen. Alle Gründe und die passende Maßnahme:

Manuelle Bereinigung

Nutzen Sie sie, wenn Werte oder Spaltennamen sofort von der Datenplattform verschwinden müssen oder der Rückzug blockiert ist:

1. Lösen Sie, wenn möglich, eine Bereitstellung aus, damit die aktuelle Tabelle die Spalte nicht mehr enthält (sonst überspringen Sie diesen Schritt und löschen den Tabellenordner in Schritt 3).
2. Löschen Sie im Ordner der Tabelle (<pfad-präfix><technischer-name>/) alle Datendateien (part-….snappy.parquet) außer der Datei, die im neuesten Commit unter _delta_log/ als add steht — im Azure-Portal (Teil A) bzw. im OneLake-Datei-Explorer oder mit einem Storage-Werkzeug Ihrer Wahl (Teil A2). Führen Sie kein VACUUM aus.
3. Muss auch der Spaltenname aus dem _delta_log verschwinden, löschen Sie den gesamten Tabellenordner und lösen Sie danach eine Bereitstellung aus; MDM Lite schreibt die Tabelle dann neu.
4. Leeren Sie den Papierkorb: OneLake hält gelöschte Dateien laut Microsoft 7 Tage vor, bei ADLS Gen2/Blob Storage gilt die im Storage Account eingestellte Soft-Delete-Frist (1 bis 365 Tage, sofern aktiviert). Lassen Sie die Dateien bei Bedarf dort endgültig löschen.
5. Prüfen Sie Kopien auf der Plattform: abgeleitete Tabellen, semantische Modelle, Caches des SQL-Endpunkts, Downloads. MDM Lite erreicht sie nicht.

Verifikation: Die Tabelle enthält die Spalte nicht mehr (DESCRIBE/Schema in Fabric), und der Status zeigt retraction: none.

10. Fehlerbehebung

Verbindungstest schlägt fehl: „Die angegebene Ressource ist nicht vorhanden"
→ Containername stimmt nicht. Auf führende/abschließende Leerzeichen prüfen. Containernamen sind immer kleingeschrieben und dürfen nur Buchstaben, Ziffern und Bindestriche enthalten.

Verbindungstest schlägt fehl: „Der Server konnte die Anforderung nicht authentifizieren"
→ SAS-Token ungültig oder abgelaufen. Ablaufdatum im Azure Portal prüfen (Storage Account → Shared access signature). Neues Token generieren, in den Einstellungen ersetzen und speichern.

Notebook schlägt mit 401 fehl beim Aufruf der MDM-Lite-API
→ RDM_API_KEY ist leer oder der Key wurde widerrufen. Schlüsselstatus in Einstellungen → API-Keys prüfen. Bei Verwendung von notebookutils.credentials.getSecret(): Key Vault-Namen, Secret-Namen und Berechtigungen der Fabric-Identität überprüfen.

Notebook schlägt mit 400 fehl: „Pflichtfelder fehlen im Mapping"
→ Das COLUMN_MAPPING-Dictionary enthält nicht alle Pflichtfelder des MDM-Lite-Schemas. Den Upload-from-DWH-Wizard erneut öffnen, alle mit ✓ markierten Pflichtfelder mappen und das Notebook neu herunterladen.

OneLake Shortcut liefert veraltete Daten
→ Der Delta-Export wird nur aktualisiert, wenn er manuell ausgelöst oder der Bulk-Sync ausgeführt wird. Das Exportstatus-Badge auf der Dataset-Detailseite zeigt „veraltet", wenn der letzte Delta-Commit älter als die aktuelle Datasetversion ist. Export neu auslösen oder Bulk-Sync-Notebook planen.

Tabelle erscheint unter „Tables → Unidentified" statt als erkannte Tabelle
→ Ein Pfadsegment ist kein gültiger Fabric-Bezeichner (Bindestrich oder führende Ziffer) — siehe Fabric-Namensregeln. Seit #800 erzeugt das MDM Lite ausschließlich gültige snake_case-Namen für den technischen Namen und das Pfad-Präfix; betrifft der Fehler einen vor #800 exportierten Ordner mit einem ungültigen (z. B. bindestrichhaltigen) Namen, wurde diesem Dataset beim Einführen des technischen Namens (#1512) ein neuer, gültiger technischer Name aus seinem Anzeigenamen zugewiesen — der alte, ungültig benannte Ordner wurde dabei nicht automatisch aufgeräumt (MDM Lite löscht nie Tabellen). Lösen Sie den Export einmal neu aus, damit der aktuelle Stand unter dem neuen, gültigen Ordner erscheint, und löschen Sie den alten Ordner anschließend manuell im Storage Account. Prüfen Sie zusätzlich, ob der Shortcut direkt unter Tables/ (nicht unter Files/) angelegt wurde. Reste aus der Zeit vor #786 (GUID-Ordner mit einzelner data.parquet-Datei) werden ebenfalls nicht automatisch migriert und müssen einmalig manuell gelöscht werden.

Export schlägt fehl: „Der Zielpfad existiert bereits als Ordner oder Tabelle im Lakehouse"
→ OneLake meldet für den Zielpfad einen nicht leeren Ordner (technisch HTTP 409, DirectoryIsNotEmpty). Typische Ursachen: (1) Das Lakehouse ist nicht schema-fähig — dann behandelt OneLake das Pfad-Präfix (z. B. stg_mdm/) nur als gewöhnlichen Ordner unterhalb von Tables/, nicht als Schema; (2) unter Tables/<pfad-präfix> liegt bereits eine andere Tabelle oder ein Ordner, der mit dem Zielpfad kollidiert (etwa nach einer Änderung des Pfad-Präfix). Prüfen Sie im Lakehouse, ob es schema-fähig ist, und ob der Pfad Tables/<pfad-präfix><technischer-name>/ bereits anders belegt ist; passen Sie das Pfad-Präfix an oder räumen Sie den kollidierenden Ordner im Lakehouse auf. In der Oberfläche erscheint nur diese verständliche Meldung; die ursprüngliche Antwort von Azure (Status, ErrorCode, RequestId) steht unter Details neben dem fehlgeschlagenen Dataset im Ergebnis von „Jetzt synchronisieren" — für Support und Fehlersuche.

Nach dem Sammel-Export fehlt ein Dataset oder die Tabelle enthält noch Zeilen, obwohl die aktuelle Version leer ist
→ „Jetzt synchronisieren" betrachtet nur Entwürfe (werden als „übersprungen – nicht veröffentlicht" gemeldet) und veröffentlichte Datasets; archivierte Datasets zählen nicht mit. Eine Version ohne Zeilen ist ungültig („Version enthält keine Zeilen") und wird nicht ausgeliefert — bereitgestellt wird weiter die letzte gültige Version mit Daten, auch wenn eine neuere, leere Version (oder eine reine Schema-Änderung darauf) existiert. Das im Lakehouse sichtbare Zeilenbild entspricht dann dieser Version, nicht der leeren Arbeitsversion. Auf der Dataset-Detailseite zeigt der Hinweis „Version #n ist ungültig … Konsumenten sehen weiterhin v…", welche Version ausgeliefert wird.

Teil A2 — Verbindungstest/Export schlägt mit 401 oder 403 fehl
→ Fast immer eine von zwei Ursachen: (1) die Fabric-Mandanteneinstellung "Service principals can use Fabric APIs" ist nicht freigegeben (A2.3, liegt beim Fabric-Tenant-Admin) — auch mit korrekter Workspace-Rolle schlägt der Zugriff dann fehl; (2) der Service Principal hat keine oder eine zu niedrige Rolle auf dem Ziel-Workspace/-Lakehouse (A2.2 — mindestens Contributor/Member bzw. OneLake-RBAC ReadWrite). Client Secret zusätzlich auf Ablauf prüfen (Entra ID → App-Registrierung → Zertifikate & Geheimnisse).

Teil A2 — Tabelle landet unter „Files" statt unter „Tables" bzw. bleibt "Unidentified"
→ Wie bei Teil A: Prüfen, ob das Ziel-Lakehouse schema-fähig ist (Kapitel 3/A2.1). Ist es das nicht, landet die Tabelle direkt unter Tables/<tabelle>/ ohne Schema-Ebene, statt als <schema>.<tabelle>. Ein ungültiges Pfad-Präfix-Segment (Bindestrich, führende Ziffer) führt wie bei Teil A zu „Unidentified" — dieselbe Fabric-Namensregel gilt für beide Pfade.

Notebook (Teil B/D) schlägt mit 410 endpoint_removed fehl
→ Ein noch vor diesem Release generiertes Notebook ruft den entfallenen zeilenbezogenen Änderungs-Feed auf. Öffnen Sie den Assistenten erneut und laden Sie ein neues Notebook herunter (siehe Kapitel 8 – Einmalige Umstellung).

Notebook (Teil B/D) schlägt mit ValueError: SYNC_MODE must be 'auto' or 'full' ab
→ Die Parameterzelle enthält noch den entfallenen Wert incremental (oder full/incremental aus einem älteren Notebook-Stand). Auf auto oder full setzen (siehe Schritt B6).

Notebook (Teil B/D) meldet 403 delivery_ceiling_exceeds_key
→ Der verwendete API-Key hat eine niedrigere Klassifizierungsgrenze als die mandantenweite höchste Klassifizierung für die Bereitstellung — bei einem Lese-Key ist das typischerweise der Fall, sobald die höchste Klassifizierung auf „Vertraulich" oder „Eingeschränkt" steht (siehe Kapitel 9a) (Einstellungen → Allgemein → „Höchste Klassifizierung für die Bereitstellung", siehe Benutzerhandbuch). Die Tabelle wird nie „für diesen Key" zusätzlich gekürzt bereitgestellt. Nutzen Sie stattdessen OneLake direkt oder OneLake Shortcut (dort gelten Key-höchste Klassifizierungn nicht), senken Sie die mandantenweite höchste Klassifizierung bewusst oder verwenden Sie — nur als Ausweg — einen Key mit höherer höchste Klassifizierung (siehe Kapitel 9a). Bei „Eingeschränkt" gibt es keinen solchen Key.

Hinweis „MDM Lite kann sie derzeit nicht entfernen" / retraction: blocked
→ Die Tabelle auf der Datenplattform enthält noch Spalten über
höchsten Klassifizierung für die Bereitstellung, und MDM Lite kann sie nicht entfernen. Grund und Maßnahme je retraction_blocked_reason stehen in Kapitel 9a; die manuelle Bereinigung unter Manuelle Bereinigung.

Hinweis „MDM Lite entfernt sie bei der nächsten Bereitstellung" / retraction: pending
→ Warten Sie etwa 30 Sekunden: Der Rückzugslauf schreibt die Tabelle neu und löscht die abgelösten Datendateien sofort. Alternativ „Jetzt bereitstellen" bzw. „Export to OneLake"; bei Notebooks der nächste Lauf. Bleibt der Status pending, prüfen Sie den Export-Status auf einen Fehler. Siehe Kapitel 9a.

Notebook (Teil B/D) meldet 409 dataset_not_published oder 409 no_deliverable_version
→ Das Dataset ist zurückgezogen/archiviert (dataset_not_published) oder hat keine gültige, bereits wirksame Version (no_deliverable_version, z. B. ausschließlich geplante Versionen mit zukünftigem Stichtag). Die Zieltabelle bleibt in beiden Fällen unverändert liegen, bis das Dataset veröffentlicht ist bzw. eine Version wirksam wird.

Notebook (Teil B) bricht mit delivery_table_changed nach mehreren Versuchen ab
→ Der Tabellenstand hat sich zwischen zwei Seiten desselben Abrufs geändert (z. B. durch einen gleichzeitigen Import). Das Notebook versucht automatisch bis zu MAX_RETRIES-mal neu; hält der Fehler danach an, prüfen Sie, ob ein anderer Prozess das Dataset in sehr kurzer Folge ändert, und führen Sie den Lauf erneut aus.

delta_table_modified_externally beim Export/Notebook-Lauf
→ Ein fremder Prozess (z. B. ein manuell ausgeführtes OPTIMIZE oder VACUUM) hat einen Commit auf der Zieltabelle hinterlassen. MDM Lite ist alleiniger Schreiber dieser Tabellen (siehe Kapitel 2) und bricht ab, statt den fremden Commit zu überschreiben oder zu löschen. Entfernen Sie eigene Jobs auf dieser Tabelle; ein erneuter Export/Notebook-Lauf schreibt danach wieder normal.

409 delta_export_in_progress beim Export
→ Dasselbe Dataset wird gerade schon exportiert, zum Beispiel durch die automatische Bereitstellung nach einer Änderung, durch die Veröffentlichung oder durch einen zweiten Klick auf „Exportieren". MDM Lite schreibt eine Tabelle nie mit zwei Exporten gleichzeitig. Der zweite Export wartet deshalb bis zu 30 Sekunden auf den ersten und bricht danach ohne Änderung ab. Die Tabelle bekommt den Stand des laufenden Exports. Warten Sie, bis er abgeschlossen ist, und exportieren Sie danach bei Bedarf erneut. Beim Sammel-Export erscheint das Dataset in diesem Fall als „übersprungen".

422 delivery_table_too_large
→ Die Bereitstellungstabelle überschreitet die Zeilenobergrenze. MDM Lite prüft die Zeilenzahl, bevor die Tabelle aufgebaut wird, damit eine einzelne Anfrage den Server nicht überlastet; es wird nie eine abgeschnittene Tabelle geliefert. Die Meldung nennt die Zahl der Zeilen und die Grenze. Im Modus „Vollständige Historie" zählen alle gespeicherten Zustände aller aufbewahrten Versionen. Ohne ausdrückliche Einstellung richtet sich die Grenze nach dem Arbeitsspeicher des Servers und der Spaltenzahl (Richtwert bei 1 GiB Speicher: etwa 200.000 Zeilen mit 5 kurzen Spalten, etwa 70.000 Zeilen mit 30 Spalten, höchstens 2.000.000). Sprechen Sie mit Ihrem MDM-Lite-Administrator über mehr Serverspeicher oder eine ausdrücklich gesetzte Grenze (Delivery:MaxTableRows) bzw. über eine engere Versionsaufbewahrung. Ein Export, der daran scheitert, wird als fehlgeschlagen vermerkt und später erneut versucht.

Bulk-Sync schlägt für einzelne Datasets fehl, andere laufen durch
→ Das Bulk-Notebook setzt bei Dataset-Fehlern den Gesamtlauf fort und listet am Ende alle fehlgeschlagenen Datasets mit Fehlermeldung auf. Der gespeicherte ETag eines fehlgeschlagenen Datasets wird nicht aktualisiert — bei der Ursachenbehebung gehen keine Änderungen verloren. Nach Behebung einfach erneut ausführen; nur die zuvor fehlgeschlagenen bzw. inzwischen erneut geänderten Datasets werden dann übertragen.

11. API-Referenz (Bereitstellungs-Endpunkte)

Alle Endpunkte erfordern Authorization: ApiKey <API-Key> (Scope „read" genügt) oder ein gültiges JWT mit mindestens der Rolle Viewer. Mandantenabgrenzung ist serverseitig erzwungen.

Bereitstellungstabelle eines Datasets

GET /api/datasets/{id}/delivery-table

Liefert Schema und Zeilen der Bereitstellungstabelle — genau das, was OneLake und die generierten Notebooks auf die Datenplattform schreiben.

Antwort (Auszug):

{
  "contract_version": 1,
  "dataset_id": "7f1c2a3e-...",
  "table_name": "kostenstellen",
  "delivery_mode": "current",
  "delivered_version": 8,
  "delivered_at": "2026-07-01T08:00:00.000Z",
  "etag": "\"1-9b2f...\"",
  "schema": { "type": "struct", "fields": [ { "name": "kostenstelle", "type": "string", "nullable": true, "metadata": {} } ] },
  "table_properties": { "mdmlite.contractVersion": "1", "mdmlite.deliveryMode": "current" },
  "rows": [ { "kostenstelle": "4711", "name": "Marketing", "rdm_record_id": "...", "rdm_valid_from": "2026-01-01" } ],
  "next_cursor": null,
  "has_more": false
}

Übersicht aller bereitstellbaren Datasets

GET /api/delivery-tables

Für Sammel-Abrufe (Bulk-Sync): alle veröffentlichten, für den Aufrufer lesbaren Datasets der aktuellen Umgebung, mit dataset_id, name, table_name, delivery_mode, delivered_version, etag und status (ok oder ein Fehlercode wie oben). Paginierung über limit/cursor wie beim einzelnen Endpunkt. Der ETag lässt sich ohne die Zeilen selbst berechnen — ideal, um vor dem eigentlichen Abruf zu prüfen, ob sich überhaupt etwas geändert hat.

Status der OneLake-Bereitstellung und Klassifizierung

GET /api/datasets/{id}/onelake-shortcut/status

Liefert den Exportstatus des Datasets und den Block delivery_classification (höchste Klassifizierung, abgeleitete Dataset-Stufe, Anzahl zurückgehaltener Spalten, Rückzugsstatus) — Feldbeschreibung in Kapitel 9a. Jeder Leser des Datasets darf ihn abrufen; fremde Mandanten oder Umgebungen erhalten 404.

Bereitstellungsmodus ändern

PATCH /api/datasets/{id}/delivery-mode
Body: { "deliveryMode": "current" | "history" }

Erfordert die effektive Dataset-Rolle Admin (API-Keys erreichen diese Rolle nie und werden mit 403 abgewiesen) — siehe Benutzerhandbuch, „Den Bereitstellungsmodus wählen".

Entfallen: zeilenbezogener Änderungs-Feed

GET /api/datasets/{id}/changes

Antwortet seit diesem Release mit 410 Gone (Fehlercode endpoint_removed) und verweist auf …/delivery-table. Ein noch gegen diesen Endpunkt gerichtetes Notebook muss neu generiert werden (siehe Kapitel 8).

Unverändert: dataset-übergreifender Änderungs-Feed und Server-Zeit

GET /api/datasets/changes?since=<ISO-8601-Timestamp>   → alle Datasets mit Audit-Aktivität seit since (Diagnose, kein Bereitstellungsweg)
GET /api/server-time                                   → aktueller Server-Zeitstempel

Die generierten Notebooks nutzen GET /api/datasets/changes seit diesem Release nicht mehr zur Sync-Erkennung (das übernimmt GET /api/delivery-tables mit seinen ETags) — der Endpunkt bleibt aber für eigene Diagnose- und Monitoring-Zwecke bestehen. Feldreferenz: design/api-spec.md ↗ (GitHub, ggf. Zugriff erforderlich).

Aktuelle Datasetdaten

GET /api/datasets/{id}/current              → aktuelle Version
GET /api/datasets/{id}/as-of?date=2025-12-31 → Stand zum Stichtag
GET /api/datasets/{id}/versions/{version}   → bestimmte Version

Weiterführende Dokumentation: Benutzerhandbuch · API-Spezifikation ↗ (GitHub, ggf. Zugriff erforderlich) · Import-Spezifikation ↗ (GitHub, ggf. Zugriff erforderlich)