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-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. 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 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 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 entweder im Ablauf oder den gesamten Agent.

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 Flussebene

Routinggruppen auf Ablaufebene sind Routinggruppenressourcen, die mit einer als übergeordnetes Element. Sie können innerhalb des Ablaufs wiederverwendet werden.

Routinggruppen auf Agent-Ebene

Routinggruppen auf Agent-Ebene sind Routinggruppenressourcen, die mit einer Agent als übergeordnetes Element. Sie können innerhalb des gesamten Agents wiederverwendbar sein, aber Routen sind nicht zulässig. die zu einer nicht symbolischen Seite als Ziel übergehen.

Routen auf Ablaufebene

Routen auf Ablaufebene sind Routen, die auf einen Ablauf angewendet werden. indem Sie sie zur Startseite des Ablaufs hinzufügen. 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.

So erstellst du über die Console Routen auf Flussebene:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie unter Routen auf die Schaltfläche zum Hinzufügen .
  3. Das Bearbeitungssteuerfeld 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. Das Steuerfeld für die 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 aus der Console:

  1. Öffnen Sie die Startseite des Ablaufs.
  2. Klicken Sie auf die Überschrift Routen.
  3. Das Steuerfeld 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 Routes auf Seitenebene:

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

So ordnen Sie Routen auf Seitenebene in der Console neu an:

  1. Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
  2. Klicken Sie auf die Überschrift Routen.
  3. Das Steuerfeld für die 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 aus der Console:

  1. Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
  2. Klicken Sie auf die Überschrift Routen.
  3. Das Steuerfeld 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 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.

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

  1. Öffnen Sie die Startseite des Workflows.
  2. Klicke auf die Schaltfläche „ hinzufügen“ in der Überschrift Event-Handler.
  3. Das Steuerfeld für den Ereignishandler wird geöffnet.
  4. Geben Sie Event-Handler-Felder an.
  5. Klicken Sie auf Speichern.

So löschen Sie Ereignis-Handler auf Ablaufebene aus der Console:

  1. Öffnen Sie die Startseite des Workflows.
  2. Klicken Sie auf die Überschrift Ereignishandler.
  3. Das Listenfeld des Event-Handlers wird geöffnet.
  4. Bewegen Sie den Mauszeiger auf einen Ereignishandler und klicken Sie dann 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 angezeigt wird, klicken Sie auf Status-Handler hinzufügen, wählen Sie Event-Handler aus und klicken Sie dann auf Übernehmen.
  3. Klicken Sie unter der Überschrift Ereignis-Handler auf die Schaltfläche „Hinzufügen“ .
  4. Das Steuerfeld für den Ereignishandler 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 Ereignishandler.
  3. Das Listenfeld des Event-Handlers wird geöffnet.
  4. Bewegen Sie den Mauszeiger auf einen Ereignishandler und klicken Sie dann 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. Das Steuerfeld für Parameter wird geöffnet.
  4. Scrollen Sie nach unten zum Abschnitt Ereignis-Handler für Aufforderungen und klicken Sie dann auf Ereignis-Handler hinzufügen.
  5. Das Steuerfeld für den Ereignishandler 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. Das Parameterfeld wird geöffnet.
  4. Scrollen Sie nach unten zum Abschnitt Event-Handler für erneute Eingabeaufforderungen.
  5. Bewegen Sie den Mauszeiger auf einen Ereignishandler und klicken Sie dann auf die Schaltfläche „Löschen“ .

Eingebundene Ereignisse

Die folgenden Ereignisse sind eingebettet und werden von Conversational Agents (Dialogflow CX) aufgerufen. Einige Ereignisse sind auf bestimmte Ebenen beschränkt.

Ereignisname
 Ablaufebene Seitenebene Parameterebene Wird ausgelöst, wenn Folgendes eintritt
sys.no-match-default ✔ ✔ ✔
  • Auf Navigations- oder Seitenebene: Die Eingabe des Endnutzers stimmt nicht mit Intents für Handler überein, die sich im Geltungsbereich befinden.
  • Auf Parameterebene: Die Eingabe des Endnutzers erfüllt nicht den 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:
  • Konversations-Agents (Dialogflow CX) erhalten eine leere Texteingabe vom Endnutzer.
  • Conversational Agents (Dialogflow CX) empfangen leere Endnutzer-Audioeingaben 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 (256 Zeichen), die von nicht generativen Intents oder Parametern abgeglichen wird. Wenn nicht angegeben, behandelt Conversational Agents (Dialogflow CX) lange Nutzeräußerungen als no-match. Bei Audioeingaben wird dieses Ereignis erst ausgelöst, nachdem der Client den Audiostream schließt.
webhook.error ✔ ✔ Der Webhook-Aufruf hat einen Fehler zurückgegeben. Dieses Ereignis wird nur dann aufgerufen: 1) wenn es keinen detaillierten Webhook-Ereignis-Handler (z. B. webhook.error.timeout) gibt, der mit dem Webhook-Fehlercode übereinstimmt, 2) wenn in der ursprünglichen Route, über die die Auftragsausführung mit dem fehlgeschlagenen Webhook aufgerufen wurde, kein Übergangsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Auswertungsreihenfolge.
webhook.error.timeout ✔ ✔ Zeitüberschreitung des Webhook-Aufrufs. Ein Webhook-Ereignis wird nur dann aufgerufen, wenn in der ursprünglichen Route, über die die Ausführung mit dem fehlgeschlagenen Webhook aufgerufen wurde, kein Umstellungsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Auswertungsreihenfolge.
webhook.error.bad-request ✔ ✔ Der Webhook hat 400 Bad Request zurückgegeben. Ein Webhook-Ereignis wird nur dann aufgerufen, wenn in der ursprünglichen Route, über die die Ausführung mit dem fehlgeschlagenen Webhook aufgerufen wurde, kein Umstellungsziel festgelegt ist. Weitere Informationen finden Sie im Abschnitt Auswertungsreihenfolge.
webhook.error.rejected ✔ ✔ Der Webhook hat den Fehler 401 Unauthorized (401 – nicht autorisiert) oder 403 Forbidden (403 – verboten) 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 Auswertungsreihenfolge.
webhook.error.unavailable ✔ ✔ Der Webhook hat 503 Service Unavailable 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 Anordnung der Bewertung.
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 Anordnung der Bewertung.
flow-cancelled ✔ ✔ Der Endnutzer hat den Ablauf abgebrochen. Dieses Ereignis wird von der Seite „Ablauf mit Abbruch“ ausgelöst, siehe das symbolische Übergangsziel END_FLOW_WITH_CANCELLATION.
flow-failed ✔ ✔ Dieser Ablauf konnte die angegebene Aufgabe nicht abschließen. Dieses Ereignis wird von der Seite „Ablauf beenden mit Fehlern“ 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 von der Seite „Ablauf mit menschlicher Eskalation“ ausgelöst, siehe das symbolische Übergangsziel END_FLOW_WITH_HUMAN_ESCALATION.

Benutzerdefinierte Ereignisse

Sie können benutzerdefinierte Ereignisse und Event-Handler erstellen. Mit benutzerdefinierten Ereignissen werden Dinge verarbeitet, die außerhalb der Unterhaltung mit dem Endnutzer passieren. Beispielsweise, wenn der Endnutzer auf eine Schaltfläche geklickt hat, eine bestimmte Zeit verstrichen ist oder sich das verfügbare Inventar während der Unterhaltung geändert hat.

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
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 die Auftragsausführung zu einem Webhook-Fehler führt, gilt Folgendes:
    • 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, 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 in der angegebenen Reihenfolge auf den aktiven Ablauf 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 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. Siehe auch Größe des Handler-Aufrufstacks und des Ablaufstacks.
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 diese Umstellung mit dem eingebauten Ereignis flow-cancelled verarbeiten. Siehe auch Größe des Handler-Aufrufstacks und des Ablaufstacks.
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 diese Umstellung mit dem eingebauten Ereignis flow-failed verarbeiten. Siehe auch Limit des Handler-Aufrufs und des Ablaufs.
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. Siehe auch Größe des Handler-Aufrufstacks und des Ablaufstacks.
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.

Limit für Handler-Aufruf- und Flow-Stacks

Wenn eine Sitzung von Flow zu Flow mit bestimmten Übergangszielen übergeht, wird jeder Flow auf den Ablauf übertragen, stack

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 den Ablaufstapel

Das maximale Limit für den Ablaufstapel ist 25. Eine Überschreitung des Stack-Höchstlimits dass Datenflüsse aus dem Stack entfernt werden, was zu unerwartetem Verhalten führt. wenn Sie den Übergang END_FLOW verwenden. Um diese potenziellen Probleme zu vermeiden, sollten Sie die Anzahl der Übergänge zwischen den einzelnen Abläufen vor dem END_FLOW-Übergang minimieren.

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

Bedingungen festlegen

Zum Festlegen von Bedingungen 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 boolesche Konstanten.

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
Seiten
Weiter
Intents