Indice dei contenuti
Questo articolo costituisce la parte introduttiva di una serie di approfondimenti sul Microsoft Bot Framework ed è dedicato ai concetti generali del Microsoft Bot Framework, il sistema messo a disposizione da Microsoft per sviluppare bot di vario tipo, con funzionalità semplici o avanzate a seconda dei casi e delle esigenze.
Gli argomenti che tratteremo, in gran parte relativi alle caratteristiche fondamentali del Software Developer Kit (Bot Framework SDK), saranno particolarmente utile negli articoli successivi, nel corso dei quali vedremo come creare un Bot con Microsoft Bot Framework, ASP.NET Core e C#.
Introduzione
Il Microsoft Bot Framework è un set di strumenti che consentono agli sviluppatori di creare, testare, distribuire e gestire bot. Le sue componenti principali sono:
- Un Software Developer Kit (Bot Framework SDK) modulare ed estensibile per la creazione di bot, disponibile per C#, JavaScript, Typescript e Python.
- Un ambiente di test (Bot Framework Emulator), che consente di interagire con i bot e valutare il funzionamento prima del rilascio.
- Una Command-Line Interface (Bot Framework CLI), ovvero una serie di comandi console che consentono di gestire il funzionamento dei bot prima e dopo il rilascio.
- Uno strumento di composizione visuale (Bot Framework Composer), disponibile sia come desktop application che come applicazione web, che consente di progettare e creare bot di vario tipo anche senza conoscere i linguaggi di programmazione, nonché di sviluppare i workflow conversazionali all’interno di un ambiente visuale.
- Un servizio dedicato su MS Azure (Bot Service), che consente di pubblicare il bot sotto forma di web application con un endpoint HTTP raggiungibile dall’esterno, e di abilitarlo per la connessione su uno o più canali.
In questa serie di articoli vedremo come utilizzare ciascuno questi strumenti - con la sola eccezione del Bot Framework Composer - per sviluppare ed effettuare il deploy dei nostri bot.
Come funziona
L'insieme elementi di cui si compone il Microsoft Bot Framework ci consente di immaginare il funzionamento dell'infrastruttura e l'interazione tra le varie componenti.
Cerchiamo di spiegare gli aspetti fondamentali di questo diagramma:
- Il bot è in buona sostanza una web application (o un web service, se preferiamo definirlo così) realizzata su Visual Studio 2019 tramite la Bot Framework SDK.
- Il Bot Framework Emulator consente di testare la web application sia nel nostro ambiente di sviluppo locale, connettendosi all'endpoint privato reso disponibile da Visual Studio su localhost, sia una volta effettuato il deploy, connettendosi all'endpoint pubblico fornito dall'Azure Bot Service.
- Una volta effettuato il deploy, l'endpoint pubblico del bot potrà essere utilizzato dagli appositi Connector dell'Azure Bot Service che consentono di gestire l'interazione tra il bot e gli utenti dei vari canali ai quali il bot sarà abilitato.
Flussi di comunicazione e HTTP lifecycle
A questo punto è ragionevole chiedersi: ma come avviene, tecnicamente, questa attività di scambio di informazioni tra la chat e il bot? Nel caso dell’emulatore possiamo immaginarlo facilmente, visto che di fatto l’emulatore si connette proprio alla URL della nostra web application: ma in che modo questo può avvenire in un ambiente di produzione, come ad esempio una chat di Microsoft Teams?
La risposta ce la fornisce questo diagramma, che illustra in modo piuttosto chiaro lo scambio delle informazioni tra l’ambiente di chat e il nostro bot.
Cerchiamo di riassumerne i punti salienti:
Ogni interazione tra gli utenti e il bot genera un'attività. Il Bot Connector Service cattura quell’attività e la invia al nostro bot attraverso una request HTTP asincrona. Il bot riceve la request e risponde al servizio con uno status code 200, dando così conferma di avvenuta ricezione: questa conferma è molto importante, in quanto consente al Bot Connector Service di comprendere che il nostro bot è attivo, ovvero in grado di ricevere le notifiche relative alle varie attività.
Nel caso in cui l’attività generi un’azione da parte del bot, come nei due casi che abbiamo analizzato poco fa, il bot effettua una chiamata di ritorno - sempre tramite HTTP post - in cui invia la sua azione: solitamente si tratta di uno o più messaggi, ma in determinati casi potrebbe essere qualcosa di diverso, come ad esempio l’uscita dalla chat. Anche le chiamate effettuate dal Bot sono effettuate in modo asincrono e ricevono una conferma da parte del Bot Connector Service, che certifica in questo modo l’avvenuta ricezione.
Azure Bot Service
Adesso che il flusso HTTP è più chiaro, non resta che capire cosa sia questo Bot Connector Service: come suggerisce il nome, si tratta di un servizio ad-hoc, fornito da Microsoft tramite la piattaforma Azure, motivo per cui è oggi considerato una parte integrante dell’infrastruttura denominata Azure Bot Service, che ha il compito di connettere il nostro bot con il canale o i canali in cui scegliamo di rendere il bot attivo.
Con il termine canale intendiamo l’applicazione di messaggistica che mette a disposizione la chat dove il bot si trova ad operare: restando in ambiente Microsoft il pensiero va subito Microsoft Teams, ma il Bot Service supporta anche moltissimi altri canali di terze parti, tra cui Telegram, Slack, LINE, e così via. Questo ci fa comprendere un altro concetto fondamentale del Microsoft Bot Framework, ovvero il fatto che consente di sviluppare bot che saranno a tutti gli effetti channel-agnostic, ovvero indipendenti dal canale in cui andremo a utilizzarli: il flusso di comunicazione tra ciascuna applicazione di messaggistica e il bot sarà infatti normalizzato dal connector messo a disposizione dal Bot Service, che si occuperà di trovare il modo più adeguato per mettere in connessione questi due attori in modo trasparente per lo sviluppatore.
Ovviamente, affinché il Bot Service (e relativo connector) possa occuparsi di gestire le comunicazioni tra il nostro bot e una qualsivoglia applicazione, deve essere a conoscenza del fatto che il nostro bot esiste e che sia stato abilitato alla connessione con quel determinato canale. Per questo motivo è necessario effettuare il deploy del bot su Microsoft Azure e configurarlo in tal senso, oltre a installarlo all’interno del canale stesso, con modalità che cambiano a seconda dell’applicazione. Alcune app richiedono di creare un account da associare al bot; altre, come ad esempio Facebook Messenger o Microsoft Teams, richiedono anche di registrare un’applicazione ad-hoc. Di tutti questi aspetti ci occuperemo meglio nei prossimi articoli, quando ci occuperemo del deploy e dell'attivazione del nostro bot.
Il concetto di Turn
Prima di concludere questa panoramica è il caso di approfondire un ulteriore concetto alla base dell’attività del Bot Framework SDK, noto con il nome di Turn, che in italiano è traducibile come turno.
Come sappiamo tutti, in una conversazione le persone sono solite parlare una alla volta: quando questo non accade, e la conversazione è gestita da un moderatore, è probabile che quest’ultimo chieda ai partecipanti di alternarsi, così da evitare di parlare gli uni sopra agli altri: in altre parole, chiede di fare a turno.
All’interno del Microsoft Bot Framework, un turno è costituito da un insieme che raggruppa l’attività dell’utente che arriva al bot e la risposta del bot a quella determinata attività. Possiamo quindi pensare a un turno come a un singolo scambio di una partita di tennis: un colpo a cui segue un altro colpo; volendo declinare la cosa in termini tecnici, possiamo affermare che un turno è un contesto di esecuzione che prevede un input (la activity ricevuta dal bot) e un output (l’activity inviata dal bot in risposta).
Questo contesto di esecuzione, che nell’SDK viene chiamato TurnContext, è una delle astrazioni fondamentali del Bot Framework, in quanto veicola sia l’attività in entrata che il meccanismo con cui inviare eventuali attività in uscita a tutti i componenti middleware e alla logica dell'applicazione. Questo duplice utilizzo è evidente in tutti i bot che prevedono un'interazione con l'utente, che prevedono event handler in cui il TurnContext viene utilizzato sia per estrarre le informazioni contenute nell’activity di input (ad es. il testo inserito dall’utente nel primo metodo) che per inviare la risposta da parte del bot. Questo importante concetto sarà ulteriormente approfondito all'interno dei prossimi articoli, dedicati allo studio del codice sorgente di due diverse tipologie di bot.
Ambiente di sviluppo
Poiché nei prossimi articoli ci addentreremo nella creazione di alcune tipologie di bot tramite il Bot Framework SDK, è opportuno spendere qualche minuto per spiegare come preparare il relativo ambiente di sviluppo.
La prima cosa da fare è procedere con l'installazione dei seguenti componenti:
- Visual Studio 2019 (qualsiasi edizione): https://visualstudio.microsoft.com/it/downloads/
- Microsoft .NET Core 3.1 SDK: https://dotnet.microsoft.com/download
- Bot Framework SDK v4 Template per Visual Studio: https://marketplace.visualstudio.com/items?itemName=BotBuilder.botbuilderv4
- Bot Framework Emulator: https://github.com/Microsoft/BotFramework-Emulator/releases/latest
Per ragioni di tempo non ci soffermeremo sui dettagli relativi all’installazione dei singoli componenti, che comunque non presenta particolari difficoltà: l’unica raccomandazione da tenere presente è quella di procedere in ordine, in modo da installare i template per Visual Studio dopo l’installazione di Visual Studio.
Conclusione
Per il momento è tutto. Nel prossimo articolo ci dedicheremo all'analisi del codice di un bot molto semplice, che ci consentirà di approfondire alcuni concetti chiave dell’SDK relativi al funzionamento dell’architettura e delle interfacce di comunicazione che abbiamo introdotto in questo approfondimento.
Articoli correlati
- Indice degli argomenti
- Introduzione: cos'è un bot?
- Microsoft Bot Framework: concetti generali
- Microsoft Bot Framework: Esempio semplice - Echo Bot
- Microsoft Bot Framework: Esempio complesso - Dialog Bot
- Microsoft Bot Framework: Deploy su Azure Bot Service
- Microsoft Bot Framework: Integrazione con MS Teams
