Stop met kopiëren van je data: waarom Dynamics 365 virtuele tabellen traditionele synchronisatie verslaan

By Mirko Peters · 2026-08-27

Welkom terug op de blog! In ons vak praten we veel over het samenbrengen van systemen, het slechten van silo's en ervoor zorgen dat gebruikers direct hebben wat ze nodig hebben. Maar er is een stille valkuil waar veel organisaties in trappen bij het integreren van hun bedrijfssystemen: de drang om alles te kopiëren. Vandaag duiken we diep in waarom traditionele datasynchronisatie voor enorme hoofd

Automatically translated with AI from the original post. Read the English original

Cover: Dynamics 365 Virtual Entities - Simply Explained

Als je een gedetailleerde audiotoelichting over dit onderwerp wilt horen, met praktijkvoorbeelden, bekijk dan zeker de bijbehorende podcastaflevering: Dynamics 365 Virtual Entities - Simply Explained.

De valkuilen van dataduplicatie en verouderde synchronisatietaken

Stel je dit scenario voor: je verkoopteam brengt de dag comfortabel door in Dynamics 365. Maar je voorraadniveaus staan in een apart magazijnsysteem, je facturen worden beheerd in een financiële applicatie en je productcatalogus wordt onderhouden in een heel ander ERP-systeem. De klassieke, standaardaanpak van veel IT-teams is het bouwen van een integratiepijplijn. Je schrijft geplande taken die al die informatie periodiek naar Dataverse kopiëren. Klinkt eenvoudig, toch?

Helaas leidt dit tot een architectuur vol dubbele records, vertragingen in de synchronisatie, mislukte batchverwerkingen en, het ergste van alles, verouderde informatie. Stel je voor dat je magazijnsysteem tijdens de nachtelijke synchronisatie tien eenheden op voorraad registreert. De volgende ochtend toont je Dynamics 365-dashboard trots diezelfde tien beschikbare eenheden. Maar tijdens de lunch koopt een klant die binnenloopt alle tien resterende eenheden en worden ze verzonden. Het magazijnsysteem weet meteen dat de voorraad officieel nul is. Dynamics 365 blijft echter tien op voorraad tonen tot de volgende geplande synchronisatie vanavond. Je ahnungslose verkoper neemt nu belangrijke upsellbeslissingen op basis van volledig verouderde informatie. Het probleem is niet per se dat je synchronisatiescript is mislukt; de fundamentele fout is dat gekopieerde informatie tussen synchronisatiecycli onvermijdelijk verouderd raakt.

Bovendien roept kopiëren een beruchte architectuurvraag op: welk systeem is eigenlijk de bron van de waarheid? Als een product in het ERP-systeem staat, maar er een gedupliceerde kopie in Dataverse staat, en iemand past de omschrijving, prijs of beschikbaarheid op één plek aan, dan moet iemand of iets bepalen welke versie wint. Traditionele synchronisatie levert dataconsistentieproblemen op waar je wakker van ligt. Virtuele tabellen bieden een heel andere aanpak: het oorspronkelijke bedrijfssysteem blijft volledig eigenaar van het record, terwijl Dynamics 365-gebruikers die informatie veilig kunnen opvragen wanneer dat nodig is.

Denk er eens aan als identieke documenten in twee afzonderlijke archiefkasten. De ene kast hoort bij de verkoopafdeling en de andere bij het magazijn. Telkens als iemand een document in de ene kast wijzigt, moet die fysiek naar de andere kast lopen om de kopie bij te werken. Mis je één update, dan spreken de twee kasten elkaar meteen tegen. Traditionele synchronisatie volgt precies dit patroon. Virtuele tabellen bieden een betere manier: in plaats van een kwetsbare tweede kopie te onderhouden, geef je je team een veilig, realtime venster op de originele kast.

Inzicht in Dynamics 365 virtuele tabellen

Organisaties willen vaak zeggen dat ze “één systeem” willen dat alles beheerst. Maar als je met dagelijkse medewerkers praat, hebben ze eigenlijk één plek nodig om te werken. Een verkoper zou Dynamics 365 niet open moeten houden, via alt-tab naar een ERP moeten schakelen om de voorraad te controleren, een derde verouderde applicatie moeten openen om de status van een factuur na te kijken, en pas dan terug moeten keren naar het klantrecord. Medewerkers willen een geïntegreerde werkomgeving. Virtuele tabellen brengen geselecteerde externe informatie rechtstreeks in de vertrouwde Dynamics 365-ervaring, terwijl gespecialiseerde systemen hun eigen bedrijfsprocessen blijven beheren.

Als je al een tijdje met de zakelijke applicatiestack van Microsoft werkt, kom je de oudere term "Virtual Entities" misschien nog tegen in verouderde documentatie, technische fora of gesprekken met ervaren ontwikkelaars. De bijgewerkte en huidige Microsoft-terminologie is Virtual Tables. Hoe je ze ook noemt, het kernconcept blijft hetzelfde: Dynamics 365 en Dataverse kunnen externe informatie tonen alsof gebruikers met een native Dataverse-tabel werken, terwijl de fysieke records zelf veilig buiten Dataverse opgeslagen blijven.

Om het verschil te begrijpen, vergelijk je een gewone Dataverse-tabel met een Virtual Table. Bij een standaard Dataverse-tabel staan de records rechtstreeks in de Dataverse-database. Accounts, contactpersonen, opportunities en aangepaste tabellen zijn daar goede voorbeelden van. Bij een Virtual Table definieert Dataverse alleen hoe de externe informatie moet verschijnen en hoe die opgehaald moet worden, maar de records staan volledig ergens anders. Denk aan een bibliotheekcatalogus. Een catalogus bevat informatie over een boek: je ziet de titel, de auteur en waar het boek op de fysieke plank staat. Maar de catalogus is niet het boek zelf. Een Virtual Table werkt precies op dezelfde manier. Dataverse kent de structuur en weet hoe het een record moet opvragen, maar het externe systeem bevat de daadwerkelijke data.

Hoe Virtual Tables een live venster naar externe data bieden

Virtual Tables werken met een runtime-model voor gegevenstoegang. In plaats van elk extern record op te halen en permanent lokaal op te slaan, haalt een Virtual Table informatie dynamisch op wanneer de applicatie die echt nodig heeft. Een gebruiker opent bijvoorbeeld een specifieke weergave, zoekt naar bepaalde records, past een filter toe of selecteert een afzonderlijke rij. Dataverse vraagt dan op dat moment alleen de relevante informatie op bij het externe systeem.

Stel dat een accountmanager een grote potentiële deal bespreekt met een belangrijke klant. De klant wil volgende maand 500 eenheden bestellen. De accountmanager blijft volledig binnen de vertrouwde Dynamics 365-interface en opent de bijbehorende productbeschikbaarheid. Hij of zij ziet het artikelnummer, de magazijnlocatie, de beschikbare hoeveelheid en de verwachte datum van aanvulling. Die informatie komt in realtime rechtstreeks uit het externe magazijn- of ERP-systeem, in plaats van uit het geïmporteerde voorraadoverzicht van gisteren. Dynamics 365 fungeert als de gedeelde werkomgeving, terwijl het magazijnsysteem de absolute autoriteit over de voorraad blijft.

Deze runtime-architectuur elimineert de risico's van gegevensduplicatie. Wanneer een gebruiker een query uitvoert, doorloopt de applicatie een gestroomlijnde reeks stappen. Een verkoper opent een productlijst en filtert op beschikbare artikelen. Dataverse herkent dat het doel een Virtual Table is. De onderliggende dataprovider ontvangt het verzoek, gebruikt de verbindingsgegevens van de gegevensbron om contact te leggen met de externe service, vertaalt het filter van de gebruiker naar een formaat dat het externe systeem begrijpt, haalt de overeenkomende records op, zet de resultaten om naar standaard Dataverse-rijen en toont ze direct in de gebruikersinterface. De gebruiker krijgt een naadloze ervaring, terwijl de data nooit zijn autoritatieve thuisbasis verlaat.

De drie kernbouwstenen: dataproviders, gegevensbronnen en tabellen

Om deze magie onder de motorkap mogelijk te maken, steunt elke Virtual Table op drie kernbouwstenen: de dataprovider, de gegevensbron en de Virtual Table-definitie zelf. Inzicht in deze drie componenten is essentieel voor iedereen die een robuuste integratiestrategie wil ontwerpen.

Wat is een dataprovider?

De dataprovider fungeert als de belangrijkste vertaler in de architectuur. Dynamics 365 en Dataverse sturen verzoeken met hun eigen interne concepten: tabellen, kolommen, filters en record-ID's. Het externe systeem gebruikt echter vaak een heel andere API, protocol of gegevensformaat. De provider vertaalt tussen deze twee kanten. Gebruikers hoeven dit complexe gesprek niet te begrijpen; zij werken gewoon met de resulterende records via de standaard Dynamics 365-applicatie-interface.

Microsoft biedt standaardondersteuning voor een OData Version 4-provider. OData biedt een gestandaardiseerde, breed geaccepteerde manier om gegevens via het web beschikbaar te stellen en op te vragen. Als je externe service producten beschikbaar stelt via OData, met velden zoals productnummers, omschrijvingen, stukprijzen en beschikbare aantallen, kan de ingebouwde provider die records opvragen en teruggeven in een structuur die Dataverse native begrijpt. Voor moderne cloudapplicaties maakt dit integreren opvallend eenvoudig.

Natuurlijk ondersteunt niet elke legacy- of maatwerkapplicatie OData. Als je architectuur een andere integratiemethode vereist, kunnen organisaties Custom Data Providers implementeren. Een ervaren developer kan een custom provider schrijven die Dataverse koppelt aan een eigen REST-API, een SQL-database of een interne webservice. Ongeacht de onderliggende technologie voert de custom provider steeds dezelfde basistaken uit: de Dataverse-aanvraag ontvangen, communiceren met het externe systeem, het antwoord vertalen en de records naadloos teruggeven.

Wat is een Data Source?

Als de Data Provider weet hoe hij de taal moet spreken, bevat de Data Source het exacte adres en de inloggegevens die nodig zijn om de bestemming te bereiken. De Data Source bevat alle verbindingsinformatie voor de externe service, waaronder het service-eindpunt, authenticatieparameters, API-sleutels en verbindingsgerelateerde throttling-instellingen. Zie de provider als de taalexpert en de source als het adresboek.

Externe kolommen mappen en unieke record-ID's

Zodra de verbinding tot stand is, moet je je externe kolommen mappen op het schema van je Virtual Table. Bijvoorbeeld: de magazijnapplicatie noemt een veld "Available Quantity", terwijl je Dynamics 365-gebruikers liever "Stock on Hand" zien. De veldmapping vertelt Dataverse dat deze twee verschillende namen exact dezelfde informatie vertegenwoordigen. Zo kunnen organisaties in Dynamics 365 begrijpelijke terminologie gebruiken zonder het externe systeem te dwingen tot kostbare hernoemingen van het schema.

Daarnaast heeft Dataverse voor elk record een betrouwbare unieke identifier nodig om het ene item van het andere te onderscheiden. Records in een Virtual Table moeten betrouwbare unieke sleutels hebben die Dataverse kan herkennen. Zonder een robuuste ID kan Dataverse niet met zekerheid bepalen welk exact product, welke factuur of welke klant de gebruiker heeft geselecteerd. Recordidentiteit is daarom een cruciale technische voorwaarde bij de beoordeling of een externe gegevensbron effectief via Virtual Tables kan werken.

Wanneer Virtual Tables gebruiken in je architectuur

Virtual Tables vormen een krachtige verschuiving in architectuurdenken. Ze werken het best in scenario's waarin een gespecialiseerd extern systeem duidelijk eigenaar is van de masterdata, maar Dynamics 365-gebruikers tijdens hun dagelijkse werk contextuele toegang tot die informatie nodig hebben. Voorbeelden zijn realtime voorraadtracking, complexe productcatalogi, orderstatussen van inkooporders, actuele factuurstatussen, financiële grootboeksamenvattingen, leveranciersdirectories en gerichte marketinginzichten.

Doordat de externe applicatie verantwoordelijk blijft voor de levenscyclus van het zakelijke record, terwijl Dynamics 365-gebruikers contextueel inzicht krijgen, elimineer je de risico's van gegevensduplicatie, beperk je de opslagzwaarte in Dataverse en zorg je ervoor dat je teams altijd beslissingen nemen op basis van actuele, accurate informatie. Het is tijd om te stoppen met het kopiëren van je data en de kracht van moderne virtualisatie te gaan benutten.

Kortom: afstappen van traditionele datasynchronisatie en overstappen op Virtual Tables kan je Microsoft 365-architectuur aanzienlijk stroomlijnen. Je houdt je single source of truth intact, elimineert verouderde datavensters en geeft je gebruikers de geïntegreerde werkomgeving waar ze al lang om vragen. Wil je hier dieper op ingaan, luister dan zeker de volledige aflevering via Dynamics 365 Virtual Entities - Simply Explained.