Le virtual tables (in passato “virtual entities”) permettono di rappresentare in Dataverse dati che risiedono fisicamente in un sistema esterno, senza copiarli né replicarli. La tabella e le sue colonne sono definite nei metadata di Dataverse, ma i record vengono recuperati a runtime dalla sorgente al momento della query. Per app model-driven, viste, form, Web API e Dataverse SDK la virtual table appare come una tabella qualsiasi; ciò che cambia è che il dato non vive mai in Dataverse.

Il ruolo del data provider e di OData

Ogni virtual table è associata a un data source, che a sua volta usa un data provider. Il provider traduce le operazioni Dataverse (soprattutto Retrieve e RetrieveMultiple) in chiamate verso la sorgente. Le opzioni principali che il PL-400 si aspetta che tu conosca:

  • OData v4 Data Provider: provider integrato, no-code, per endpoint che espongono OData v4 (Web API). Storicamente read-only.
  • Virtual Connector Provider: provider basato sul framework dei connectors (es. SQL Server, Azure SQL) che collega tabelle esterne tramite una connection, con supporto CRUD nelle versioni recenti. È l’opzione low-code preferita quando esiste un connettore.
  • Custom data provider: sviluppato in codice registrando plug-in sui messaggi del provider (Retrieve, RetrieveMultiple, e per il CRUD Create, Update, Delete). Serve quando la sorgente non è raggiungibile via OData né via connettore, o quando devi mappare/trasformare i dati.

In tutti i casi ogni record richiede un identificatore univoco mappabile a un GUID come chiave primaria: se la sorgente non ha un ID rappresentabile in questo modo, l’integrazione non funziona correttamente.

Virtual tables o sincronizzazione periodica?

La scelta architetturale ricorrente è: virtual table oppure sync periodico (ETL, dataflow, integrazione che copia i dati dentro Dataverse).

Preferisci le virtual tables quando:

  • serve una vista real-time / always-fresh: il dato è letto direttamente alla fonte, niente latenza di sincronizzazione;
  • non vuoi duplicare dati (compliance, volumi elevati, single source of truth esterna);
  • l’accesso è prevalentemente in lettura e per volumi ragionevoli.

Preferisci la sincronizzazione (o un mirror in Dataverse) quando:

  • ti servono funzionalità native che le virtual tables non supportano (vedi sotto): rollup, audit, offline, analytics;
  • la sorgente è lenta o inaffidabile: ogni query utente colpisce il sistema esterno, quindi le prestazioni dipendono da esso;
  • devi fare reporting pesante o alimentare analytics (es. link verso Microsoft Fabric), che richiede change tracking.

Limitazioni note

Il punto centrale d’esame è che una virtual table non si comporta come una tabella nativa. In particolare:

  • CRUD parziale: con OData provider i campi sono tipicamente read-only; scrittura solo se il provider (Virtual Connector o custom) implementa le operazioni.
  • Rollup e colonne calcolate non sono supportati.
  • Auditing non supportato.
  • Change tracking non disponibile → niente Fabric/Synapse Link, niente sync incrementale verso data lake.
  • Nessun supporto offline per le app mobili.
  • Business rules limitate; alcune funzionalità (es. duplicate detection, note/allegati, ownership a livello utente) non si applicano — le virtual tables sono organization-owned.
  • Column-level security non applicabile.
  • Le prestazioni delle viste dipendono dalla sorgente e da come il provider gestisce filtri e paginazione: query non filtrate su tabelle esterne grandi possono degradare l’esperienza.

Sul fronte plug-in: per un custom provider scrivi plug-in sui messaggi del data provider; ma non puoi trattare la virtual table come una tabella standard su cui registrare liberamente logica su tutti gli eventi come faresti con una tabella nativa.

Trappole tipiche d’esame

  • Scenario: il cliente vuole audit trail e rollup su dati provenienti da un DB esterno → risposta: NON usare virtual table; sincronizza i dati in una tabella nativa Dataverse (audit e rollup non sono supportati sulle virtual tables).
  • Scenario: serve alimentare un lakehouse Microsoft Fabric con questi dati → risposta: le virtual tables non hanno change tracking; usa un mirror nativo con Link to Fabric, non una virtual table.
  • Scenario: la sorgente espone un endpoint OData v4 e serve solo lettura, in tempo reale, no codice → risposta: virtual table con OData v4 Data Provider.
  • Scenario: serve scrivere verso una tabella Azure SQL senza scrivere codice → risposta: Virtual Connector Provider (supporta CRUD), non l’OData provider read-only.
  • Scenario: gli utenti mobile devono lavorare offline su questi record → risposta: le virtual tables non supportano l’offline; opta per dati nativi sincronizzati.