Richtlinien für das Debuggen

GILT FÜR: SDK v4

Bots sind komplexe Apps, in denen viele Teile zusammenarbeiten. Wie bei jeder komplexen App kann dies zu einigen interessanten Fehlern führen oder bei Ihrem Bot ein anderes Verhalten als das erwartete verursachen.

Das Debuggen Ihres Bots kann eine schwierige Aufgabe sein. Jeder Entwickler hat eine eigene bevorzugte Methode, um diese Aufgabe zu erledigen. Die folgenden Richtlinien sind Vorschläge, die für die meisten Bots gelten.

Nachdem Sie überprüft haben, ob Ihr Bot funktioniert, besteht der nächste Schritt darin, ihn mit einem Kanal zu verbinden. Dazu können Sie Ihren Bot auf einem Stagingserver bereitstellen und einen eigenen Direktleitungsclient für Ihren Bot erstellen, mit dem eine Verbindung hergestellt werden kann. Weitere Informationen finden Sie unter Verbinden eines Bots mit einer Direct Line.

Durch die Erstellung Ihres eigenen Clients können Sie die inneren Funktionsweisen des Kanals definieren und testen, wie Ihr Bot auf bestimmte Aktivitätsbörsen reagiert. Sobald die Verbindung mit Ihrem Client besteht, führen Sie die Tests aus, um den Botzustand einzurichten und Ihre Features zu überprüfen. Wenn Ihr Bot ein Feature wie Spracherkennung nutzt, können Sie diese Funktionalität mithilfe dieser Kanäle überprüfen.

Die Verwendung des Bot-Framework-Emulators und Webchat über Azure-Portal können hier weitere Einblicke in die Leistung Ihres Bots während der Interaktion mit verschiedenen Kanälen bieten.

Das Debuggen des Bots funktioniert ähnlich wie bei anderen Apps mit mehreren Threads: Sie können Haltepunkte festlegen oder Features wie das Direktfenster verwenden.

Bots folgen einem ereignisgesteuerten Programmierparadigma, das möglicherweise schwierig zu rationalisieren ist, wenn Sie nicht mit ihm vertraut sind. Die Idee, dass der Bot zustandslos ist, mehrere Threads aufweist und asynchrone oder Warte-Aufrufe behandeln muss, kann zu unerwarteten Fehlern führen. Auch wenn das Debuggen Ihres Bots ähnlich wie bei anderen Apps mit mehreren Threads funktioniert, finden Sie hier einige Vorschläge, Tools und Ressourcen zur Hilfestellung.

Grundlegendes zu Bot-Aktivitäten mit dem Emulator

Der Bot behandelt unterschiedliche Typen von Aktivitäten neben der normalen Nachrichtenaktivität. Ein Verständnis dieser Aktivitäten hilft Ihnen dabei, Ihren Bot effizienter zu schreiben, und ermöglicht Ihnen, zu überprüfen, ob die gesendeten und empfangenen Aktivitäten des Bots Ihren Erwartungen entsprechen. Wenn Sie den Emulator verwenden, zeigen Sie, was diese Aktivitäten sind, wann sie geschehen, und welche Informationen sie enthalten. Weitere Informationen finden Sie unter Debuggen mit dem Emulator.

Speichern und Abrufen von Benutzerinteraktionen mit Transkripts

Über Azure-Blob-Transkriptspeicher wird eine spezielle Ressource bereitgestellt, mit der Sie Transkripts, die Interaktionen zwischen Ihren Benutzern und Ihrem Bot enthalten, speichern und abrufen können.

Außerdem können Sie nach dem Speichern der Benutzereingabeinteraktionen den „Speicher-Explorer“ von Azure verwenden, um Daten, die in den Transkripts im Blob-Transkriptspeicher enthalten sind, manuell anzuzeigen. Im folgenden Beispiel wird "Speicher-Explorer" aus den Einstellungen für "mynewtestblobstorage" geöffnet. So öffnen Sie eine gespeicherte Benutzereingabe: Blob Container > ChannelId > TranscriptId > ConversationId

Die gespeicherte Benutzereingabe der Konversation wird im JSON-Format geöffnet. Die Benutzereingabe wird zusammen mit dem Schlüssel "text:" beibehalten. Weitere Informationen zum Erstellen und Verwenden einer Bot-Transkriptdatei finden Sie unter Debuggen Ihres Bots mithilfe von Transkriptdateien.

Funktionsweise von Middleware

Middleware ist bei der ersten Verwendung möglicherweise nicht intuitiv, insbesondere beim Fortsetzen oder Kurzschließen der Ausführung. Middleware kann zu Beginn oder zum Ende eines Durchlaufs ausgeführt werden. Dabei legt der Aufruf des Delegats next() fest, wann die Ausführung an die Logik des Bots übergeben wird.

Wenn Sie mehrere Middleware-Teile verwenden und wie Ihre Pipeline ausgerichtet ist, kann die Stellvertretung die Ausführung an eine andere Middleware übergeben. Details zur Middleware-Pipeline des Bots können dazu beitragen, diese Idee zu verdeutlichen.

Wenn die next() Stellvertretung nicht aufgerufen wird, wird dies als Kurzschlussrouting bezeichnet. Dies geschieht, wenn die Middleware die aktuelle Aktivität erfüllt und festlegt, dass es nicht erforderlich ist, die Ausführung zu übergeben.

Verstehen, wann und warum Middleware Short-Circuits helfen können, anzugeben, welches Teil von Middleware zuerst in Ihrer Pipeline sein soll. Darüber hinaus ist das Verständnis, was sie erwarten müssen, für integrierte Middleware wichtig, die vom SDK oder anderen Entwicklern bereitgestellt wird. Es kann hilfreich sein, zuerst eigene Middleware zu erstellen, um vor dem Einstieg in die integrierte Middleware ein wenig zu experimentieren.

Weitere Informationen zum Debuggen eines Bots mithilfe von Inspektions-Middleware finden Sie unter Debuggen eines Bots mit Inspektions-Middleware.

Grundlegendes zum Zustand

Die Überwachung des Zustands ist ein wichtiger Bestandteil Ihres Bots, insbesondere für komplexe Aufgaben. Im Allgemeinen hat es sich bewährt, Aktivitäten möglichst schnell zu verarbeiten und die Verarbeitung abzuschließen, sodass der Zustand beibehalten wird. Aktivitäten können fast gleichzeitig an Ihren Bot gesendet werden und können aufgrund der asynchronen Architektur verwirrende Fehler bewirken.

Stellen Sie vor allem sicher, dass der Status ihren Erwartungen entsprechend beibehalten wird. Abhängig davon, wo sich Ihr persistenter Zustand befindet, können Sie ihn mithilfe von Speicheremulatoren für Cosmos DB und Azure Table Storage überprüfen, bevor Sie Produktionsspeicher verwenden.

Verwenden von Aktivitätshandlern

Aktivitätshandler können eine weitere Ebene der Komplexität einführen, in erster Linie dadurch, dass jede Aktivität in einem unabhängigen Thread (oder abhängig von Ihrer Sprache in Webworkern) ausgeführt wird. Je nachdem, was Ihre Handler tun, kann dies Zu Problemen führen, bei denen der aktuelle Zustand nicht das ist, was Sie erwarten.

Der integrierte Zustand wird am Ende eines Durchlaufs geschrieben, während dieses Durchlaufs generierte Aktivitäten werden jedoch unabhängig von der Durchlaufpipeline ausgeführt. Häufig hat dies keine Auswirkung, aber wenn ein Aktivitätshandler den Zustand ändert, muss der Zustand geschrieben werden, damit er diese Änderung enthält. In diesem Fall kann die Durchlaufpipeline vor dem Abschluss warten, bis die Aktivität abgeschlossen ist, um sicherzustellen, dass für diesen Durchlauf der richtige Zustand aufgezeichnet wird.

Die Methode send activity und ihre Handler stellen ein besonderes Problem dar. Der einfache Aufruf von send activity innerhalb des Handlers on send activities bewirkt eine unendliche Aufspaltung von Threads. Sie können dieses Problem auf verschiedene Weise umgehen, z. B. durch Anfügen zusätzlicher Meldungen an die ausgehenden Informationen oder durch das Schreiben an einen anderen Speicherort wie die Konsole oder eine Datei, um einen Absturz Ihres Bots zu vermeiden.

Debuggen eines Produktions-Bots

Wenn Sich Ihr Bot in der Produktion befindet, können Sie Ihren Bot über einen beliebigen Kanal mithilfe von Dev Tunnels debuggen. Die nahtlose Verbindung Ihres Bots mit mehreren Kanälen ist ein wichtiges Feature, das in Bot Framework zur Verfügung steht. Weitere Informationen finden Sie unter Debuggen eines Bots aus einem beliebigen Kanal mithilfe von Devtunnel und Debuggen eines Qualifikations- oder Qualifikationsanwenders.

Nächste Schritte

Zusätzliche Ressourcen

• Debuggen in Visual Studio
• Debugging, Ablaufverfolgung und Profilerstellung für Bot Framework
• Verwenden von ConditionalAttribute für Methoden, die nicht im Produktionscode enthalten sein sollen
• Verwenden von Tools wie Fiddler zum Einsehen des Netzwerkverkehrs
• Behandeln allgemeiner Probleme und die anderen Artikel zur Problembehandlung in diesem Abschnitt