Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Zustands-Handler

State-Handler, auch einfach als Handler bezeichnet, dienen zur Steuerung der Unterhaltung. Dazu werden Antworten für Endnutzer und/oder Antworten erstellt. durch Umsetzen der aktuellen Seite. Für jede Unterhaltungsrunde werden Handler ausgewertet. Dies kann sich auf die Sitzung auswirken. Handler haben drei allgemeine Datentypen:

Begriff Definition
Handler-Anforderungen Dies sind die Anforderungen, die erfüllt sein müssen, damit sich der Handler auf die Sitzung auswirkt. Ein Handler gilt als aufgerufen, wenn er seine Anforderungen erfüllt und die Sitzung in irgendeiner Weise beeinflusst.
Handler-Auftragsausführung Wenn ein Handler aufgerufen wird, werden mit einer optionalen Auftragsausführung Antworten für Endnutzer erstellt. Diese Antworten sind entweder in statischen Agent-Daten definiert oder werden dynamisch aus Ihrem Webhook-Dienst abgerufen.
Handler-Umstellungsziel Nach dem Aufruf eines Handlers wird ein optionales Umstellungsziel verwendet, um die aktuelle Seite zu ändern. Die nächste Seite kann nur eine Ablauf-Startseite oder eine Seite im aktuell aktiven Ablauf sein.

Es gibt zwei Arten von Zustands-Handlern mit unterschiedlichen Handler-Anforderungen:

Begriff Definition
Routen Routen werden aufgerufen, wenn eine Endnutzereingabe mit einem Intent übereinstimmt und/oder eine Bedingung für den Sitzungsstatus erfüllt ist. Eine Route mit einer Intent-Anforderung wird auch als Intent-Route bezeichnet. Eine Route mit lediglich einer Bedingungsanforderung wird auch als Bedingungsroute bezeichnet.
Event-Handler Ereignis-Handler werden aufgerufen, wenn ein Ereignis eintritt. Einige integrierte Ereignisse werden ausgelöst, wenn unerwartete Endnutzereingaben empfangen werden oder wenn ein Webhook-Fehler auftritt. Sie können auch benutzerdefinierte Ereignisse definieren, die aufgerufen werden, wenn etwas außerhalb der Unterhaltung stattfindet.

Die Verarbeitung eines Zustands-Handlers umfasst drei Schritte:

Begriff Definition
1. Umfang Ein Handler muss sich im Bereich befinden, um Auswirkungen auf die Sitzung zu haben. Der Bereich wird dadurch bestimmt, ob ein Handler auf einen Ablauf, eine Seite oder einen Formularparameter angewendet wird und ob der verknüpfte Ablauf aktiv ist, die zugehörige Seite aktiv ist oder der Agent versucht, den zugehörigen Formularparameter auszufüllen.
2. Kennenlernen Jeder Handler im Bereich wird der Reihe nach ausgewertet. Wenn die Anforderungen eines Handlers erfüllt sind, gilt die Bewertung als bestanden.
3. Aufruf Wenn ein Handler im Bereich liegt und die Bewertung besteht, wird er aufgerufen. Zugehörige Auftragsausführungen werden aufgerufen und zugehörige Umstellungsziele werden auf die Sitzung angewendet.

Bereich

Damit ein Handler ausgewertet werden kann, muss er im Gültigkeitsbereich liegen. Der Handler-Bereich ist ein wichtiges und leistungsstarkes Tool zur Steuerung von Unterhaltungen. Über den Bereich eines Handlers können Sie Folgendes steuern:

X Posten
Wann ein Intent zugeordnet werden kann
Wann eine Bedingung geprüft werden soll
Wann ein bestimmtes Ereignis verarbeitet werden kann
Wann ein Seitenwechsel stattfinden kann
Wann eine statische Auftransausführungsantwort bereitgestellt wird
Wann eine für den Webhook aktivierte Auftragsausführung für dynamische Antworten aufgerufen wird

Der Bereich wird dadurch bestimmt, ob ein Handler auf einen Ablauf, eine Seite oder einen Formularparameter angewendet wird und ob der verknüpfte Ablauf aktiv ist, die zugehörige Seite aktiv ist oder der Agent versucht, den zugehörigen Formularparameter auszufüllen.

Dies sind die detaillierten Bereichsregeln:

  • Auf den aktiven Ablauf angewendete Routen:
    • Wenn die aktuelle Seite die Ablaufstartseite ist, liegen sie im Bereich.
    • Wenn die aktuelle Seite nicht die Seite des Ablaufs ist, liegen sie nur im Bereich, wenn sie eine Intent-Anforderung haben.
  • Auf die aktuelle Seite angewendete Routen liegen im Bereich.
  • Event-Handler, die den aktiven Ablauf angewendet haben, liegen im Bereich.
  • Event-Handler, die auf die aktuelle Seite angewendet werden, liegen im Bereich.
  • Event-Handler, die auf einen Formularparameter angewendet werden, den der Agent derzeit auszufüllen versucht, liegen im Bereich.

Routen

Für Routen gelten zwei Anforderungen, von denen eine oder beide angegeben werden müssen. Wenn beide Anforderungen angegeben sind, müssen beide erfüllt sein, damit die Route aufgerufen wird:

Begriff Definition
Intent-Anforderung Ein Intent, der mit der Endnutzereingabe für die aktuelle Unterhaltungsrunde übereinstimmen muss. Wenn eine Route eine Intent-Anforderung hat, wird sie als Intent-Route bezeichnet.
Erforderliche Bedingung Eine Bedingung, die erfüllt sein muss. Wenn eine Route eine Bedingungsanforderung hat, wird sie als Bedingungsroute bezeichnet.

Sie können Routen auf Abläufe (Routen auf Ablaufebene) und Seiten (Routen auf Seitenebene) anwenden. Beispiel: Sie können Routen in folgenden Situationen verwenden:

X Posten
Wenn eine Endnutzereingabe einem Intent zugeordnet wird, sollte über die Übereinstimmung eine statische Auftragsausführungsantwort ausgelöst werden.
Wenn die Endnutzereingabe mit einem Intent übereinstimmt, sollte die Übereinstimmung eine Webhook-fähige Auftragsausführung für eine dynamische Antwort auslösen.
Wenn eine Endnutzereingabe den endgültigen erforderlichen Formularparameter bereitgestellt hat, löst eine Bedingungsprüfung einen Sitzungswechsel zu einer anderen Seite aus.
Wenn eine Endnutzereingabe einen bestimmten Formularparameter bereitgestellt haben, löst eine Bedingungsprüfung die Antwort der statischen Auftragsausführung aus.
Eine Bedingungsprüfung, die auf true gesetzt ist, wodurch ein Seitenübergang erzwungen wird.

Intent-Übernahme

Wenn eine Route aufgrund eines übereinstimmenden Intents aufgerufen wird, wird der Intent normalerweise verbraucht. Ein verbrauchter Intent kann nur dann wieder zugeordnet werden, wenn eine neue Endnutzereingabe eine neue Intent-Übereinstimmung auslöst. Im folgenden Szenario ist es möglich, eine Intent-Übereinstimmung von einem Ablauf an einen anderen weiterzugeben:

  • Eine Route in flow F1 hat intent I1 als Anforderung und flow F2 als Umstellungsziel.
  • Flow F2 hat eine Route, die auch intent I1 als Anforderung enthält.

Wenn in diesem Fall die Route in flow F1 aufgerufen wird, wird intent I1 zweimal einer einzelnen Endnutzereingabe zugeordnet und beide Routen werden aufgerufen.

Die Übernahme von Intents ist nützlich für folgende Situationen:

X Posten
Ändern Sie die aktuelle Seite in eine bestimmte Seite in einem anderen Ablauf (die Route des Umstellungszielablaufs hat eine bestimmte Umstellungszielseite).
Erstellen Sie eine Eintragsnachricht für die Startseite eines Ablaufs (die Route des Umstellungszielablaufs hat eine Auftragsausführung).

Route-Gruppen

Bei der Erstellung eines Agents kann es vorkommen, dass für viele Seiten ein gemeinsamer Satz von Routen festgelegt werden muss. Um Routen wiederverwendbar zu machen, können Sie Routengruppen definieren. Diese Gruppen sind dann eine Ressource für den gesamten Ablauf.

Beispielsweise können Sie in Ihrem Ablauf Endnutzereingaben verarbeiten, z. B. "Ich möchte meiner Pizza ein Topping hinzufügen" oder "Ich möchte die Größe meines Getränks ändern". Diese Eingaben sollten verarbeitet werden, wenn eine der Seiten des Ablaufs aktiv ist. Sie können zwei Routen mit Intents definieren, um diese Eingaben für alle relevanten Seiten zu verarbeiten, aber das ist viel doppelte Arbeit. Stattdessen können Sie die Route-Gruppen einmal definieren und auf allen relevanten Seiten einen Verweis zur Gruppe hinzufügen.

Routen auf Ablaufebene

Routen auf Ablaufebene sind Routen, die auf einen Ablauf angewendet werden. Diese Arten von Handlern haben folgende Anwendungsfälle:

X Posten
Handler mit einer Intent- oder Bedingungsanforderung für die Ablaufstartseite.
Handler mit einer Intent-Anforderung für den Bereich aller Seiten innerhalb des Ablaufs.

Routen auf Seitenebene

Routen auf Seitenebene sind Routen, die auf eine Seite angewendet werden. Diese Arten von Handlern haben folgende Anwendungsfälle:

X Posten
Handler mit einer Intent- oder Bedingungsanforderung im Bereich, wenn bestimmte Seiten aktiv sind.

Event-Handler

Event-Handler benötigen eine einzige Voraussetzung, um aufgerufen zu werden:

Begriff Definition
Ereignisanforderung Ein Ereignis, das aufgerufen werden muss. Ereignisse werden anhand ihres Namens identifiziert. Einige integrierte Ereignisse werden aufgerufen, wenn unerwartete Eingaben von Endnutzern empfangen werden oder wenn ein Webhook-Fehler auftritt. Sie haben auch die Möglichkeit, benutzerdefinierte Ereignisse zu definieren, die aufgerufen werden, wenn etwas außerhalb der Unterhaltung stattfindet.

Sie können Event-Handler auf Abläufe (Event-Handler auf Ablaufebene), Seiten (Event-Handler auf Seitenebene) und Parameter (Event-Handler auf Parameterebene) anwenden. Beispielsweise können Sie in folgenden Situationen Event-Handler verwenden:

X Posten
Wenn keine Endnutzereingabe mit Intents übereinstimmt, stellt der Event-Handler no-match eine bestimmte statische Auftragsausführungsantwort bereit.
Ein Timer läuft in Ihrem System ab und Sie möchten Erinnerungsinformationen an den Endnutzer mit einer bestimmten statischen Auftragsausführungsantwort senden.

Event-Handler auf Ablaufebene

Event-Handler auf Ablaufebene sind Event-Handler, die auf einen Ablauf angewendet werden. Diese Arten von Handlern haben folgende Anwendungsfälle:

X Posten
Handler mit einer Ereignisanforderung für die Ablaufstartseite.
Handler mit einer Ereignisanforderung im Bereich für alle Seiten innerhalb des Ablaufs.
Transitions mit unerwarteten Endnutzereingaben, die von allen Seiten in einem Ablauf gemeinsam genutzt werden.
Transitions mit Webhook-Fehlern, die von allen Seiten in einem Ablauf gemeinsam genutzt werden.
Verarbeitung von benutzerdefinierten Ereignissen, die von Ihrem System aufgerufen und von allen Seiten in einem Ablauf gemeinsam genutzt werden.

Jeder Ablauf hat Event-Handler für die eingebundenen Ereignisse no-match und no-input. Diese Event-Handler werden beim Erstellen eines Ablaufs automatisch erstellt und können nicht gelöscht werden.

Event-Handler auf Seitenebene

Event-Handler auf Seitenebene sind Event-Handler, die auf eine Seite angewendet werden. Diese Arten von Handlern haben folgende Anwendungsfälle:

X Posten
Handler mit einer Ereignisanforderung, wenn bestimmte Seiten aktiv sind.
Verarbeitung von unerwarteten Endnutzereingaben, die für eine Seite spezifisch sind.
Verarbeitung von Webhook-Fehlern, die für eine Seite spezifisch sind.
Verarbeitung von benutzerdefinierten Ereignissen, die von Ihrem System aufgerufen wurden und für eine Seite spezifisch sind.

Event-Handler auf Parameterebene

Event-Handler auf Parameterebene sind Event-Handler, die auf einen Formularparameter angewendet werden. Sie werden auch als Handler für die erneute Eingabeaufforderung bezeichnet. Diese Event-Handler lassen keine benutzerdefinierten Ereignisse zu, da sie speziell für die Verarbeitung ungültiger Endnutzereingaben beim Ausfüllen von Formularen vorgesehen sind.

Diese Arten von Handlern haben folgende Anwendungsfälle:

X Posten
Der Endnutzer hat keine gültige Eingabe bereitgestellt, als er aufgefordert wurde, einen Formularparameter auszufüllen.

Eingebundene Ereignisse

Die folgenden Ereignisse sind eingebettet. Einige Ereignisse sind auf bestimmte Ebenen beschränkt.

Ereignisname
Ablaufebene Seitenebene Parameterebene Wird ausgelöst, wenn Folgendes eintritt
sys.no-match-default Endnutzereingaben stimmen nicht mit Intents für Handler überein, die sich im Bereich befinden, und erfüllen auch keine Formularparameter.
sys.no-match-[1-6] Wenn Sie Handler für eines dieser numerisch sortierten Ereignisse angeben, werden sie anstelle von sys.no-match-default und in dieser Reihenfolge aufgerufen: sys.no-match-1, sys.no-match-2, ...
sys.no-input-default Die Endnutzereingabe wurde nicht empfangen. Dies kann in folgenden Fällen aufgerufen werden:
  • Dialogflow empfängt eine leere Texteingabe durch den Endnutzer.
  • Dialogflow empfängt eine leere Audioeingabe an Endnutzer oder die Eingabe enthält keine erkannte Sprache.
  • Eine keine Zeitüberschreitung tritt vor, wenn die Audioeingabe der Endnutzer eine erkannte Sprache enthält.
sys.no-input-[1-6] Wenn Sie Handler für eines dieser numerisch sortierten Ereignisse angeben, werden sie anstelle von sys.no-input-default und in dieser Reihenfolge aufgerufen: sys.no-input-1, sys.no-input-2, ...
sys.invalid-parameter Wird aufgerufen, wenn ein Webhook den Parameter für ungültig erklärt.
webhook.error Der Webhook-Aufruf hat einen Fehler zurückgegeben.
webhook.error.timeout Zeitüberschreitung des Webhook-Aufrufs.

Benutzerdefinierte Ereignisse

Sie können benutzerdefinierte Ereignisse und Event-Handler erstellen. Ereignisse werden einfach anhand ihres Namens identifiziert. Verwenden Sie nach Möglichkeit keine Ereignisnamen, die mit sys. oder webhook. beginnen, um Konflikte mit integrierten Ereignissen zu vermeiden.

Informationen zum Aufrufen eines Ereignisses mit der API finden Sie im Feld queryInput.event der Methode detectIntent für den Typ Session.

Wählen Sie ein Protokoll und eine Version für die Sitzungsreferenz aus:

Protokoll V3 V3beta1
REST Sitzungsressource Sitzungsressource
RPC Sitzungsoberfläche Sitzungsoberfläche
C# Nicht verfügbar Nicht verfügbar
Go Nicht verfügbar Nicht verfügbar
Java SessionsClient SessionsClient
Node.js SessionsClient SessionsClient
PHP Nicht verfügbar Nicht verfügbar
Python SessionsClient SessionsClient
Ruby Nicht verfügbar Nicht verfügbar

Auswertungsreihenfolge

Handler werden in einer bestimmten Reihenfolge ausgewertet. Es gelten die folgenden allgemeinen Regeln:

  1. Nur Handler im Bereich werden ausgewertet.
  2. Es können nur Handler aufgerufen werden, deren Anforderungen erfüllt sind.
  3. Wenn ein Handler ohne Übergangsziel aufgerufen wird, wird die Liste der Handler weiter geprüft. Aufgrund dieser Regel können verschiedene Auftragsausführungen mehrere Nachrichten zur Antwortwarteschlange hinzufügen.
  4. Wenn ein Handler mit einem Umstellungsziel aufgerufen wird, endet die Auswertung der Handler-Liste.
  5. Wenn ein Handler mit Auftragsausführung aufgerufen wird und die Auftragsausführung zu einem Webhook-Fehler führt, gilt Folgendes:
    • Wenn für den Handler ein Übergangsziel definiert ist, schlägt der Webhook im Hintergrund fehl.
    • Wenn ein Event-Handler im Bereich ist, wird das Ereignis verarbeitet und die Auswertung der Handler-Liste beendet.
    • Wenn für das Ereignis kein Event-Handler vorhanden ist, schlägt der Webhook fehl.
  6. Wenn eine Intent-Anforderung erfüllt ist, wird der Intent verwendet, sodass nur der erste Routen-Handler, der für den Intent gefunden wurde, aufgerufen werden kann. Weitere Informationen zu den Ausnahmen finden Sie unter Intent-Weitersetzung.
  7. Wenn eine Bedingung erfüllt ist, wird die Bedingung nicht verarbeitet. Daher können mehrere Routen mit der Bedingung aufgerufen werden.
  8. Wenn eine Ereignisanforderung erfüllt ist, wird das Ereignis verbraucht, sodass nur der erste Event-Handler für das Ereignis aufgerufen werden kann.
  9. Der Handler-Aufrufstack kann die Bewertungsreihenfolge beeinflussen.

Die Auswertung erfolgt in drei Phasen:

  1. Routen, die eine Intent-Anforderung haben, werden in dieser Reihenfolge bewertet:
    1. Seitenebene: Einzelne Routen, die in der angegebenen Reihenfolge auf die aktuelle Seite angewendet werden.
    2. Gruppen auf Seitenebene: Route-Gruppen, die in der angegebenen Reihenfolge auf die aktuelle Seite angewendet werden.
    3. Ablaufebene: Routen, die in der angegebenen Reihenfolge auf den aktiven Ablauf angewendet werden.
    4. Gruppen auf Ablaufebene: Routengruppen, die auf den aktiven Ablauf in der angegebenen Reihenfolge angewendet werden.
  2. Routen, die nur eine Bedingungsanforderung enthalten, werden in dieser Reihenfolge bewertet:
    1. Seitenebene: Einzelne Routen, die in der angegebenen Reihenfolge auf die aktuelle Seite angewendet werden.
    2. Gruppen auf Seitenebene: Route-Gruppen, die in der angegebenen Reihenfolge auf die aktuelle Seite angewendet werden.
    3. Ablaufebene (nur wenn die aktuelle Seite die Ablaufstartseite): Routen, die auf den aktiven Ablauf angewendet werden, in der angegebenen Reihenfolge. auf.
    4. Gruppen auf Ablaufebene (nur wenn die aktuelle Seite die Flussstartseite ist): Routengruppen, die auf die aktive in der angegebenen Reihenfolge erfolgen.
  3. Event-Handler werden in dieser Reihenfolge ausgewertet:
    1. Parameterebene: Event-Handler, die auf den Formularparameter der aktuellen Seite angewendet werden, den der Agent derzeit auszufüllen versucht (Handler für die erneute Eingabeaufforderung), in der angegebenen Reihenfolge.
    2. Seitenebene: Auf die aktuelle Seite angewendete Event-Handler in der angegebenen Reihenfolge.
    3. Ablaufebene: Event-Handler, die in der angegebenen Reihenfolge auf den aktiven Ablauf angewendet werden.

Symbolische Umstellungsziele

Wenn Sie ein Umstellungsziel für einen Handler eingeben, können Sie bestimmte Abläufe oder Seiten eingeben, aber auch symbolische Ziele:

Symbolisches Umstellungsziel
Beschreibung
START_PAGE Umstellung zur Startseite des gleichnamigen aktiven Ablaufs.
END_FLOW Beenden Sie den derzeit aktiven Ablauf und kehren Sie zur Seite zurück, die eine Umstellung zum aktuellen Ablauf verursacht hat. Siehe auch Handler-Aufrufstack.
END_SESSION Löschen Sie die aktuelle Sitzung und wechseln Sie zur speziellen Seite mit dem Namen END_SESSION. Mit der nächsten Nutzereingabe wird die Sitzung auf der Startseite des Standardstartablaufs neu gestartet.
PREVIOUS_PAGE Umstellung zur vorherigen Seite
CURRENT_PAGE Wechseln Sie wieder zur aktuellen Seite. Das kann hilfreich sein, wenn der Agent etwas wiederholen soll.

Handler-Aufrufstack

Wenn eine Sitzung zu END_FLOW wechselt, kehren sie zur aufrufenden Seite zurück, die einen Übergang zum abgeschlossenen Ablauf verursacht hat. In diesem Fall bleibt der Handler-Aufrufstack erhalten. Alle Handler, die zuvor von der aufrufenden Seite ausgewertet wurden, werden übersprungen und die verbleibenden Handler werden der Reihe nach ausgewertet.

Beispiel:

  1. Die Seite P enthält drei Handler in dieser Reihenfolge: H1, H2, H3.
  2. H1 wird bewertet, aber kein Wechsel verursacht.
  3. H2 wird ausgewertet und führt zu einem Übergang von F.
  4. Eine Seite im Ablauf F wechselt zu END_FLOW.
  5. Die Sitzung kehrt zu Seite P zurück, die wiederum mit einem beibehaltenen Status wieder aktiv wird.
  6. Die Handler-Evaluierung auf Seite P wird mit dem Status beibehalten, der beibehalten wird. Das Ergebnis wird dann von H3 ausgewertet.

Bedingungen festlegen

Zum Festlegen von Bedingungen mit der Konsole geben Sie Bedingungsregeln mit einer der folgenden drei logischen Optionen an:

  • AT LEAST ONE-Regel (ODER)
  • Übereinstimmung mit JEDER Regel (UND)
  • Ausdruck anpassen

Mit der UND-/ODER-Option können Sie einfache oder zusammengesetzte Bedingungen für Parameterwerte erstellen.

Sie können für alle Bedingungstypen, einschließlich Funktionen und Boolescher Konstanten, die kostenlose Option Ausdruck anpassen verwenden.

Beispiel: Wenn Sie eine Bedingung festlegen möchten, bei der eine Validierung von 10% besteht, wählen Sie die OptionAusdruck anpassen Option und geben Sie$sys.func.rand() < 0.1 in denZustände Feld:

Screenshot zum Festlegen einer benutzerdefinierten Bedingung