Zustands-Handler

Zustands-Handler, auch einfach Handler genannt, werden zur Steuerung der Unterhaltung verwendet. Handler erstellen Antworten für Endnutzer und/oder wechseln die aktuelle 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-Übergangsziel 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. Geltungsbereich 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. Bewertung 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.

Umfang

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 Element
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.
Bedingungsanforderung 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 Element
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 auf true gesetzte Bedingungsprüfung, die einen Seitenübergang erzwingt.

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. Sie können diese Gruppenressourcen erstellen, die entweder innerhalb des Ablaufs oder des gesamten Agents wiederverwendbar sind.

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.

Routengruppen auf Ablaufebene

Routengruppen auf Ablaufebene sind Routinggruppenressourcen, die mit einem übergeordneten Ablauf erstellt werden. Sie können innerhalb des Ablaufs wiederverwendet werden.

Routengruppen auf Agent-Ebene

Routengruppen auf Agent-Ebene sind Routinggruppenressourcen, die mit einem übergeordneten Agent erstellt werden. Sie sind innerhalb des gesamten Agents wiederverwendbar, aber Routen, die zu einer nicht symbolischen Seite als Ziel übergehen, sind nicht zulässig.

Routen auf Ablaufebene

Routen auf Ablaufebene sind Routen, die auf einen Ablauf angewendet werden, indem sie zur Startseite des Ablaufs hinzugefügt werden. Diese Arten von Handlern haben folgende Anwendungsfälle:

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

So erstellen Sie Routen auf Ablaufebene über die Console:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie unter der Überschrift Routen auf die Schaltfläche .
  3. Das Bearbeitungsfeld für die Route wird geöffnet.
  4. Geben Sie Routenfelder an.
  5. Klicken Sie auf Speichern.

So ordnen Sie Routen auf Ablaufebene über die Console neu an:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie auf die Überschrift Routen.
  3. Der Bereich mit der Routenliste wird geöffnet.
  4. Ziehen Sie die Routen in die gewünschte Reihenfolge. Alternativ können Sie auf das Dreipunkt-Menü klicken und dann Verschieben nach auswählen.

So löschen Sie Routen auf Ablaufebene über die Console:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie auf die Überschrift Routen.
  3. Der Bereich mit der Routenliste wird geöffnet.
  4. Klicken Sie auf das Dreipunkt-Menü .
  5. Wählen Sie Löschen aus.

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.

So erstellen Sie über die Console Routen auf Seitenebene:

  1. Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
  2. Klicken Sie unter der Überschrift Routen auf die Schaltfläche .
  3. Das Bearbeitungsfeld für die Route wird geöffnet.
  4. Geben Sie Routenfelder an.
  5. Klicken Sie auf Speichern.

So ordnen Sie Routen auf Seitenebene über die Console neu an:

  1. Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
  2. Klicken Sie auf die Überschrift Routen.
  3. Der Bereich mit der Routenliste wird geöffnet.
  4. Ziehen Sie die Routen in die gewünschte Reihenfolge. Alternativ können Sie auf das Dreipunkt-Menü klicken und dann Verschieben nach auswählen.

So löschen Sie Routen auf Seitenebene über die Console:

  1. Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
  2. Klicken Sie auf die Überschrift Routen.
  3. Der Bereich mit der Routenliste wird geöffnet.
  4. Klicken Sie auf das Dreipunkt-Menü .
  5. Wählen Sie Löschen aus.

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 Element
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.

So erstellen Sie Event-Handler auf Ablaufebene über die Console:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie unter der Überschrift Event-Handler auf die Schaltfläche hinzufügen.
  3. Der Ereignis-Handler-Bereich wird geöffnet.
  4. Geben Sie Event-Handler-Felder an.
  5. Klicken Sie auf Speichern.

So löschen Sie Event-Handler auf Ablaufebene über die Console:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie auf die Überschrift Event-Handler.
  3. Der Bereich mit der Event-Handler-Liste wird geöffnet.
  4. Bewegen Sie den Mauszeiger auf einen Event-Handler und klicken Sie auf die Schaltfläche „Löschen“ .

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.

So erstellen Sie über die Console Event-Handler auf Seitenebene:

  1. Öffnen Sie eine Seite (nicht die Startseite des Ablaufs).
  2. Wenn die Überschrift Event-Handler nicht vorhanden ist, klicken Sie auf Zustands-Handler hinzufügen, wählen Sie Event-Handler aus und klicken Sie dann auf Übernehmen.
  3. Klicken Sie unter der Überschrift Event-Handler auf die Schaltfläche hinzufügen.
  4. Der Ereignis-Handler-Bereich wird geöffnet.
  5. Geben Sie Event-Handler-Felder an.
  6. Klicken Sie auf Speichern.

So löschen Sie Event-Handler auf Seitenebene über die Console:

  1. Öffnen Sie eine Seite (nicht die Startseite des Ablaufs).
  2. Klicken Sie auf die Überschrift Event-Handler.
  3. Der Bereich mit der Event-Handler-Liste wird geöffnet.
  4. Bewegen Sie den Mauszeiger auf einen Event-Handler und klicken Sie auf die Schaltfläche „Löschen“ .

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.

So erstellen Sie Event-Handler auf Parameterebene über die Console:

  1. Öffnen Sie eine Seite mit Formularparametern.
  2. Klicken Sie auf einen Parameter.
  3. Der Parameterbereich wird geöffnet.
  4. Scrollen Sie nach unten zum Abschnitt Reprompt Event-Handler und klicken Sie dann auf Add Event-Handler.
  5. Der Ereignis-Handler-Bereich wird geöffnet.
  6. Geben Sie Event-Handler-Felder an.
  7. Klicken Sie auf Speichern.

So löschen Sie Event-Handler auf Parameterebene über die Console:

  1. Öffnen Sie eine Seite mit Formularparametern.
  2. Klicken Sie auf einen Parameter.
  3. Der Parameterbereich wird geöffnet.
  4. Scrollen Sie nach unten zum Abschnitt Reprompt Event-Handler.
  5. Bewegen Sie den Mauszeiger auf einen Event-Handler und klicken Sie auf die Schaltfläche „Löschen“ .

Eingebundene Ereignisse

Die folgenden Ereignisse sind integriert und werden von Dialogflow aufgerufen. Einige Ereignisse sind auf bestimmte Ebenen beschränkt.

Ereignisname
 Ablaufebene Seitenebene Parameterebene Wird ausgelöst, wenn Folgendes eintritt
sys.no-match-default ✔ ✔ ✔
  • Für Flow- oder Seitenebene: Die Endnutzereingabe stimmt mit keinen Intents für Handler überein, die betroffen sind.
  • Auf Parameterebene: Die Endnutzereingabe entspricht nicht dem 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 erhält eine leere Texteingabe durch den Endnutzer.
  • Dialogflow empfängt eine leere Endnutzer-Audioeingabe oder die Eingabe enthält keine erkannte Sprache.
  • Ein Sprachzeitlimit tritt auf, bevor die Audioeingabe des Endnutzers 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 eine Webhook-Antwort den Parameter durch Festlegen von WebhookResponse.pageInfo.formInfo.parameterInfo.state auf INVALID ungültig macht.
sys.long-utterance ✔ ✔ ✔ Die Endnutzereingabe überschreitet die maximal zulässige Länge von 256 Zeichen, die von nicht generativen Intents oder Parametern abgeglichen werden kann. Wenn nicht angegeben, behandelt Dialogflow lange Nutzeräußerungen als no-match. Bei Audiostreams wird dieses Ereignis erst ausgelöst, nachdem der Client den Audiostream geschlossen hat.
webhook.error ✔ ✔ Der Webhook-Aufruf hat einen Fehler zurückgegeben. Dieses Ereignis wird nur aufgerufen: 1) wenn es keinen detaillierten Webhook-Event-Handler (z. B. „webhook.error.timeout“) gibt, der mit dem Webhook-Fehlercode übereinstimmt. 2) Wenn in der ursprünglichen Route kein Übergangsziel festgelegt ist, das die Auftragsausführung mit dem fehlerhaften Webhook aufgerufen hat. Weitere Informationen finden Sie im Abschnitt Bewertungsreihenfolge.
webhook.error.timeout ✔ ✔ Zeitüberschreitung des Webhook-Aufrufs. Ein Webhook-Ereignis wird nur aufgerufen, wenn in der ursprünglichen Route, die die Auftragsausführung mit dem fehlgeschlagenen Webhook aufgerufen hat, kein Übergangsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Bewertungsreihenfolge.
webhook.error.bad-request ✔ ✔ Der Webhook hat die Anfrage 400 Bad Request zurückgegeben. Ein Webhook-Ereignis wird nur aufgerufen, wenn in der ursprünglichen Route, die die Auftragsausführung mit dem fehlgeschlagenen Webhook aufgerufen hat, kein Übergangsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Bewertungsreihenfolge.
webhook.error.rejected ✔ ✔ Der Webhook hat 401 Unauthorized oder 403 Forbidden zurückgegeben. Ein Webhook-Ereignis wird nur aufgerufen, wenn in der ursprünglichen Route, die die Auftragsausführung mit dem fehlgeschlagenen Webhook aufgerufen hat, kein Übergangsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Bewertungsreihenfolge.
webhook.error.unavailable ✔ ✔ Der Webhook hat 503 Service Nicht verfügbar zurückgegeben. Ein Webhook-Ereignis wird nur aufgerufen, wenn in der ursprünglichen Route, die die Auftragsausführung mit dem fehlgeschlagenen Webhook aufgerufen hat, kein Übergangsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Bewertungsreihenfolge.
webhook.error.not-found ✔ ✔ Der Webhook-Aufruf ist fehlgeschlagen, weil die Webhook-URL nicht erreichbar war. Ein Webhook-Ereignis wird nur aufgerufen, wenn in der ursprünglichen Route, die die Auftragsausführung mit dem fehlgeschlagenen Webhook aufgerufen hat, kein Übergangsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Bewertungsreihenfolge.
flow-cancelled ✔ ✔ Der Endnutzer hat einen Vorgang abgebrochen. Dieses Ereignis wird von der Seite „Ablauf mit Abbruch beenden“ ausgelöst, siehe das symbolische Übergangsziel END_FLOW_WITH_CANCELLATION.
flow-failed ✔ ✔ Der Ablauf konnte die angegebene Aufgabe nicht abschließen. Dieses Ereignis wird von der Seite „Ablauf mit Fehler beenden“ ausgelöst, siehe das symbolische Übergangsziel END_FLOW_WITH_FAILURE.
flow-failed-human-escalation ✔ ✔ Der Endnutzer möchte mit einem Kundenservicemitarbeiter sprechen. Dieses Ereignis wird über die Seite „Ablauf mit menschlicher Eskalierung beenden“ ausgelöst, siehe das symbolische Übergangsziel von END_FLOW_WITH_HUMAN_ESCALATION.

Benutzerdefinierte Ereignisse

Sie können benutzerdefinierte Ereignisse und Event-Handler erstellen. Benutzerdefinierte Ereignisse werden verwendet, um Vorgänge zu verarbeiten, die außerhalb der Unterhaltung mit dem Endnutzer stattfinden. Beispielsweise hat der Endnutzer auf eine Schaltfläche geklickt, eine bestimmte Zeit verstrichen, das verfügbare Inventar hat sich während der Unterhaltung geändert usw.

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++ SessionsClient Nicht verfügbar
C# SessionsClient Nicht verfügbar
Einfach loslegen (Go) SessionsClient 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 diese zu einem Webhook-Fehler führt:
    • Wenn für den Handler ein Umstellungsziel definiert ist, schlägt der Webhook 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 verbraucht, sodass nur der erste Routen-Handler für den Intent aufgerufen werden kann (siehe Intent-Übernahme für die Ausnahmen).
  7. Wenn eine Bedingungsanforderung erfüllt ist, wird die Bedingung nicht verbraucht. 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 sich auf die Auswertungsreihenfolge auswirken.

Die Auswertung erfolgt in drei Phasen:

  1. Routen mit einer Intent-Anforderung werden in dieser Reihenfolge ausgewertet:
    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 in der angegebenen Reihenfolge auf den aktiven Ablauf angewendet werden.
  2. Routen, für die nur eine Bedingung erforderlich ist, werden in dieser Reihenfolge ausgewertet:
    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 ist): Routen, die in der angegebenen Reihenfolge auf den aktiven Ablauf angewendet werden.
    4. Gruppen auf Ablaufebene (nur wenn die aktuelle Seite die Ablaufstartseite ist): Routengruppen, die in der angegebenen Reihenfolge auf den aktiven Ablauf angewendet werden.
  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. Weitere Informationen finden Sie unter Handler-Aufrufstack und Limit für Flussstacks.
END_FLOW_WITH_CANCELLATION Beenden Sie den derzeit aktiven Ablauf und kehren Sie zur Seite zurück, die eine Umstellung zum aktuellen Ablauf verursacht hat. Die aufrufende Seite kann diesen Übergang mit dem integrierten Ereignis flow-cancelled verarbeiten. Weitere Informationen finden Sie unter Handler-Aufrufstack und Limit für Flussstacks.
END_FLOW_WITH_FAILURE Beenden Sie den derzeit aktiven Ablauf und kehren Sie zur Seite zurück, die eine Umstellung zum aktuellen Ablauf verursacht hat. Die aufrufende Seite kann diesen Übergang mit dem integrierten Ereignis flow-failed verarbeiten. Weitere Informationen finden Sie unter Handler-Aufrufstack und Limit für Flussstacks.
END_FLOW_WITH_HUMAN_ESCALATION Beenden Sie den derzeit aktiven Ablauf und kehren Sie zur Seite zurück, die eine Umstellung zum aktuellen Ablauf verursacht hat. Die aufrufende Seite kann diesen Übergang mit dem integrierten Ereignis flow-failed-human-escalation verarbeiten. Weitere Informationen finden Sie unter Handler-Aufrufstack und Limit für Flussstacks.
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 Übergang zur vorherigen Seite, der einen Übergang zur aktuellen Seite verursacht hat. Der Seitenstatus von der vorherigen Seite wird nach dem Übergang wiederhergestellt.
CURRENT_PAGE Wechseln Sie wieder zur aktuellen Seite. Das kann hilfreich sein, wenn der Agent etwas wiederholen soll.

Handler-Aufrufstack und Limit für Flussstacks

Wenn eine Sitzung mit bestimmten Übergangzielen von Ablauf zu Ablauf wechselt, wird jeder Ablauf in den Stapel des Ablaufs verschoben.

Handler-Aufrufstack

Wenn eine Sitzung auf END_FLOW wechselt, kehrt sie zur aufrufenden Seite zurück, die eine Umstellung 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. Seite P hat drei Handler in dieser Reihenfolge: H1, H2, H3.
  2. H1 wird ausgewertet, verursacht jedoch keine Umstellung.
  3. H2 wird ausgewertet und führt zu einem Übergang zum AblaufF.
  4. Eine Seite im Ablauf F geht zu END_FLOW über.
  5. Die Sitzung kehrt zu Seite P zurück, die mit einem beibehaltenen Status wieder aktiv wird.
  6. Die Handler-Auswertung auf Seite P wird aus dem beibehaltenen Status fortgesetzt, sodass H3 ausgewertet wird.

Limit für Datenfluss-Stack

Das maximale Flow-Stack-Limit beträgt 25. Das Überschreiten des maximalen Stack-Limits kann dazu führen, dass Datenflüsse aus dem Stack entfernt werden, was zu unerwartetem Verhalten bei der Verwendung des END_FLOW-Übergangs führt. Minimieren Sie die Anzahl der Fluss-zu-Fluss-Übergänge vor der END_FLOW-Umstellung, um diese potenziellen Probleme zu vermeiden.

Wenn der Ablaufstack leer ist, beendet der Übergang END_FLOW die Sitzung.

Bedingungen festlegen

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

  • Übereinstimmung mit MINDESTENS EINER Regel (ODER)
  • Übereinstimmung mit JEDER Regel (UND)
  • Ausdruck anpassen

Der Einfachheit halber können Sie die UND/ODER-Optionen verwenden, um einfache oder zusammengesetzte Bedingungen für Parameterwerte zu erstellen.

Sie können die kostenlose Formatoption Ausdruck anpassen für alle Bedingungstypen verwenden, einschließlich Systemfunktionen und boolean constants.

Wenn Sie beispielsweise eine Bedingung festlegen möchten, die mit einer Wahrscheinlichkeit von 10 % die Bewertung besteht, wählen Sie die Option Ausdruck anpassen und geben Sie $sys.func.rand() < 0.1 in das Eingabefeld Bedingung ein:

Screenshot vom Festlegen einer benutzerdefinierten Bedingung

Zurück
Pages
Weiter
Intents