Integrazione Microsoft 365 HowTo

La possibilità di integrare l'applicativo di un’azienda con sistemi terzi consente è una caratteristica di importanza fondamentale: consente al personale dell’azienda di condividere automaticamente tutta una serie di informazioni che sarebbero altrimenti recuperabili solo tramite con un lungo lavoro manuale di copia/incolla. Ecco perché è fondamentale predisporre i propri sistemi per ricevere e per inviare informazioni.

Microsoft Office 365 è un servizio in abbonamento di Microsoft Corporation che nasce come evoluzione nel cloud della suite Office, e nell’ultimo anno ha conosciuto una diffusione senza precedenti. In questo post prenderemo come esempio l’integrazione con Microsoft 365 per capire i concetti base e i vantaggi in ottica di efficienza dei processi aziendali.

Autenticazione in Microsoft 365

Nella maggior parte dei casi, l’integrazione tra applicativi si struttura in tre step principali: 

• un'autenticazione di un applicativo verso l’altro;
• un’autorizzazione che permetta l’accesso alle informazioni che si vogliono integrare;
• il reperimento e aggiornamento delle informazioni, che può essere sincrono o asincrono (tipicamente mediante webhook).

Dopo aver registrato il proprio applicativo all’interno del proprio account Azure si può richiedere dei token per autenticarsi. 

È possibile autenticarsi come applicazione o come un utente specifico. Nel primo caso è possibile accedere alle risorse di tutti gli utenti in qualsiasi momento: questa è un’opzione consigliata, ad esempio, nel caso di job asincroni che devono interfacciarsi con Microsoft 365. 

Nel secondo caso invece il token, la chiave di accesso rilasciata, ha una durata molto inferiore rispetto al precedente ed è possibile accedere solamente alle risorse dello specifico utente.

Gestione dei permessi in Microsoft 365

Entrambi i token rilasciati nel punto precedente sono soggetti a dei permessi che determinano quali risorse possono essere visualizzate/modificate. 

Analogamente a quanto avviene per l’autenticazione, i permessi possono riguardare sia l’utente che l’applicazione. 

I permessi per utente tengono conto anche dei permessi che lo specifico utente ha all’interno di Microsoft 365: ad esempio, se l’utente Mario non ha il permesso di modificare gli eventi sul proprio calendario, anche dando questo permesso all’applicativo esterno, utilizzando il token relativo all’utente Mario non sarà possibile effettuare questa azione.

API e subscription in Microsoft 365

Dopo aver ottenuto un token valido, è possibile interagire con Microsoft 365 tramite le sue API (Application Programming Interface) che consentono di inserire e recuperare informazioni. 

È possibile anche chiedere a Microsoft 365 di tenerci aggiornati qualora qualche risorsa di nostro interesse venga modificata. Microsoft 365 gestisce questa feature tramite le subscription: è possibile dunque creare una subscription per una determinata risorsa, specificando la tipologia di eventi a cui si è interessati (creazione, modifica, eliminazione). 

Per tutta la durata della subscription (che dipende dal tipo di risorsa collegata), Microsoft 365 invierà una notifica al nostro applicativo ogni volta che un evento di nostro interesse si è verificato. La notifica viene trasmessa sotto forma di Webhook: sostanzialmente viene effettuata una chiamata POST HTTP con i dati relativi alla risorsa interessata dall’aggiornamento.

Facendo un esempio concreto: è possibile dire a 365 di notificare il nostro applicativo web tramite una chiamata ogni volta che il nostro Mario modifica un evento nel suo calendario.

In conclusione

Alla luce di quanto sopra, possiamo individuare due principali criticità: la durata delle subscriptions e la coerenza dei dati scambiati.

Come abbiamo visto, le subscriptions hanno una durata molto limitata (nell’ordine dei giorni). È quindi necessario implementare un meccanismo di refresh che, ciclicamente, chieda a Microsoft 365 di mantenere viva la subscription in questione, rinnovandone la scadenza. Questo può anche, in alcune casistiche, richiedere all’utente di rinnovare manualmente l’autorizzazione presso 365 della nostra applicazione.

Per quanto riguarda la coerenza dei dati scambiati: può capitare che la procedura per riportare una modifica dei dati di Microsoft 365 all’interno del nostro sistema (o il contrario) non sia perfettamente definita. 

Ad esempio, supponiamo di avere sincronizzati gli eventi a calendario di un utente. Se un evento viene eliminato dal calendario di Microsoft 365, come dobbiamo comportarci con il medesimo dato nel nostro sistema? 

Possiamo decidere di non fare nulla, di eliminarlo (cosa non sempre facile, soprattutto nei casi in cui tale dato ha acquisito altre relazioni all’interno del nostro software), oppure di scollegarlo dall’utente in questione. Chiaramente lo stesso problema si presenterà anche nel senso opposto.

Questi sono gli step minimi per fare un’integrazione con Microsoft 365. 

Nel mio prossimo post vi parlerò di come ho utilizzato l’integrazione con il Calendar 365 per aggiungere una funzionalità al nostro Nosco.