Mit diesem Formular können Sie fehlende, unklare oder fehlerhafte Inhalte in der Dokumentation melden und Verbesserungsvorschläge machen. Ihr Feedback hilft uns, die Qualität und Vollständigkeit kontinuierlich zu verbessern.
Plattformbetrieb und Governance
Dieses Dokument beschreibt die Betriebsabläufe der Plattform auf konzeptioneller Ebene – Datenaktualisierung, Mandantenerweiterung, Änderungsverfolgung sowie Compliance- und Governance-Aspekte.
Einen Überblick über die Plattform und ihre Architektur finden Sie unter unitop Fabric im Überblick.
1. Lösung im Überblick
Die Plattform folgt der Medallion Architecture von Microsoft Fabric – einem etablierten Architekturmuster, bei dem Daten die Stufen Bronze Layer, Silver Layer und Gold Layer durchlaufen. Mit jeder Stufe steigen Datenqualität, Konsistenz und geschäftliche Verwendbarkeit, bevor die Daten in Power BI für Berichte und Analysen bereitgestellt werden.
Mehr zur Medallion Architecture lesen Sie in der Dokumentation von Microsoft.
flowchart LR
BC["Business Central<br/>(je Mandant)"] -->|OData API| Bronze
subgraph Fabric["Microsoft Fabric"]
Bronze["Bronze Layer<br/>Rohdaten, unveränderte Kopie"]
Silver["Silver Layer<br/>Bereinigt · typisiert · auditierbar"]
Gold["Gold Layer<br/>Berichtsfertige Ansichten"]
Bronze --> Silver --> Gold
end
Gold --> PBI["Power BI<br/>Berichte & Dashboards"]
style BC fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style Bronze fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style Silver fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style Gold fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style PBI fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
| Layer | Beschreibung | Einsatzzweck |
|---|---|---|
| Bronze Layer | Rohe, originalgetreue Kopie der Business-Central-Daten | Vollständige Quellhistorie, keine Transformation |
| Silver Layer | Bereinigte, typisierte, deduplizierte und auditierbare Daten | Einheitliche Datengrundlage für Analysen und Reporting |
| Gold Layer | Aggregierte, berichtsfertige Ansichten und Modelle | Optimierte Leseschicht für Power BI Berichte und Dashboards |
Daten sind stets mandantenweise organisiert – jeder Datensatz trägt über alle Layer hinweg den zugehörigen Mandantenbezeichner.
2. Der Silver Layer
Der Silver Layer enthält die bereinigten, typisierten und auditierbaren Daten der Plattform. Er ist auf Stabilität und Konsistenz ausgelegt und dient als einheitliche Datengrundlage für den Gold Layer, Power-BI-Modelle und individuelle Analysen.
Eigenschaften des Silver Layer:
- Bereinigte, typisierte Daten: Rohtext aus der Quelle wird in korrekte Datentypen (Zahlen, Datumsangaben, Beträge) umgewandelt, sodass Berechnungen korrekt und konsistent sind.
- Ein Datensatz pro Geschäftsobjekt: Daten, die über mehrere Quellschnittstellen geliefert werden, werden zu einem einzigen, einheitlichen Datensatz zusammengeführt.
- Stabile, zuverlässige Bezeichner: Jeder Datensatz erhält einen deterministischen Schlüssel. Derselbe Quelldatensatz wird stets demselben Schlüssel zugeordnet, wodurch Tabellenbeziehungen über Aktualisierungen hinweg konsistent bleiben.
- Mandantenweise Verarbeitung: Daten werden je Mandant geladen und Änderungen je Mandant verfolgt. Jeder Datensatz trägt seinen Mandantenbezeichner und ist jederzeit eindeutig einem Mandanten zugeordnet.
- Vollständiger Audit-Trail: Jede Einfügung, Aktualisierung und Löschung wird mit Zeitstempel protokolliert (siehe Abschnitt 5).
Aufgrund dieser Eigenschaften ist der Silver Layer der empfohlene Integrationspunkt, wenn Daten außerhalb der bereitgestellten Power-BI-Berichte genutzt werden sollen.
3. Datenaktualisierung und Zeitplanung
Jede Datenaktualisierung in unitop Fabric läuft als vollständiger ETL-Prozess durch alle drei Layer – gesteuert über eine zentrale Pipeline in Microsoft Fabric. Dieser Abschnitt beschreibt den technischen Ablauf sowie die konfigurierbaren Aktualisierungsmodi.
Ablauf einer Aktualisierung
Eine Aktualisierung durchläuft die gesamte Verarbeitungskette von Bronze Layer bis Power BI, orchestriert als einzelne verwaltete Pipeline in Microsoft Fabric:
flowchart LR
Trigger["Zeitplan<br/>(Fabric-Pipeline)"] --> Orchestrator["Vollständiger ETL-Lauf"]
Orchestrator --> B["Bronze Layer<br/>Laden aus BC"]
B --> S["Silver Layer<br/>Bereinigen & Nachverfolgen"]
S --> G["Gold Layer<br/>Ansichten erstellen"]
G --> R["Power BI<br/>aktualisiert"]
style Trigger fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style Orchestrator fill:#fff,stroke:#425253,stroke-width:1px,color:#000000
style B fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style S fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style G fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
style R fill:#fff,stroke:#0098a1,stroke-width:1px,color:#000000
Aktualisierungshäufigkeit
- Die Aktualisierung wird durch einen Zeitplan in der Fabric-Pipeline gesteuert und läuft in der Regel einmal täglich (üblicherweise außerhalb der Geschäftszeiten).
- Der Zeitplan ist konfigurierbar – er wird zentral im Fabric-Arbeitsbereich festgelegt, ist nicht fest im Code verankert und kann ohne Codeänderungen angepasst werden.
- Pro Tabelle werden zwei Aktualisierungsmodi verwendet:
- Vollständig: Ein vollständiger Snapshot wird neu geladen (erkennt dabei auch Löschungen).
- Inkrementell: Nur seit dem letzten Lauf geänderte Datensätze werden geladen (geringere Laufzeit, reduzierte Last auf dem Quellsystem).
Mehr zu Pipelines in Microsoft Fabric lesen Sie in der Dokumentation von Microsoft.
4. Mandantenlogik und Mehrmandanten-Unterstützung
unitop Fabric unterstützt den gleichzeitigen Betrieb mehrerer Mandanten innerhalb einer einzelnen Plattforminstanz. Die Mandantentrennung ist systemseitig erzwungen und erfordert keine manuelle Konfiguration.
Mandantentrennung
Jeder Datensatz trägt seinen Mandantenbezeichner aus der Quelle durch alle Layer – Bronze Layer, Silver Layer und Gold Layer. Daten verschiedener Mandanten werden zu keinem Zeitpunkt zusammengeführt. Berichtsbeziehungen gelten ausschließlich innerhalb desselben Mandanten. Jeder Mandant wird im Rahmen der Aktualisierung unabhängig verarbeitet, sodass unterschiedliche Aktualisierungsrhythmen je Mandant möglich sind.
Neue Mandanten hinzufügen
Die Lösung ist auf die Erweiterung um weitere Mandanten ausgelegt. Die Aufnahme eines neuen Mandanten umfasst folgende Schritte:
- Mandant registrieren: Eintrag in die zentrale Konfiguration (den Mandantenkatalog, den die Plattform liest).
- Einrichtungsschritt ausführen: Aktivierung des neuen Mandanten und Vorbereitung seiner Metadaten.
- Datenladen durchführen: Die Daten des neuen Mandanten durchlaufen Bronze Layer → Silver Layer → Gold Layer wie die Daten jedes bestehenden Mandanten.
Das Hinzufügen eines Mandanten ist eine Konfigurations- und Ladeaktivität, kein Entwicklungsprojekt. Das Implementierungsteam führt diese Schritte mit dem bereitgestellten Einrichtungswerkzeug durch.
5. Änderungsverfolgung und Löschungen (Change Log)
Der Silver Layer protokolliert jede Änderung und Löschung mit Zeitstempel. Gelöschte Datensätze werden nicht physisch entfernt, sondern als gelöscht markiert und für Audit-Zwecke aufbewahrt. Dieser Abschnitt beschreibt das zugrunde liegende Soft-Delete-Modell und den Change Feed.
Funktionsweise
Der Silver Layer pflegt Tracking-Informationen zu jedem Datensatz:
- Aktiver vs. gelöschter Zustand: Datensätze werden markiert, nicht physisch entfernt.
- Zuletzt-geändert-Zeitstempel: Zeitpunkt der letzten Änderung des Datensatzes.
- Gelöscht-Zeitstempel: Zeitpunkt, zu dem der Datensatz gegebenenfalls in der Quelle entfernt wurde.
Dies ist ein Soft-Delete-Modell: Wenn ein Datensatz in Business Central verschwindet, wird er im Silver Layer als gelöscht markiert, aber aufbewahrt. Die Erkennungslogik unterscheidet bei jeder Aktualisierung drei Situationen:
| Situation | Aktion der Plattform |
|---|---|
| Neuer oder geänderter Datensatz in der Quelle | Einfügen oder Aktualisieren |
| Datensatz in der Quelle entfernt | Als gelöscht markieren (für Audit aufbewahren) |
| Zuvor gelöschter Datensatz erscheint erneut | Wiederherstellen und Werte aktualisieren |
Hinweis
Die Löscherkennung erfordert einen vollständigen Snapshot und gilt daher für Tabellen, die im vollständigen Aktualisierungsmodus betrieben werden. Inkrementelle Tabellen erfassen Änderungen, erkennen jedoch konstruktionsbedingt keine Löschungen.
Darüber hinaus führt der Silver Layer einen Change Feed, der alle Einfügungen, Aktualisierungen und Löschungen protokolliert – für Audit-Abfragen und zeitpunktbezogene Ansichten.
Für das Reporting: Power BI zeigt standardmäßig nur aktive Datensätze an. Gelöschte Datensätze verbleiben für Compliance und historische Analysen im Silver Layer.
6. Betriebliche Aufgaben – Kurzübersicht
Die folgende Tabelle fasst häufige betriebliche Aufgaben mit den zugehörigen Vorgehensweisen zusammen. Detaillierte Beschreibungen der einzelnen Abläufe finden sich in den jeweiligen Abschnitten dieses Dokuments.
| Aufgabe | Vorgehen / Ort |
|---|---|
| Daten häufiger aktualisieren | Zeitplan der Pipeline im Fabric-Arbeitsbereich anpassen |
| Aktualisierungen beschleunigen | Große Tabellen in den inkrementellen Modus umstellen |
| Einen neuen Mandanten hinzufügen | In der Konfiguration registrieren, Einrichtung ausführen, Datenladen starten |
| Letzten Aktualisierungszeitpunkt ermitteln | Datensatzbezogene Aktualisierungszeitstempel im Silver Layer |
| Gelöschte Datensätze prüfen | Gelöschte Datensätze sind im Silver Layer aufbewahrt und markiert |
| Analysen auf bereinigten, validierten Daten aufbauen | Silver Layer als Datengrundlage verwenden |
| Mandantentrennung sicherstellen | Automatisch – durch den Mandantenbezeichner erzwungen |
7. Compliance und Governance
Die Plattform ist auf Auditierbarkeit und Data Governance ausgelegt. Die folgenden Merkmale beschreiben die technischen Mechanismen, die Nachvollziehbarkeit, Datentrennung und Zugriffsschutz gewährleisten.
- Vollständiger Audit-Trail: Jede Einfügung, Aktualisierung und Löschung wird mit Zeitstempel protokolliert. Löschungen werden als Soft Delete aufbewahrt, was Nachvollziehbarkeit und historische Rekonstruktion ermöglicht.
- Data Lineage: Daten durchlaufen klar definierte Stufen (Bronze Layer → Silver Layer → Gold Layer). Herkunft und Transformationspfad jedes Wertes sind transparent nachvollziehbar.
- Mandantenisolierung: Die Plattform trennt Daten verschiedener Mandanten systemseitig. Eine mandantenübergreifende Vermischung ist durch die Datenstruktur ausgeschlossen.
- Sicherer Zugriff auf die Quelle: Verbindungen zu Business Central und zu Geheimnissen nutzen verwaltete, plattformeigene Identitäten anstelle gespeicherter Anmeldeinformationen, was das Risiko einer Preisgabe von Zugangsdaten reduziert.
- Kontrollierte, versionierte Deployments: Lösungsaktualisierungen werden als versionierte, nachvollziehbare Pakete bereitgestellt, was Change-Control und Reproduzierbarkeit unterstützt.
- Datenaufbewahrung: Da Löschungen als Soft Delete behandelt werden und die Historie erhalten bleibt, kann die Plattform Aufbewahrungs- und historische Berichtsanforderungen erfüllen. Konkrete Aufbewahrungsfristen können an bestehende Richtlinien angepasst werden.
- Schutz vor Datenverlust: Der Silver Layer enthält Audit-Historien (z. B. im Quellsystem gelöschte Datensätze), die das Quellsystem nicht mehr vorhält. Das Löschen der zugrunde liegenden Lakehouses ist durch eingeschränkte Zugriffsrechte geschützt und durch Backups abgesichert, sodass eine versehentliche Löschung wiederhergestellt werden kann, ohne Audit-Historien zu verlieren.