Freigeben über

Verwalten des Zustands

GILT FÜR: SDK v4

Der Zustand in einem Bot basiert auf den gleichen Paradigmen wie bei modernen Webanwendungen, und über das Bot Framework SDK werden einige Abstraktionen bereitgestellt, um die Verwaltung des Zustands zu vereinfachen.

Wie bei Web-Apps auch, ist ein Bot grundsätzlich zustandslos. Jedes einzelne Segment der Konversation kann auch von einer anderen Instanz Ihres Bots verarbeitet werden. Für einige Bots wird diese Einfachheit bevorzugt – der Bot kann entweder ohne zusätzliche Informationen ausgeführt werden, oder die erforderlichen Informationen sind garantiert innerhalb der eingehenden Nachricht. Für andere ist der Status (z. B. der Ort, an dem die Unterhaltung unterbrochen wurde, oder Daten, die zuvor über den Benutzer empfangen wurden) erforderlich, damit der Bot über eine nützliche Unterhaltung verfügt.

Warum benötige ich einen State?

Durch die Aufrechterhaltung des Zustands kann Ihr Bot aussagekräftigere Unterhaltungen führen, indem er bestimmte Dinge an einen Benutzer oder eine Unterhaltung erinnert. Wenn Sie z. B. zuvor mit einem Benutzer gesprochen haben, können Sie frühere Informationen zu ihnen speichern, damit Sie sie nicht erneut fragen müssen. Der Zustand speichert auch Daten länger als den aktuellen Dialogschritt, sodass Ihr Bot Informationen im Verlauf von Gesprächen mit mehreren Dialogschritten speichert.

Da es sich um Bots handelt, gibt es einige Ebenen für die Verwendung des Zustands: die Speicherschicht, die Statusverwaltung (im Bot-Zustand im folgenden Diagramm enthalten) und Statuseigenschaften-Accessoren. Dieses Diagramm veranschaulicht Teile der Interaktionssequenz zwischen diesen Ebenen mit den durchgezogenen Pfeilen, die einen Methodenaufruf darstellen, und die gestrichelten Pfeile, die die Antwort darstellen (mit oder ohne Rückgabewert).

Sequenzdiagramm, das zeigt, wie der Systemzustand bei jeder Runde geladen, zwischengespeichert und gespeichert wird.

Der Fluss dieses Diagramms wird in den folgenden Abschnitten mit Details zu den einzelnen Ebenen erläutert.

Speicherebene

Ausgangspunkt ist das Back-End, in dem die Zustandsinformationen tatsächlich gespeichert werden, nämlich die Speicherebene. Dies kann als Ihr physischer Speicher betrachtet werden, z. B. In-Memory, Azure oder ein Drittanbieterserver.

Das Bot Framework SDK enthält einige Implementierungen für die Speicherschicht:

  • Speicher implementiert speicherinternen Speicher zu Testzwecken. In-Memory-Datenspeicher ist nur für lokale Tests vorgesehen, da dieser Speicher veränderlich und temporär ist. Die Daten werden jedes Mal gelöscht, wenn der Bot neu gestartet wird.
  • Azure Blob Storage stellt eine Verbindung mit einer Azure Blob Storage-Objektdatenbank bereit.
  • Azure Cosmos DB partitionierter Speicher verbindet sich mit einer partitionierten Cosmos DB NoSQL-Datenbank.

Von Bedeutung

Die Klasse Cosmos DB-Speicher wurde als veraltet gekennzeichnet. Container, die ursprünglich mit CosmosDbStorage erstellt wurden, hatten keinen Partitionsschlüssel 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, aber überspringen Sie die manuelle Erstellung eines Containers, da CosmosDbPartitionedStorage den Container für Sie erstellt.

Anweisungen zum Herstellen einer Verbindung mit anderen Speicheroptionen finden Sie unter direkt in den Speicher schreiben.

Zustandsverwaltung

Die Zustandsverwaltung automatisiert das Lesen und Schreiben des Zustands Ihres Bots auf die zugrunde liegende Speicherebene. Status wird als Zustandseigenschaften gespeichert, die effektiv Schlüsselwertpaare sind, die Ihr Bot lesen und schreiben kann, ohne sich gedanken über die spezifische zugrunde liegende Implementierung zu machen. Diese Statuseigenschaften definieren, wie diese Informationen gespeichert werden. Wenn Sie beispielsweise eine Eigenschaft abrufen, die Sie als eine bestimmte Klasse oder ein bestimmtes Objekt definiert haben, wissen Sie, wie diese Daten strukturiert werden.

Diese Zustandseigenschaften werden in bereichsbezogene "Buckets" zusammengefasst, die nur Sammlungen sind, um diese Eigenschaften zu organisieren. Das SDK enthält drei der folgenden "Buckets":

  • Benutzerstatus
  • Konversationsstatus
  • Zustand der privaten Unterhaltung

Alle diese Buckets sind Unterklassen der Bot-Zustandsklasse, die verwendet werden kann, um andere Buckettypen mit unterschiedlichen Anwendungsbereichen zu definieren.

Diese vordefinierten Buckets sind abhängig vom Bucket-Typ auf eine spezifische Sichtbarkeit beschränkt.

  • Der Benutzerstatus ist in jedem Gesprächsabschnitt verfügbar, während der Bot mit diesem Benutzer auf diesem Kanal spricht, unabhängig von der Gesprächsqualität.
  • Der Gesprächsstatus ist in jeder einzelnen Gesprächsrunde einer spezifischen Unterhaltung verfügbar, unabhängig vom Benutzer, z. B. in Gruppengesprächen.
  • Der Status der privaten Unterhaltung bezieht sich sowohl auf die spezifische Unterhaltung als auch auf den spezifischen Benutzer.

Tipp

Sowohl der Benutzer- als auch der Unterhaltungsstatus sind nach Kanal festgelegt. Dieselbe Person, die unterschiedliche Kanäle verwendet, um auf Ihren Bot zuzugreifen, wird als unterschiedliche Benutzer, eine für jeden Kanal und jeweils mit einem unterschiedlichen Benutzerstatus angezeigt.

Die Schlüssel, die für jeden dieser vordefinierten Buckets verwendet werden, sind entweder benutzer- oder/und konversationsspezifisch, oder beides. Beim Festlegen des Werts Ihrer Statuseigenschaft wird der Schlüssel intern definiert, mit Informationen, die im Turnkontext enthalten sind, um sicherzustellen, dass jeder Benutzer oder jede Unterhaltung im richtigen Bucket und in der richtigen Eigenschaft platziert wird. Insbesondere werden die Schlüssel wie folgt definiert:

  • Der Benutzerstatus erstellt einen Schlüssel mithilfe der Kanal-ID und aus der ID. Beispiel: {Activity.ChannelId}/users/{Activity.From.Id}#YourPropertyName
  • Der Konversationsstatus erstellt einen Schlüssel mithilfe der Kanal-ID und der Gesprächs-ID. Beispiel: {Activity.ChannelId}/conversations/{Activity.Conversation.Id}#YourPropertyName
  • Der Status der privaten Unterhaltung erstellt einen Schlüssel mithilfe der Kanal-ID, der from ID und der Konversations-ID. Beispiel: {Activity.ChannelId}/conversations/{Activity.Conversation.Id}/users/{Activity.From.Id}#YourPropertyName

Wann jeder Zustandstyp verwendet werden soll

Der Gesprächsstatus ist gut geeignet, um den Kontext des Gesprächs nachzuverfolgen, z. B.:

  • Ob der Bot dem Benutzer eine Frage gestellt hat und welche Frage das war
  • Was das aktuelle Thema der Unterhaltung ist oder was das letzte war

Der Benutzerstatus eignet sich gut zum Nachverfolgen von Informationen über den Benutzer, z. B.:

  • Nicht kritische Benutzerinformationen, z. B. Name und Einstellungen, Alarmeinstellungen oder Warnungseinstellungen
  • Informationen über die letzte Unterhaltung, die sie mit dem Bot hatten
    • Beispielsweise kann ein Produktsupport-Bot nachverfolgen, welche Produkte der Benutzer gefragt hat.

Der Status privater Unterhaltungen eignet sich gut für Kanäle, die Gruppenunterhaltungen unterstützen, aber wo Sie sowohl benutzer- als auch unterhaltungsspezifische Informationen nachverfolgen möchten. Beispiel: Wenn man einen Klicker-Bot für den Klassenraum hätte:

  • Der Bot könnte Schülerantworten für eine bestimmte Frage aggregieren und anzeigen.
  • Der Bot könnte die Leistung jedes Schülers aggregieren und diese am Ende der Sitzung privat an sie weiterleiten.

Ausführliche Informationen zur Verwendung dieser vordefinierten Buckets finden Sie im Artikel zur Vorgehensweise.

Herstellen einer Verbindung mit mehreren Datenbanken

Wenn Ihr Bot eine Verbindung mit mehreren Datenbanken herstellen muss, erstellen Sie für jede Datenbank eine Speicherebene. Sie können mehrere Datenbanken verwenden, wenn Ihr Bot Informationen sammelt, die unterschiedliche Sicherheits-, Parallelitäts- oder Datenspeicherortanforderungen aufweisen.

Erstellen Sie für jede Speicherebene die Zustandsverwaltungsobjekte, die Sie benötigen, um Ihre Statuseigenschaften zu unterstützen.

Zugriffsmethoden für Zustandseigenschaften

Zustandseigenschaftsaccessoren werden verwendet, um tatsächlich eine Ihrer Zustandseigenschaften zu lesen oder zu schreiben, und sie bieten get-, set- und delete-Methoden für den Zugriff auf Ihre Zustandseigenschaften innerhalb eines Turnus. Um einen Accessor zu erstellen, müssen Sie den Eigenschaftsnamen angeben, was normalerweise bei der Initialisierung des Bots erfolgt. Anschließend können Sie diesen Accessor verwenden, um diese Eigenschaft des Status Ihres Bots abzurufen und zu bearbeiten.

Die Accessoren ermöglichen es dem SDK, den Zustand aus dem zugrunde liegenden Speicher abzurufen und den Statuscache des Bots für Sie zu aktualisieren. Der Statuscache ist ein lokaler Cache, der von Ihrem Bot verwaltet wird, der das Statusobjekt für Sie speichert und Lese- und Schreibvorgänge ermöglicht, ohne auf den zugrunde liegenden Speicher zuzugreifen. Wenn sie noch nicht im Cache vorhanden ist, ruft der Aufruf der Get-Methode des Accessors den Zustand ab und platziert sie auch im Cache. Nach dem Abrufen kann die Zustandseigenschaft wie eine lokale Variable bearbeitet werden.

Die Löschmethode des Accessors entfernt die Eigenschaft aus dem Cache und löscht sie auch aus dem zugrunde liegenden Speicher.

Von Bedeutung

Für den ersten Aufruf der Get-Methode eines Accessors müssen Sie eine Factory-Methode angeben, um das Objekt zu erstellen, wenn es noch nicht in Ihrem Status vorhanden ist. Wenn keine Factory-Methode angegeben wird, erhalten Sie eine Ausnahme. Details zur Verwendung einer Factorymethode finden Sie im Artikel zur Vorgehensweise.

Um alle Änderungen beizubehalten, die Sie an der Zustandseigenschaft vornehmen, die Sie vom Accessor abrufen, muss die Eigenschaft im Statuscache aktualisiert werden. Sie können dies über einen Aufruf der Accessor set-Methode tun, die den Wert Ihrer Eigenschaft im Cache festlegt und verfügbar ist, falls dieser später in diesem Schritt gelesen oder aktualisiert werden muss. Um diese Daten tatsächlich im zugrunde liegenden Speicher zu speichern (und sie somit nach dem aktuellen Ablauf verfügbar zu machen), müssen Sie dann ihren Zustand speichern.

Funktionsweise der Accessormethoden für Zustandseigenschaften

Die Accessormethoden sind die primäre Möglichkeit, mit der Ihr Bot mit dem Status interagieren kann. Wie die einzelnen Arbeiten funktionieren und wie die zugrunde liegenden Ebenen interagieren, sind wie folgt:

  • Die get-Methode des Accessors:
    • Accessor ruft die Eigenschaft aus dem Zustandscache ab.
    • Wenn sich die Eigenschaft im Cache befindet, gib sie zurück. Andernfalls rufen Sie es aus dem Statusverwaltungsobjekt ab. (Wenn sich das Objekt noch nicht im Zustand befindet, verwenden Sie die Factory-Methode, die im get-Aufruf der Accessoren bereitgestellt wird.)
  • Set-Methode des Accessors:
    • Aktualisieren Sie den Statuscache mit dem neuen Eigenschaftswert.
  • Die Speicheränderungsmethode des Zustandsverwaltungsobjekts:
    • Überprüfen Sie die Änderungen der Eigenschaften im Zustandscache.
    • Schreiben Sie diese Eigenschaft in den Speicher.

Status in Dialogfeldern

Die Dialogbibliothek verwendet einen Dialogstatus-Eigenschaftszugriff, der im Konversationszustand des Bots definiert ist, um die Position eines Dialogs im Gesprächsverlauf beizubehalten. Die Eigenschaft "Dialogstatus" ermöglicht es jedem Dialogfeld auch, vorübergehende Informationen zwischen den Dialogphasen zu speichern.

Adaptive Dialogfelder verfügen über eine aufwändigere Speicherbereichsstruktur, wodurch der Zugriff auf Konfigurations- und Erkennungsergebnisse unter anderem erleichtert wird. Der Dialog-Manager verwendet die Verwaltungsobjekte für den Benutzer- und Gesprächszustand, um diese Speicherbereiche bereitzustellen.

Informationen zur Dialogbibliothek finden Sie im Artikel zur Dialogbibliothek .

Speichern des Zustands

Wenn Sie die set-Methode des Accessors aufrufen, um den aktualisierten Zustand aufzuzeichnen, wurde diese Zustandseigenschaft noch nicht im permanenten Speicher gespeichert und stattdessen nur im Statuscache Ihres Bots gespeichert. Um alle Änderungen im Zustandscache im permanenten Zustand zu speichern, müssen Sie die Speicheränderungsmethode des Zustandsverwaltungsobjekts aufrufen, die für die Implementierung der oben genannten Botstatusklasse (z. B. Benutzerstatus oder Unterhaltungszustand) verfügbar ist.

Durch Aufrufen der Methode zum Speichern von Änderungen für ein Statusverwaltungsobjekt (z. B. die oben erwähnten Buckets) werden alle Eigenschaften im Statuscache gespeichert, die Sie an diesem Punkt für diesen Bucket eingerichtet haben, aber nicht für einen der anderen Buckets, die Sie möglicherweise im Status Ihres Bots haben.

Tipp

Der Bot-Zustand implementiert ein Verhalten vom Typ "Last write wins", wobei der letzte Schreibvorgang den zuvor geschriebenen Zustand überstempelt. Dies kann für viele Anwendungen funktionieren, hat jedoch Auswirkungen, insbesondere in skalierten Szenarien, in denen möglicherweise eine gewisse Parallelität oder Latenz auftritt.

Wenn Sie über eine benutzerdefinierte Middleware verfügen, die den Zustand nach Abschluss des Turnhandlers möglicherweise aktualisiert, sollten Sie den Behandlungszustand in Middleware in Betracht ziehen.

Weitere Ressourcen