Schluss mit dem Kopieren Ihrer Daten: Warum virtuelle Tabellen in Dynamics 365 der klassischen Synchronisierung überlegen sind

Von Mirko Peters · 2026-08-27

Willkommen zurück im Blog! In unserer Arbeit sprechen wir viel darüber, Systeme zusammenzuführen, Silos aufzubrechen und sicherzustellen, dass Benutzer die Informationen, die sie brauchen, jederzeit griffbereit haben. Doch viele Organisationen tappen bei der Integration ihrer Unternehmenssysteme in eine stille Falle: den Drang, alles zu kopieren. Heute gehen wir ausführlich darauf ein, warum eine

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Blog! In unserer Arbeit sprechen wir viel darüber, Systeme zusammenzuführen, Silos aufzubrechen und sicherzustellen, dass Benutzer die Informationen, die sie brauchen, jederzeit griffbereit haben. Doch viele Organisationen tappen bei der Integration ihrer Unternehmenssysteme in eine stille Falle: den Drang, alles zu kopieren. Heute gehen wir ausführlich darauf ein, warum eine klassische Datensynchronisierung zu massiven Problemen führen kann und wie eine integrierte Funktion von Microsoft Dataverse die Art, wie Sie mit externen Daten umgehen, grundlegend verändern kann.

Wenn Sie eine detaillierte Audio-Aufbereitung dieses Themes mit Praxisbeispielen hören möchten, schauen Sie sich unbedingt die passende Podcast-Folge an: Dynamics 365 Virtual Entities - Simply Explained.

Die Fallstricke doppelter Daten und veralteter Synchronisierungsaufträge

Stellen Sie sich folgendes Szenario vor: Ihr Vertriebsteam arbeitet den ganzen Tag bequem in Dynamics 365. Ihre Lagerbestände liegen jedoch in einem separaten Lagerverwaltungssystem, Ihre Rechnungen werden in einer Finanzanwendung verwaltet und Ihre Produktkataloge pflegen Sie in einem völlig anderen ERP-System. Der klassische Standardansatz vieler IT-Teams ist der Aufbau einer Integrationspipeline. Sie schreiben geplante Aufträge, die all diese Informationen regelmäßig in Dataverse kopieren. Klingt einfach, oder?

Leider entsteht dabei eine Architektur, die voller doppelter Datensätze, Synchronisierungsverzögerungen, fehlgeschlagener Batches und, am schlimmsten, veralteter Informationen steckt. Stellen Sie sich vor, Ihr Lagersystem erfasst während der nächtlichen Synchronisierung zehn verfügbare Einheiten auf Lager. Am nächsten Morgen zeigt Ihr Dynamics 365-Dashboard stolz genau diese zehn verfügbaren Einheiten an. Doch zur Mittagszeit kauft ein Laufkunde vor Ort alle zehn verbleibenden Einheiten und nimmt sie direkt mit. Das Lagersystem weiß sofort, dass der Bestand offiziell null beträgt. Dynamics 365 zeigt jedoch weiterhin zehn Einheiten auf Lager an, bis der nächste geplante Synchronisierungslauf am Abend stattfindet. Ihr ahnungsloser Vertriebsmitarbeiter trifft nun wichtige Upselling-Entscheidungen auf Basis völlig veralteter Daten. Das Problem liegt nicht unbedingt darin, dass Ihr Synchronisierungsskript fehlgeschlagen ist. Der grundlegende Fehler besteht darin, dass kopierte Informationen zwischen den Synchronisierungszyklen zwangsläufig veralten.

Außerdem wirft das Kopieren von Informationen eine berüchtigte Architekturfrage auf: Welches System besitzt eigentlich die maßgebliche Wahrheit? Wenn ein Produkt im ERP-System existiert, eine duplizierte Kopie aber in Dataverse liegt und jemand Beschreibung, Preis oder Verfügbarkeitsstatus an einer Stelle ändert, muss irgendjemand oder irgendetwas entscheiden, welche Version gilt. Klassische Synchronisierung führt zu echten Albträumen bei der Datenkonsistenz. Virtuelle Tabellen verfolgen einen völlig anderen Ansatz: Das ursprüngliche Geschäftssystem behält die vollständige Hoheit über den Datensatz, während Benutzer in Dynamics 365 diese Informationen bei Bedarf sicher abfragen können.

Stellen Sie sich vor, Sie bewahren identische Dokumente in zwei getrennten Aktenschränken auf. Einer gehört der Vertriebsabteilung, der andere dem Lager. Jedes Mal, wenn jemand ein Dokument in einem Schrank ändert, muss er persönlich hinübergehen und die Kopie im anderen Schrank aktualisieren. Verpasst man auch nur ein einziges Update, widersprechen sich beide Schränke sofort. Genau so funktioniert klassische Synchronisierung. Virtuelle Tabellen bieten einen besseren Weg: Anstatt eine fragile zweite Kopie zu pflegen, erhalten Ihre Teams ein sicheres Echtzeitfenster in den Originalschrank.

Virtuelle Tabellen in Dynamics 365 im Überblick

Organisationen erklären häufig, sie wollten „ein System“ haben, das alles vereint. Doch wenn Sie mit den Mitarbeitenden im Alltag sprechen, brauchen sie eigentlich nur einen Ort, an dem sie arbeiten können. Ein Vertriebsmitarbeiter sollte nicht Dynamics 365 geöffnet halten, per Alt-Tab in ein ERP-System wechseln, um den Lagerbestand zu prüfen, eine dritte Altanwendung für den Rechnungsstatus öffnen und schließlich zum Kundendatensatz zurückkehren müssen. Mitarbeitende wollen einen einheitlichen Arbeitsbereich. Virtuelle Tabellen bringen ausgewählte externe Informationen direkt in die native Dynamics 365-Oberfläche, während spezialisierte Systeme weiterhin ihre jeweiligen Geschäftsprozesse steuern.

Wenn Sie schon länger mit dem Business-Applications-Stack von Microsoft arbeiten, stoßen Sie vielleicht noch auf den älteren Begriff „Virtual Entities“ – in Legacy-Dokumentationen, in technischen Foren oder in Gesprächen mit erfahrenen Entwicklern. Die aktuelle Microsoft-Terminologie lautet Virtual Tables. Unabhängig davon, wie Sie sie nennen, bleibt das Kernkonzept dasselbe: Dynamics 365 und Dataverse können externe Informationen so darstellen, als würden Benutzer mit einer nativen Dataverse-Tabelle arbeiten, während die eigentlichen Datensätze sicher außerhalb von Dataverse gespeichert bleiben.

Um den Unterschied zu verstehen, vergleichen Sie eine normale Dataverse-Tabelle mit einer Virtual Table. Bei einer Standard-Dataverse-Tabelle werden die Datensätze direkt in der Dataverse-Datenbank gespeichert. Konten, Kontakte, Opportunities und benutzerdefinierte Tabellen sind typische Beispiele dafür. Bei einer Virtual Table definiert Dataverse lediglich, wie die externen Informationen erscheinen sollen und wie sie abgerufen werden. Die Datensätze selbst liegen jedoch an einem völlig anderen Ort. Stellen Sie sich einen Bibliothekskatalog vor. Er enthält Informationen über ein Buch: den Titel, den Autor und den Standort im Regal. Der Katalog ist aber nicht das Buch selbst. Eine Virtual Table funktioniert genauso. Dataverse kennt die Struktur und weiß, wie der Datensatz angefordert wird, aber die Daten selbst befinden sich im externen System.

Wie Virtual Tables ein Live-Fenster zu externen Daten öffnen

Virtual Tables arbeiten mit einem Modell für den Datenzugriff zur Laufzeit. Anstatt jeden einzelnen externen Datensatz abzurufen und dauerhaft lokal zu speichern, lädt eine Virtual Table Informationen dynamisch, wenn die Anwendung sie tatsächlich benötigt. Ein Benutzer kann eine bestimmte Ansicht öffnen, nach bestimmten Datensätzen suchen, einen Filter anwenden oder eine einzelne Zeile auswählen. Dataverse fordert dann genau in diesem Moment nur die relevanten Informationen vom externen System an.

Stellen Sie sich einen Account Manager vor, der mit einem großen Kunden über einen umfangreichen potenziellen Auftrag spricht. Der Kunde möchte im nächsten Monat 500 Einheiten bestellen. Ohne die vertraute Oberfläche von Dynamics 365 zu verlassen, öffnet der Account Manager die zugehörigen Informationen zur Produktverfügbarkeit. Er sieht die Artikelnummer, den Lagerstandort, die verfügbare Menge und den voraussichtlichen Nachschubtermin. Diese Informationen stammen in Echtzeit direkt aus dem externen Lager- oder ERP-System, anstatt sich auf die Bestandsliste von gestern zu stützen, die man importiert hat. Dynamics 365 dient als einheitlicher Arbeitsbereich, während das Lagersystem die maßgebliche Quelle für den Bestand bleibt.

Diese Laufzeitarchitektur vermeidet die Risiken von Datendopplungen. Wenn ein Benutzer eine Abfrage ausführt, durchläuft die Anwendung einen klar strukturierten Ablauf. Ein Vertriebsmitarbeiter öffnet eine Produktliste und filtert nach verfügbaren Artikeln. Dataverse erkennt, dass es sich beim Ziel um eine Virtual Table handelt. Der zugrunde liegende Datenprovider empfängt die Anfrage, nutzt die Verbindungsdetails der Datenquelle, um den externen Dienst zu kontaktieren, übersetzt den Filter des Benutzers in ein Format, das das externe System versteht, ruft die passenden Datensätze ab, wandelt die Ergebnisse in Standard-Dataverse-Zeilen um und zeigt sie sofort in der Benutzeroberfläche an. Der Benutzer erlebt eine nahtlose Bedienung, während die Daten ihren maßgeblichen Speicherort nie verlassen.

Die drei zentralen Bausteine: Datenprovider, Datenquellen und Tabellen

Damit dieser Mechanismus im Hintergrund funktioniert, stützt sich jede Virtual Table auf drei zentrale Architekturbausteine: den Datenprovider, die Datenquelle und die Definition der Virtual Table selbst. Wer eine belastbare Integrationsstrategie entwerfen möchte, sollte diese drei Komponenten unbedingt verstehen.

Was ist ein Datenprovider?

Der Datenprovider fungiert als zentraler Übersetzer in der Architektur. Dynamics 365 und Dataverse senden Anfragen mithilfe ihrer eigenen internen Konzepte – Tabellen, Spalten, Filter und Datensatz-IDs. Das externe System verwendet jedoch meist eine völlig andere API, ein anderes Protokoll oder ein anderes Datenformat. Der Provider übersetzt zwischen diesen beiden Welten. Benutzer müssen diese komplexe Kommunikation nicht verstehen; sie arbeiten einfach über die Standard-Oberfläche von Dynamics 365 mit den resultierenden Datensätzen.

Microsoft bietet standardmäßig Unterstützung für einen OData-Version-4-Anbieter. OData stellt einen standardisierten, branchenweit akzeptierten Ansatz bereit, um Daten im Web verfügbar zu machen und abzufragen. Wenn Ihr externer Dienst Produkte über OData bereitstellt, die Felder wie Artikelnummern, Beschreibungen, Stückpreise und verfügbare Mengen enthalten, kann der integrierte Anbieter diese Datensätze abrufen und in einer Struktur zurückgeben, die Dataverse nativ versteht. Für moderne Cloud-Anwendungen gestaltet sich die Integration dadurch erstaunlich einfach.

Natürlich unterstützt nicht jede Legacy- oder individuell entwickelte Geschäftsanwendung OData. Wenn Ihre Architektur eine andere Integrationsmethode erfordert, können Organisationen benutzerdefinierte Datenanbieter implementieren. Ein erfahrener Entwickler kann einen benutzerdefinierten Anbieter schreiben, der Dataverse mit einer proprietären REST-API, einer SQL-Datenbank oder einem internen Unternehmenswebdienst verbindet. Unabhängig von der zugrunde liegenden Technologie übernimmt der benutzerdefinierte Anbieter stets dieselben grundlegenden Aufgaben: Er nimmt die Dataverse-Anfrage entgegen, kommuniziert mit dem externen System, übersetzt die Antwort und gibt die Datensätze nahtlos zurück.

Was ist eine Datenquelle?

Der Datenanbieter weiß, wie die Sprache gesprochen wird. Die Datenquelle enthält dagegen die konkrete Adresse und die Anmeldeinformationen, die für den Zugriff auf das Zielsystem erforderlich sind. Sie umfasst sämtliche Verbindungsinformationen für den externen Dienst, einschließlich Dienstendpunkt, Authentifizierungsparameter, API-Schlüssel und verbindungsbezogene Drosselungseinstellungen. Man kann sich den Anbieter als Sprachexperten und die Datenquelle als Adressbuch vorstellen.

Zuordnung externer Spalten und eindeutiger Datensatz-IDs

Sobald die Verbindung hergestellt ist, müssen Sie die externen Spalten dem Schema Ihrer virtuellen Tabelle zuordnen. Beispielsweise nennt die Lageranwendung ein Feld möglicherweise „Verfügbare Menge“, während Ihre Dynamics-365-Benutzer lieber „Lagerbestand“ sehen. Die Feldzuordnung teilt Dataverse mit, dass diese beiden unterschiedlichen Bezeichnungen exakt dieselbe Information darstellen. So können Organisationen in Dynamics 365 eine benutzerfreundliche Terminologie verwenden, ohne das externe System zu kostspieligen Umbenennungen seines Schemas zu zwingen.

Zusätzlich benötigt Dataverse für jeden Datensatz einen verlässlichen eindeutigen Bezeichner, um einen Eintrag von einem anderen zu unterscheiden. Datensätze virtueller Tabellen müssen zuverlässige eindeutige Schlüssel besitzen, die Dataverse erkennen kann. Ohne eine robuste ID kann Dataverse nicht eindeutig feststellen, welches Produkt, welche Rechnung oder welcher Kunde vom Benutzer ausgewählt wurde. Die Datensatzidentität ist daher eine zentrale technische Voraussetzung, wenn Sie beurteilen, ob eine bestimmte externe Datenquelle mit virtuellen Tabellen effektiv funktionieren kann.

Wann Sie virtuelle Tabellen in Ihrer Architektur einsetzen sollten

Virtuelle Tabellen markieren einen echten architektonischen Paradigmenwechsel. Sie eignen sich besonders dort, wo ein spezialisiertes externes System eindeutig die Stammdaten verwaltet, Benutzer in Dynamics 365 aber im Arbeitsalltag kontextbezogen auf diese Informationen zugreifen müssen. Typische Beispiele sind die Live-Bestandsverfolgung, komplexe Produktkataloge, Status von Bestellungen, Echtzeitstatus von Rechnungen, Zusammenfassungen von Hauptbuchkonten, Lieferantenverzeichnisse und gezielte Marketing-Erkenntnisse.

Indem Sie das externe System für den Lebenszyklus des Geschäftsdatensatzes verantwortlich lassen und Benutzern in Dynamics 365 zugleich kontextbezogene Einblicke geben, vermeiden Sie Datenduplizierung, reduzieren den Speicherbedarf in Dataverse und stellen sicher, dass Ihre Teams immer auf Basis aktueller, korrekter Informationen entscheiden. Es ist an der Zeit, das Kopieren Ihrer Daten zu beenden und die Möglichkeiten moderner Virtualisierung zu nutzen.

Kurz gesagt: Wenn Sie sich von der traditionellen Datensynchronisierung lösen und auf virtuelle Tabellen setzen, kann das Ihre Microsoft-365-Architektur deutlich verschlanken. Sie behalten Ihre zentrale Single Source of Truth bei, vermeiden veraltete Datenfenster und bieten Ihren Benutzern den einheitlichen Arbeitsbereich, den sie sich seit Langem wünschen. Für einen tieferen Einstieg in dieses Thema hören Sie sich unbedingt die vollständige Folge unter Dynamics 365 Virtual Entities - Simply Explained an.