Progettare l’integrazione fra Dataverse e i sistemi esterni richiede due decisioni intrecciate: come autenticarsi e quale pattern di comunicazione adottare. Da developer PL-400 devi motivare entrambe in funzione di sicurezza, affidabilità e latenza dello scenario.

Autenticazione con Microsoft Entra ID

Ogni chiamata alla Dataverse Web API (https://<org>.crm.dynamics.com/api/data/v9.2/) è protetta da Microsoft Entra ID tramite OAuth 2.0. Il token va richiesto specificando come resource/scope l’URL dell’ambiente (.../.default), non un endpoint generico.

Le identità in gioco sono tre:

  • Utente interattivo — flow authorization code con consenso. Adatto ad app presidiate (SPA, canvas app che chiama un servizio), dove agisci per conto dell’utente.
  • Service principal — l’identità di una app registration in Entra ID. Usa il flow client credentials (client id + secret o, meglio, certificato) per scenari server-to-server (S2S) non presidiati.
  • Managed identity — quando il codice gira su una risorsa Azure (Function, Logic App, Web App): elimina del tutto la gestione dei segreti.

Service principal e application user

Registrare l’app in Entra ID non basta: quel service principal deve esistere anche dentro Dataverse come application user. Si crea nell’admin center (Power Platform), associandolo all’app id e assegnandogli una security role con i privilegi minimi necessari (principio del least privilege). Senza application user il token è valido ma le chiamate rispondono 401/403.

Vantaggi dell’application user per le integrazioni non presidiate:

  • Nessuna licenza utente consumata e nessun account umano coinvolto.
  • Indipendenza da password, MFA e abbandoni: l’integrazione non si rompe se una persona lascia l’azienda.
  • Audit pulito: le operazioni risultano eseguite dall’identità applicativa.

Scelta del pattern di integrazione

Pattern Quando Note
Chiamata API diretta Dataverse deve leggere/scrivere in un sistema esterno in modo sincrono Semplice, ma accoppiato: se il target è giù, l’operazione fallisce
Webhook Notificare in near real-time un endpoint HTTPS su un evento tabella Sincrono/asincrono, payload piccolo, timeout stretti; il destinatario deve essere sempre disponibile
Azure Service Bus Disaccoppiare, garantire consegna e assorbire i picchi Buffer con retry e dead-letter queue; ideale per volumi alti e resilienza
Dual-write Sincronizzazione bidirezionale real-time con app Dynamics 365 Finance & Operations Mappatura tabelle out-of-the-box, non un pattern generico

Webhook e Service Bus si registrano tramite il plug-in registration (o ServiceEndpoint) e possono scattare in modalità asincrona dopo l’operazione (post-operation), evitando di bloccare la transazione dell’utente.

Real-time vs batch

  • Real-time / event-driven: webhook o Service Bus su singolo evento. Bassa latenza, ma richiede idempotenza (lo stesso messaggio può arrivare più volte) e gestione degli errori transitori.
  • Batch / scheduled: un processo periodico (Azure Function timer, pipeline di Azure Data Factory, o Microsoft Fabric per analytics) legge molte righe con query OData/FetchXML paginate. Migliore per grandi volumi e sistemi che non tollerano micro-chiamate, a costo di dati meno freschi.

La regola pratica: eventi puntuali a bassa latenza → real-time asincrono con coda; grandi moli o riconciliazioni → batch.

Sicurezza e affidabilità

  • Segreti in Azure Key Vault, o managed identity per non averne affatto.
  • Least privilege sulla security role dell’application user, scoped alle sole tabelle necessarie.
  • Affidabilità: preferisci pattern con retry e dead-lettering (Service Bus) quando la perdita di un messaggio è inaccettabile; i webhook sincroni non offrono garanzie di consegna native.
  • Idempotenza lato consumer per gestire duplicati e ritentativi.

Trappole tipiche d’esame

  • Integrazione notturna non presidiata che deve scrivere in Dataverse → usa un service principal + application user con client credentials, mai le credenziali di un utente reale o un account di servizio con password.
  • Serve consegna garantita e resilienza ai picchi verso un sistema esterno → Azure Service Bus (retry + dead-letter), non un webhook sincrono.
  • App registrata in Entra ID ma le chiamate tornano 403 → manca l’application user in Dataverse (o la security role); registrare in Entra non concede privilegi sui dati.
  • Sincronizzazione real-time bidirezionale con Dynamics 365 Finance & Operations → dual-write, non plug-in custom o batch.
  • Codice ospitato in una Azure Function che chiama Dataverse → managed identity per eliminare la gestione dei segreti, invece di client secret hardcoded.