Middleware

si applica a: SDK v4

Il middleware è semplicemente una classe che si trova tra l'adapter e la logica del bot, aggiunta alla raccolta middleware dell'adapter durante l'inizializzazione. L'SDK consente di scrivere il proprio middleware o di aggiungere middleware creato da altri utenti. Tutte le attività che entrano o escono dal bot passano attraverso il middleware.

L'adapter elabora e indirizza le attività in ingresso tramite la pipeline del middleware del bot alla logica del bot e quindi torna indietro. Quando ogni attività entra ed esce dal bot, ogni componente del middleware può ispezionare o agire in risposta all'attività, prima e dopo l'esecuzione della logica del bot.

Prima di passare al middleware, è importante comprendere i bot in generale e come elaborano le attività.

Applicazioni del middleware

La domanda viene spesso posta: "Quando è necessario implementare azioni come middleware rispetto all'uso della logica normale del bot?" Il middleware offre opportunità aggiuntive per interagire con il flusso di conversazione degli utenti sia prima che dopo l'elaborazione di ogni turno della conversazione. Il middleware consente anche di archiviare e recuperare informazioni relative alla conversazione e chiamare logica di elaborazione aggiuntiva quando necessario. Di seguito sono riportati alcuni scenari comuni che mostrano dove il middleware può essere utile.

Analizzare o intervenire su tutte le attività

Esistono molte situazioni che richiedono al bot di eseguire operazioni su ogni attività o per ogni attività di un determinato tipo. Ad esempio, è possibile registrare ogni attività del messaggio ricevuta dal bot o fornire una risposta di fallback se il bot non ha generato altrimenti una risposta a questo turno. Il middleware è un ottimo posto per questi processi, con la possibilità di agire sia prima che dopo l'esecuzione del resto della logica del bot.

Modifica o miglioramento del contesto del turno

Alcune conversazioni possono essere molto più efficaci se il bot ha più informazioni rispetto a quanto fornito nell'attività. In questo caso, il middleware potrebbe esaminare le informazioni sullo stato della conversazione che ha finora, eseguire query su un'origine dati esterna e accodare tale operazione all'oggetto contesto di turno prima di passare l'esecuzione alla logica del bot.

L'SDK definisce il middleware di registrazione in grado di registrare le attività in ingresso e in uscita, ma è anche possibile definire il proprio middleware.

Pipeline del middleware del bot

Per ogni attività, l'adattatore chiama middleware nell'ordine in cui è stato aggiunto. L'adattatore passa l'oggetto contesto per il turno e un delegato successivo e il middleware chiama il delegato per passare il controllo al middleware successivo nella pipeline. Il middleware ha anche l'opportunità di eseguire operazioni dopo il ritorno del delegato successivo prima di completare il metodo. È possibile considerarlo come ogni oggetto middleware ha la prima e l'ultima possibilità di agire rispetto agli oggetti middleware che lo seguono nella pipeline.

Per esempio:

• Il gestore dei turni del primo oggetto middleware esegue il codice prima di chiamare next.
  • Il secondo gestore dei turni dell'oggetto middleware esegue il codice prima di chiamare next.
    • Il gestore dei turni del bot viene attivato e restituisce.
  • Il secondo gestore dei turni dell'oggetto middleware esegue qualsiasi codice rimanente prima di restituire.
• Il gestore dei turni del primo oggetto middleware esegue tutto il codice rimanente prima di restituire.

Se il middleware non chiama il delegato successivo, l'adattatore non chiama nessuno dei middleware successivi né i gestori di turno del bot, e la pipeline si interrompe.

Al termine della pipeline di middleware del bot, il turno è concluso e il contesto della conversazione esce dal campo di applicazione.

Il middleware o il bot possono generare risposte e registrare gestori degli eventi di risposta, ma tener presente che le risposte vengono gestite in processi separati.

Ordine del middleware

Poiché l'ordine in cui viene aggiunto il middleware determina l'ordine in cui il middleware elabora un'attività, è importante decidere la sequenza da aggiungere al middleware.

Annotazioni

Questo è progettato per offrire un modello comune che funziona per la maggior parte dei bot, ma assicurati di considerare come ogni componente di middleware interagirà con gli altri per la tua situazione.

Middleware che si occupa delle attività di livello più basso dovrebbe essere aggiunto prima di tutto alla pipeline middleware di ogni bot. Ad esempio, la registrazione, la gestione delle eccezioni e la traduzione. Ordinarli in base alle proprie esigenze, ad esempio se si vuole che il messaggio in arrivo venga convertito per primo, prima che i messaggi vengano archiviati o se l'archiviazione dei messaggi deve verificarsi per prima, il che potrebbe significare che i messaggi archiviati non verranno tradotti.

Il middleware specifico del bot deve essere aggiunto per ultimo alla pipeline middleware. Questo è il middleware che implementi per eseguire un'elaborazione su ogni messaggio inviato al tuo bot. Se il tuo middleware utilizza informazioni sullo stato o altri insiemi di informazioni nel contesto del bot, aggiungilo alla pipeline del middleware dopo il middleware che modifica lo stato o il contesto.

Corto circuito

Un'idea importante sul middleware e sui gestori di risposta è il corto circuito. Se l'esecuzione deve continuare attraverso i livelli che lo seguono, il middleware (o un gestore di risposta) deve passare l'esecuzione chiamando il delegato successivo . Se il delegato successivo non viene chiamato all'interno di tale middleware (o gestore di risposta), i cortocircuiti della pipeline associati e i livelli successivi non vengono eseguiti. Ciò significa che tutta la logica del bot e qualsiasi middleware più avanti nella pipeline viene ignorata. C'è una differenza sottile tra il middleware e il gestore di risposta che cortocircuita un turno.

Quando il middleware interrompe un turno, il gestore dei turni del bot non verrà chiamato, ma tutto il codice middleware eseguito prima di questo punto nella pipeline verrà comunque eseguito fino a completamento.

Per i gestori eventi, non chiamando next significa che l'evento viene annullato, che è molto diverso dalla logica di skipping del middleware. Non elaborando il resto dell'evento, l'adapter non lo invia mai.

Suggerimento

Se si interrompe un evento di risposta, come SendActivities, accertarsi che corrisponda al comportamento previsto. In caso contrario, può risultare difficile correggere i bug.

Gestori di eventi di risposta

Oltre alla logica dell'applicazione e del middleware, i gestori di risposta (detti anche gestori eventi o gestori eventi di attività) possono essere aggiunti all'oggetto contesto. Questi gestori vengono chiamati quando la risposta associata si verifica nell'oggetto di contesto corrente, prima di eseguire la risposta effettiva. Questi gestori sono utili quando si sa che si vuole eseguire un'operazione, prima o dopo l'evento effettivo, per ogni attività di quel tipo per il resto della risposta corrente.

Avvertimento

Prestare attenzione a non chiamare un metodo di risposta dell'attività dall'interno del rispettivo gestore eventi di risposta, ad esempio chiamando il metodo di invio dell'attività dall'interno di un gestore dell'attività di invio. In questo modo è possibile generare un ciclo infinito.

Tenere presente che ogni nuova attività ottiene un nuovo thread su cui eseguire. Quando il thread per elaborare l'attività viene creato, l'elenco dei gestori per tale attività viene copiato in tale nuovo thread. Nessun gestore aggiunto dopo tale punto verrà eseguito per tale evento di attività specifico. I gestori registrati in un oggetto di contesto vengono gestiti in modo analogo al modo in cui l'adattatore gestisce la pipeline middleware. Ovvero, i gestori vengono chiamati nell'ordine in cui vengono aggiunti e chiamando il delegato successivo passa il controllo al gestore eventi registrato successivo. Se un gestore non chiama il delegato successivo, nessuno dei gestori eventi successivi viene chiamato, l'evento viene interrotto e l'adattatore non invia la risposta al canale.

Gestione dello stato nel middleware

Un metodo comune per salvare lo stato consiste nel chiamare il metodo save changes alla fine del gestore dei turni. Ecco un diagramma con un'enfasi sulla chiamata.

Il problema di questo approccio è che gli aggiornamenti di stato eseguiti da middleware personalizzati, successivi al ritorno del gestore di turno del bot, non verranno salvati in un archivio permanente. La soluzione consiste nello spostare la chiamata al metodo save changes dopo il completamento del middleware personalizzato, aggiungendo un'istanza del middleware di salvataggio automatico delle modifiche all'inizio dello stack del middleware, o almeno prima di qualsiasi middleware che potrebbe aggiornare lo stato. L'esecuzione è illustrata di seguito.

Aggiungere gli oggetti di gestione dello stato che dovranno essere aggiornati a un oggetto del set di stati del bot e quindi usarli quando si crea il middleware per il salvataggio automatico delle modifiche.

Risorse aggiuntive

È possibile esaminare il middleware del registratore di trascrizioni, come implementato in Bot Framework SDK [C# | JS].