Richtlinien für das Debuggen

  • Artikel

GILT FÜR: SDK v4

Bots sind komplexe Apps, bei 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 seine eigene bevorzugte Möglichkeit, diese Aufgabe zu erledigen. Die folgenden Richtlinien enthalten 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. Hierzu können Sie Ihren Bot auf einem Stagingserver bereitstellen und Einen eigenen Direktleitungsclient erstellen, mit dem Ihr Bot eine Verbindung herstellen kann. Weitere Informationen finden Sie unter Verbinden eines Bots mit einem Direct Line.

Durch das Erstellen eines eigenen Clients können Sie das innere Funktionieren des Kanals definieren und testen, wie Ihr Bot auf bestimmte Aktivitätsaustausche 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.

Hinweis

Bei der Bereitstellung eines Bots in Azure wird standardmäßig der Webchat Kanal bereitgestellt.

Die Verwendung von Bot Framework Emulator und Webchat über Azure-Portal hier kann weitere Einblicke in die Leistung Ihres Bots bei 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 Botaktivitä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. Die Verwendung des Emulators zeigt Ihnen, was diese Aktivitäten sind, wann sie stattfinden 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" über die Einstellungen für "mynewtestblobstorage" geöffnet. Wählen Sie zum Öffnen einer gespeicherten Benutzereingabe Folgendes aus: Blob Container > ChannelId > TranscriptId > ConversationId

Beispiel für einen Transkripteintrag, der in einem Blobtranskriptspeicher gespeichert ist.

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 Bottranskriptdatei 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 Middlewareelemente verwenden und ihre Pipeline so ausgerichtet ist, kann der Delegat die Ausführung an eine andere Middleware übergeben. Details zur Middleware-Pipeline des Bots können dazu beitragen, diese Idee zu verdeutlichen.

Wenn der next() Delegat 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.

Wenn Sie wissen, wann und warum, können Middleware-Kurzschlüsse angeben, welche Middleware in Ihrer Pipeline an erster Stelle sein sollte. Darüber hinaus ist das Verständnis der Erwartungen für die 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 Prüf-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, was aufgrund der asynchronen Architektur zu verwirrenden Fehlern führen kann.

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.

Wichtig

Die Klasse Cosmos DB-Speicher wurde als veraltet gekennzeichnet. Container, die ursprünglich mit CosmosDbStorage erstellt wurden, hatten keinen Partitionsschlüsselsatz und erhielten den Standardpartitionsschlüssel _/partitionKey.

Mit Cosmos DB-Speicher erstellte Container können mit partitioniertem Cosmos DB-Speicher verwendet werden. Weitere Informationen finden Sie unter Partitionierung in Azure Cosmos DB.

Beachten Sie außerdem, dass der partitionierte Cosmos DB-Speicher im Gegensatz zum älteren Cosmos DB-Speicher nicht automatisch eine Datenbank in Ihrem Cosmos DB-Konto erstellt. Sie müssen eine neue Datenbank manuell erstellen, überspringen aber das manuelle Erstellen eines Containers, da CosmosDbPartitionedStorage den Container für Sie erstellt.

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 Probleme verursachen, wenn der aktuelle Zustand nicht den Erwartungen entspricht.

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 Produktionsbots

Wenn sich Ihr Bot in der Produktion befindet, können Sie Ihren Bot über einen beliebigen Kanal mithilfe von ngrok debuggen. Die nahtlose Verbindung Ihres Bots mit mehreren Kanälen ist ein wichtiges Feature, das in Bot Framework verfügbar ist. Weitere Informationen finden Sie unter Debuggen eines Bots aus einem beliebigen Kanal mithilfe von ngrok und Debuggen eines Skill- oder Skill-Consumers.

Nächste Schritte

Ausführen von Komponententests für Bots

Zusätzliche Ressourcen