Middleware

GILT FÜR: SDK v4

Middleware ist einfach eine Klasse, die sich während der Initialisierung zwischen dem Adapter und ihrer Botlogik befindet und der Middleware-Sammlung des Adapters hinzugefügt wird. Das SDK ermöglicht Ihnen das Schreiben eigener Middleware sowie das Hinzufügen von Middleware, die von anderen Entwicklern erstellt wurde. Jede ein- oder ausgehende Aktivität für Ihren Bot durchläuft Ihre Middleware.

Der Adapter verarbeitet und leitet eingehende Aktivitäten über die Bot-Middleware-Pipeline an die Logik Ihres Bots weiter und wieder heraus. Während jede Aktivität den Bot durchläuft, kann jede Middleware die Aktivität überprüfen und beeinflussen, sowohl bevor als auch nachdem die Bot-Logik ausgeführt wurde.

Bevor Sie in Middleware springen, ist es wichtig, Bots im Allgemeinen zu verstehen und wie sie Aktivitäten verarbeiten.

Verwendung für Middleware

Die Frage kommt oft auf: "Wann sollte ich Aktionen als Middleware implementieren, anstatt meine normale Bot-Logik zu verwenden?" Middleware bietet Ihnen zusätzliche Möglichkeiten, mit dem Unterhaltungsfluss Ihrer Benutzer sowohl vor als auch nach jeder Wendung der Unterhaltung zu interagieren. Middleware ermöglicht ihnen auch das Speichern und Abrufen von Informationen über die Unterhaltung und das Aufrufen zusätzlicher Verarbeitungslogik bei Bedarf. Nachfolgend finden Sie einige häufige Szenarien, die zeigen, wo Middleware nützlich sein kann.

Jede Aktivität betrachten oder danach handeln

Es gibt viele Situationen, in denen Ihr Bot etwas für jede Aktivität oder für jede Aktivität eines bestimmten Typs ausführen muss. Sie können z. B. jede Nachrichtenaktivität protokollieren, die Ihr Bot empfängt, oder eine Fallbackantwort bereitstellen, wenn der Bot andernfalls keine Antwort generiert hat. Middleware ist ein großartiger Ort für solche Prozesse mit der Fähigkeit, sowohl vor als auch nach der Ausführung der restlichen Bot-Logik zu handeln.

Ändern oder Verbessern des Turnkontexts

Bestimmte Unterhaltungen können viel fruchtbarer sein, wenn der Bot mehr Informationen hat als das, was in der Aktivität bereitgestellt wird. Middleware könnte in diesem Fall die bisher verfügbaren Unterhaltungsstatusinformationen ansehen, eine externe Datenquelle abfragen und diese dem Turnkontextobjekt hinzufügen, bevor die Ausführung an die Botlogik weitergegeben wird.

Das SDK definiert die Protokollierungs-Middleware, die eingehende und ausgehende Aktivitäten aufzeichnen kann, Aber Sie können auch Ihre eigene Middleware definieren.

Die Bot-Middleware-Pipeline

Für jede Aktivität ruft der Adapter Middleware in der Reihenfolge auf, in der Sie sie hinzugefügt haben. Der Adapter übergibt das Kontextobjekt für den Vorgang und einen next Delegaten, und die Middleware ruft den Delegaten auf, um die Kontrolle an die nächste Middleware in der Pipeline weiterzugeben. Middleware hat auch die Möglichkeit, Aktionen auszuführen, nachdem der nächste Delegat zurückkehrt, bevor die Methode abgeschlossen wird. Sie können sich dies vorstellen, da jedes Middleware-Objekt die erste und letzte Chance hat, in Bezug auf die Middleware-Objekte zu handeln, die sie in der Pipeline folgen.

Beispiel:

• Der Turn-Handler des ersten Middleware-Objekts führt Code aus, bevor der nächste Aufruf ausgeführt wird.
  • Der Turnhandler des zweiten Middleware-Objekts führt Code aus, bevor der nächste Aufruf ausgeführt wird.
    • Der Turnhandler des Bots wird ausgeführt und zurückgegeben.
  • Der Turnhandler des zweiten Middleware-Objekts führt den verbleibenden Code aus, bevor er zurückkehrt.
• Der Turn-Handler des ersten Middleware-Objekts führt den verbleibenden Code aus, bevor er zurückgegeben wird.

Wenn die Middleware die nächste Stellvertretung nicht aufruft, ruft der Adapter keine der nachfolgenden Middleware- oder Bot-Turn-Handler auf, und die Pipeline wird abgebrochen.

Sobald die Bot-Middleware-Pipeline abgeschlossen ist, ist der Turn beendet, und der Turn-Kontext fällt aus dem Gültigkeitsbereich.

Middleware oder der Bot können Antworten generieren und Antwortereignishandler registrieren, bedenken Sie jedoch, dass Antworten in separaten Prozessen behandelt werden.

Reihenfolge der Middleware

Da die Reihenfolge, in der Middleware hinzugefügt wird, die Reihenfolge bestimmt, in der die Middleware eine Aktivität verarbeitet, ist es wichtig, die Sequenz zu entscheiden, in der Middleware hinzugefügt werden soll.

Hinweis

Dies soll Ihnen ein gemeinsames Muster geben, das für die meisten Bots funktioniert, aber achten Sie darauf, wie jedes Teil der Middleware für Ihre Situation mit den anderen interagiert.

Middleware, die sich um die Aufgaben der niedrigsten Ebene kümmert, sollte zuerst in die Middleware-Pipeline jedes Bots integriert werden. Beispiele hierfür sind Protokollierung, Ausnahmebehandlung und Übersetzung. Ordnen Sie diese je nach Ihren Anforderungen an, z. B. ob die eingehende Nachricht zuerst übersetzt werden soll, bevor Nachrichten gespeichert werden, oder ob der Nachrichtenspeicher zuerst erfolgen soll, was bedeutet, dass gespeicherte Nachrichten nicht übersetzt werden.

Botspezifische Middleware sollte ihrer Middleware-Pipeline zuletzt hinzugefügt werden, Middleware, die Sie implementieren, um eine Verarbeitung für jede Nachricht auszuführen, die an Ihren Bot gesendet wurde. Wenn Ihre Middleware Zustandsinformationen oder andere Im Bot-Kontext festgelegte Informationen verwendet, fügen Sie sie der Middleware-Pipeline nach der Middleware hinzu, die den Status oder den Kontext ändert.

Kurzschluss

Eine wichtige Idee rund um Middleware- und Reaktionshandler ist das Kurzschließen. Wenn die Ausführung durch die darauf folgenden Ebenen fortgesetzt werden soll, ist Middleware (oder ein Antwort-Handler) erforderlich, um die Ausführung durch das Aufrufen des next-Delegaten weiterzugeben. Wenn der nächste Delegat nicht innerhalb dieser Middleware (oder des Antworthandlers) aufgerufen wird, werden die zugehörigen Pipeline-Kurzschlüsse und nachfolgende Ebenen nicht ausgeführt. Dies bedeutet, dass alle Botlogik und jede Middleware weiter entlang der Pipeline übersprungen wird. Es gibt einen subtilen Unterschied zwischen Ihrer Middleware und dem Abbrechen einer Runde durch Ihren Antworthandler.

Wenn die Middleware einen Durchgang kurzschließt, wird Ihr Bot-TurnHandler nicht aufgerufen, aber der gesamte Middleware-Code, der vor diesem Punkt in der Pipeline ausgeführt wurde, wird weiterhin zur Ausführung gebracht, um den Abschluss zu erreichen.

Bei Ereignishandlern bedeutet das Nichtaufrufen des nächsten Aufrufs, dass das Ereignis abgebrochen wird. Dies unterscheidet sich von der Middleware-Überspringungslogik. Wenn der Rest des Ereignisses nicht verarbeitet wird, sendet der Adapter ihn nie.

Tipp

Wenn Sie ein Antwortereignis kurzschließen, wie z. B. SendActivities, stellen Sie sicher, dass dies das gewünschte Verhalten ist. Andernfalls kann es schwierig sein, Fehler zu beheben.

Antwortereignishandler

Neben der Anwendungs- und Middleware-Logik können dem Kontextobjekt Antworthandler (auch als Ereignishandler oder Aktivitätsereignishandler bezeichnet) hinzugefügt werden. Diese Handler werden aufgerufen, wenn die zugeordnete Antwort für das aktuelle Kontextobjekt erfolgt, bevor die tatsächliche Antwort ausgeführt wird. Diese Verarbeitungsprogramme sind nützlich, wenn Sie wissen, dass Sie etwas tun möchten, entweder vor oder nach dem tatsächlichen Ereignis, für jede Aktivität dieses Typs während des restlichen Verlaufs der aktuellen Antwort.

Warnung

Achten Sie darauf, keine Aktivitätsantwortmethode im jeweiligen Antwortereignishandler aufzurufen, zum Beispiel die Sende-Aktivitätsmethode innerhalb eines On-Send-Aktivitätshandlers. Dadurch kann eine endlose Schleife generiert werden.

Denken Sie daran, dass jede neue Aktivität einen neuen Thread erhält, der ausgeführt werden soll. Wenn der Thread zum Verarbeiten der Aktivität erstellt wird, wird die Liste der Handler für diese Aktivität in den neuen Thread kopiert. Handler, die nach diesem Zeitpunkt hinzugefügt werden, werden für dieses bestimmte Aktivitätsereignis nicht ausgeführt. Die für ein Kontextobjekt registrierten Handler werden ähnlich wie die Verwaltung der Middleware-Pipeline durch den Adapter behandelt. Handler werden nämlich in der Reihenfolge aufgerufen, in der sie hinzugefügt werden, und durch Aufrufen des nächsten Delegaten wird die Steuerung an den nächsten registrierten Ereignishandler übergeben. Wenn ein Handler den nächsten Delegat nicht aufruft, werden keine der nachfolgenden Ereignishandler aufgerufen, und das Ereignis verkürzt sich, sodass der Adapter die Antwort nicht zum Kanal sendet.

Verwaltung von Zuständen in Middleware

Eine gängige Methode zum Speichern des Zustands besteht darin, die Methode zum Speichern von Änderungen am Ende des Turnhandlers aufzurufen. Hier sehen Sie ein Diagramm mit dem Fokus auf dem Anruf.

Das Problem bei diesem Ansatz ist, dass alle Zustandsaktualisierungen, die von einer benutzerdefinierten Middleware vorgenommen werden, nachdem der Bot seinen Turn beendet hat, nicht im dauerhaften Speicher gespeichert werden. Die Lösung besteht darin, den Aufruf an die Methode zum Speichern von Änderungen nach Abschluss der benutzerdefinierten Middleware zu verschieben, indem eine Instanz der Automatisch speichernden Middleware am Anfang des Middleware-Stapels oder zumindest vor einer der Middleware hinzugefügt wird, die den Zustand aktualisieren kann. Die Ausführung wird unten angezeigt.

Fügen Sie die Zustandsverwaltungsobjekte hinzu, die auf ein Bot-Statussatzobjekt aktualisiert werden müssen, und verwenden Sie diese dann, wenn Sie die Middleware zum automatischen Speichern erstellen.

Weitere Ressourcen

Sie können sich die Transkriptprotokoll-Middleware ansehen, wie sie im Bot Framework SDK [C# | JS] implementiert ist.