Domande frequenti generali su Bot Framework

Alcuni canali non supportano gli aggiornamenti temporanei della digitazione nel client.

La libreria Connector è l'esposizione dell'API REST. La libreria Builder aggiunge il modello di programmazione dei dialoghi discorsivi e altre funzionalità come richieste, cascate, catene e completamento guidato di moduli. La libreria Builder fornisce anche l'accesso ai servizi di intelligenza artificiale di Azure, ad esempio la comprensione del linguaggio naturale.

Quando l'utente invia un messaggio tramite un canale, il servizio Web Bot Framework genera una chiamata HTTPS POST all'endpoint servizio Web del bot. Il bot può restituire zero, uno o molti messaggi all'utente sul canale, generando una chiamata HTTPS POST separata a Bot Framework per ogni messaggio inviato.

Dal punto di vista dei bot, "reattivo" significa che l'utente avvia la conversazione inviando un messaggio al bot e questo reagisce rispondendo al messaggio. Al contrario, "proattivo" significa che il bot avvia la conversazione inviando il primo messaggio all'utente. Ad esempio, un bot può inviare un messaggio proattivo per comunicare a un utente lo scadere di un timer o il verificarsi di un evento.

Per alcuni esempi che mostrano come inviare messaggi proattivi, vedere gli esempi C# V4 e gli esempi Node.js V4 nel repository BotBuilder-Samples in GitHub.

Un ETag è un meccanismo per il controllo della concorrenza ottimistica. L'archiviazione del contenitore dei dati del bot usa ETag per impedire aggiornamenti in conflitto ai dati. Un errore ETag con codice di stato HTTP 412 "Precondizione non riuscita" indica che sono stati ricevuti più messaggi in parallelo prima che il bot potesse terminare la prima operazione. Lo stack di dialoghi e lo stato vengono archiviati in contenitori dei dati del bot. Ad esempio, l'errore di ETag "Precondizione non riuscita" può essere visualizzato se il bot sta ancora elaborando un messaggio precedente quando riceve un nuovo messaggio per la conversazione.

Il servizio Bot Framework deve proteggere se stesso e i suoi clienti da modelli di chiamata offensivi (ad esempio, un attacco Denial of Service), in modo che nessun singolo bot possa influire negativamente sulle prestazioni di altri bot. Per ottenere questo tipo di protezione, sono stati aggiunti limiti di frequenza (noti anche come limitazione delle richieste) agli endpoint. Applicando un limite di frequenza, è possibile limitare la frequenza con cui un client o un bot può effettuare una chiamata specifica. Con la limitazione della frequenza abilitata, se un bot volesse inviare un gran numero di attività dovrebbe distribuirle in un determinato periodo di tempo. Lo scopo della limitazione della frequenza non è limitare il volume totale per un bot. È progettato per prevenire l'abuso dell'infrastruttura di conversazione che non segue i modelli di conversazione umana. Ad esempio, inondare due conversazioni con più contenuti di due esseri umani potrebbero mai consumare.

Microsoft ottimizza costantemente i limiti di frequenza per renderli il più possibile indulgenti, proteggendo al contempo il servizio e gli utenti. Poiché le soglie cambiano di tanto in tanto, i numeri non vengono pubblicati al momento. Infine, se si ospita il bot in un servizio app, il bot è associato alle limitazioni del servizio app. Per altre informazioni, vedere Riepilogo del contratto di servizio per i servizi di Azure Se si è interessati alla limitazione della frequenza, contattare Microsoft all'indirizzo bf-reports@microsoft.com.

Alcuni canali hanno limiti per le dimensioni o il tipo di file che possono essere inviati. Ad esempio, sia Direct Line che Facebook limitano i payload di attività a 262.144 byte, mentre Bot Framework Emulator non ha limiti. Tali limiti vengono imposti dal canale. Se si invia un messaggio che supera questo limite, è possibile che venga visualizzato un errore, ad esempio: La lunghezza del contenuto della richiesta ha superato il limite di 262.144 byte. È tuttavia possibile fornire un collegamento alla risorsa come allegato Internet. Per altre informazioni sull'invio di allegati, vedere come aggiungere elementi multimediali ai messaggi.

È improbabile che si verifichi una limitazione della frequenza, anche in un volume elevato. La maggior parte delle limitazioni della frequenza si verificherà in caso di invii di attività in blocco (da un bot o da un client), test di carico estremi o bug. Quando una richiesta viene limitata, viene restituita una risposta HTTP 429 (Troppe richieste) insieme a un'intestazione Retry-After che indica il tempo di attesa in secondi prima che un nuovo tentativo di richiesta abbia esito positivo. È possibile raccogliere queste informazioni abilitando l'analisi per il bot tramite Azure Application Insights oppure aggiungendo codice nel bot per la registrazione i messaggi.

La limitazione della frequenza è causata da una delle condizioni seguenti:

• Un bot invia messaggi troppo frequentemente
• Un client di un bot invia messaggi troppo frequentemente
• I client Direct Line richiedono un nuovo Web Socket troppo frequentemente

A volte, è necessario trasferire (consegnare) una conversazione da un bot a un essere umano, ad esempio quando il bot non riconosce l'utente o la richiesta non può essere automatizzata. In questi casi, il bot fornisce una transizione agli esseri umani. Bot Framework SDK supporta l'handoff a un essere umano. Esistono alcuni tipi di evento per la segnalazione delle operazioni di handoff. Questi eventi vengono scambiati tra un bot e un hub agente, detto anche hub di engagement. Questo hub agente è definito come un'applicazione o un sistema che consente agli agenti, in genere umani, di ricevere e gestire le richieste da utenti e richieste di escalation dai bot. Per informazioni dettagliate, vedere l'articolo Eseguire la transizione delle conversazioni dal bot all'uomo.