Tramite uno script \u00e8 possibile importare dati da Microsoft Dynamics 365 utilizzando il protocollo oData e autenticandosi tramite il protocollo oAuth2.<\/p>\n
Queste tecnologie rappresentano lo stato dell’arte per quanto riguarda rispettivamente l’accesso ai dati RESTful e l’autenticazione a servizi in Cloud, e l’esempio sotto riportato \u00e8 quindi particolarmente importante costituendo un punto di partenza dal quale derivare altre soluzioni facendo uso di tali tecnologie.<\/p>\n
Autenticazione oAuth2<\/strong><\/p>\n Il protocollo oAuth2 viene utilizzato sia da Microsoft che da Google per l’accesso ai rispettivi servizi Cloud. Nel caso di Microsoft, e quindi di Dynamics 365, la gestione degli utenti avviene tramite Azure Active Directory (AAD), che fra le altre cose \u00e8 in grado di gestire l’appartenenza degli utenti stessi ad un dominio specifico (quello dell’azienda, es. “qualiware.it”). Pertanto ogni azienda potr\u00e0 usare il proprio dominio e registrare gli utenti sulle varie applicazioni. <\/p>\n Una applicazione esterna, come ad esempio QualiWare, dovr\u00e0 effettuare apposite chiamate per autenticarsi e utilizzare i servizi messi a disposizione dall’applicazione Microsoft, e per fare questo non \u00e8 sufficiente disporre di un utente e una password, ma sar\u00e0 necessario registrare l’applicazione esterna stessa all’interno di AAD, per ottenere il cosiddetto Application ID (spesso chiamato anche Client ID) che andr\u00e0 specificato nelle suddette chiamate. <\/p>\n L’autenticazione con utente e password \u00e8 possibile se l’applicazione esterna \u00e8 registrata come “Native”. Se viene registrata come “Web App\/Api”, \u00e8 necessario utilizzare il cosiddetto “Client Secret”, che viene reperito nella scheda di registrazione dell’app all’interno di Active Directory.<\/p>\n Le immagini seguenti riportano un esempio di maschera di registrazione “Native” e “Web App\/Api” all’interno di AAD.<\/p>\n\n\t\t