Middleware

SI APPLICA A: SDK v4

Il middleware è semplicemente una classe che si trova tra l'adapter e la logica di bot, aggiunta alla raccolta di 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'adattatore elabora e indirizza le attività in ingresso tramite la pipeline del middleware del bot alla logica del bot e quindi esegue di nuovo il backout. 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à.

Usi per il middleware

La domanda viene spesso posta: "Quando è consigliabile 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 prima e dopo l'elaborazione di ogni turno della conversazione. Il middleware consente anche di archiviare e recuperare le informazioni relative alla conversazione e di chiamare la logica di elaborazione aggiuntiva quando necessario. Di seguito sono riportati alcuni scenari comuni che mostrano i casi in cui il middleware può essere utile.

Esaminare o agire in risposta a ogni attività

Ci sono moltissime situazioni che richiedono che il bot esegua un'azione per 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 altrimenti generato 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 di turno

Alcune conversazioni possono essere molto più efficaci se il bot dispone di più informazioni rispetto a quelle fornite nell'attività. In questo caso il middleware può esaminare le informazioni sullo stato della conversazione ottenute finora, eseguire una query su un'origine dati esterna ed eseguire l'accodamento al contesto di turno prima di passare l'esecuzione alla logica del bot.

L'SDK definisce un middleware di registrazione che può registrare le attività in ingresso e in uscita, ma è anche possibile definire un middleware personalizzato.

La pipeline middleware del bot

Per ogni attività l'adapter chiama il middleware nell'ordine in cui è stato aggiunto. L'adapter passa il contesto di ambiente per il turno e un delegato next (successivo) e il middleware chiama il delegato per passare il controllo al middleware successivo nella pipeline. Il middleware ha anche la possibilità di eseguire operazioni dopo che il delegato next (successivo) ritorna prima del completamento del metodo. È come se ogni oggetto middleware avesse la prima e ultima possibilità di agire per quanto riguarda gli oggetti middleware che lo seguono nella pipeline.

Ad esempio:

• Il primo gestore dei turni dell'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 eseguito e restituito.
  • Il secondo gestore dei turni dell'oggetto middleware esegue qualsiasi codice rimanente prima di restituire.
• Il gestore dei turni del primo oggetto middleware esegue qualsiasi codice rimanente prima di restituire.

Se il middleware non chiama il delegato successivo, l'adattatore non chiama alcun middleware o gestore di turni del bot successivo e i corto circuito della pipeline.

Al completamento della pipeline middleware del bot, il turno è finito e il contesto del turno esce dall'ambito.

Il middleware o il bot può generare risposte e registrare gestori di evento di risposta, ma si tenga presente che le risposte vengono gestite in processi separati.

Ordine del middleware

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

Nota

Ciò ha lo scopo di fornire un modello comune che funziona per la maggior parte dei bot, ma è necessario considerare in che modo ogni elemento del middleware interagirà con gli altri per la situazione specifica.

Middleware che si occupa delle attività di livello più basso che devono essere aggiunte prima a ogni bot alla pipeline del middleware. Ne sono esempi la registrazione, la gestione delle eccezioni e la traduzione. Ordinarli in base alle 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 alla pipeline del middleware per ultimo, middleware implementato per eseguire alcune elaborazioni in ogni messaggio inviato al bot. Se il middleware usa informazioni sullo stato o altre informazioni impostate nel contesto del bot, aggiungerlo alla pipeline middleware dopo il middleware che modifica lo stato o il contesto.

Attivazione del corto circuito

Un concetto importante che riguarda il middleware e i gestori di risposta è quello di corto circuito. Se l'esecuzione deve continuare ai livelli successivi, il middleware o un gestore di risposta deve passare l'esecuzione chiamando il relativo delegato next. Se il delegato successivo non viene chiamato all'interno di tale middleware (o gestore di risposta), i corto circuito della pipeline associati e i livelli successivi non vengono eseguiti. Ciò significa che tutta la logica del bot e tutto il middleware che segue nella pipeline vengono ignorati. C'è una sottile differenza tra il middleware e il gestore di risposta che corto circuito un turno.

Quando il middleware corto circuito 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 al completamento.

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

Suggerimento

Se si manda in corto circuito un evento di risposta, ad esempio SendActivities, assicurarsi che sia il comportamento desiderato. In caso contrario, può risultare difficile correggere i bug.

Gestori di evento di risposta

Oltre alla logica di applicazione e middleware, è possibile aggiungere all'oggetto di contesto gestori di risposta, anche detti gestori di eventi o gestori di eventi attività. Questi gestori di evento vengono chiamati quando si verifica la risposta associata nel contesto di ambiente corrente, prima dell'esecuzione della risposta effettiva. Questi gestori sono utili quando si sa di voler fare qualcosa, prima o dopo l'evento effettivo, per ogni attività di quel tipo per il resto della risposta corrente.

Avviso

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

Ogni nuova attività ottiene un nuovo thread per l'esecuzione. Quando viene creato il thread per elaborare l'attività, l'elenco dei gestori per l'attività viene copiato nel nuovo thread. Nessun gestore aggiunto dopo tale punto verrà eseguito per quell'evento attività specifico. I gestori registrati in un oggetto contesto vengono gestiti in modo analogo al modo in cui l'adattatore gestisce la pipeline middleware. Vale a dire, i gestori vengono chiamati nell'ordine in cui sono aggiunti e la chiamata del delegato successivo passa il controllo al gestore di evento registrato successivo. Se un gestore non chiama il delegato successivo, nessuno dei gestori eventi successivi viene chiamato, il corto circuito dell'evento e l'adattatore non invia la risposta al canale.

Gestione dello stato nel middleware

Un metodo comune per salvare lo stato è chiamare il metodo di salvataggio delle modifiche alla fine del gestore dei turni. Ecco un diagramma con lo stato attivo sulla chiamata.

Il problema con questo approccio è che tutti gli aggiornamenti dello stato eseguiti da un middleware personalizzato che si verifica dopo che il gestore dei turni del bot non verrà salvato in una risorsa di archiviazione durevole. La soluzione consiste nello spostare la chiamata al metodo di salvataggio delle modifiche dopo il completamento del middleware personalizzato aggiungendo un'istanza del middleware per il salvataggio automatico delle modifiche all'inizio dello stack del middleware o almeno prima del middleware che potrebbe aggiornare lo stato. L'esecuzione è illustrato di seguito.

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

Risorse aggiuntive

È possibile esaminare il middleware Transcript Logger implementato in Bot Framework SDK [C# | JS].