Einige Produkte und Funktionen werden derzeit umbenannt. Auch die Funktionen für generative Playbooks und Workflows werden zu einer einzigen konsolidierten Console migriert. Weitere Informationen

Diese Seite wurde von der Cloud Translation API übersetzt.

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 innerhalb des Ablaufs oder für den gesamten Kundenservicemitarbeiter wiederverwendbar erstellen.

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 Routengruppenressourcen, die mit einem Ablauf als übergeordnetem Element erstellt werden. Sie können innerhalb des Ablaufs wiederverwendet werden.

Routengruppen auf Agentebene

Routengruppen auf Kundenservicemitarbeiterebene sind Routengruppenressourcen, die mit einem Kundenservicemitarbeiter als übergeordnetem Element erstellt werden. Sie können im gesamten Agent wiederverwendet werden, aber Routen sind nicht zulässig, die zu einer nicht symbolischen Seite als Ziel führen.

Routen auf Ablaufebene

Routen auf Ablaufebene sind Routen, die auf einen Ablauf angewendet werden, indem sie der Startseite des Ablaufs hinzugefügt 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.

So erstellst du über die Console Routen auf Flussebene:

Öffnen Sie die Startseite des Workflows.
Klicken Sie unter Routen auf die Schaltfläche zum Hinzufügen .
Das Bearbeitungsfeld für die Route wird geöffnet.
Geben Sie Routenfelder an.
Klicken Sie auf Speichern.

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

Öffnen Sie die Startseite des Workflows.
Klicken Sie auf die Überschrift Routen.
Das Steuerfeld für die Routenliste wird geöffnet.
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 Flussebene aus der Console:

Öffnen Sie die Startseite des Workflows.
Klicken Sie auf die Überschrift Routen.
Das Steuerfeld für die Routenliste wird geöffnet.
Klicke auf das Dreipunkt-Menü .
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:

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

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

Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
Klicken Sie auf die Überschrift Routen.
Das Steuerfeld für die Routenliste wird geöffnet.
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:

Öffnen Sie die Seite (nicht die Startseite des Ablaufs).
Klicken Sie auf die Überschrift Routen.
Das Steuerfeld für die Routenliste wird geöffnet.
Klicke auf das Dreipunkt-Menü .
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 über die Console Event-Handler auf Ablaufebene:

Öffnen Sie die Startseite des Workflows.
Klicken Sie unter der Überschrift Ereignis-Handler auf die Schaltfläche „Hinzufügen“ .
Das Steuerfeld für den Ereignishandler wird geöffnet.
Geben Sie Event-Handler-Felder an.
Klicken Sie auf Speichern.

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

Öffnen Sie die Startseite des Workflows.
Klicken Sie auf die Überschrift Ereignishandler.
Die Liste der Ereignishandler wird geöffnet.
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:

Öffnen Sie eine Seite (nicht die Startseite des Navigationspfads).
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.
Klicken Sie unter der Überschrift Ereignis-Handler auf die Schaltfläche „Hinzufügen“ .
Das Steuerfeld für den Ereignishandler wird geöffnet.
Geben Sie Event-Handler-Felder an.
Klicken Sie auf Speichern.

So löschen Sie Event-Handler auf Seitenebene aus der Console:

Öffnen Sie eine Seite (nicht die Startseite des Ablaufs).
Klicken Sie auf die Überschrift Ereignishandler.
Die Liste der Ereignishandler wird geöffnet.
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 über die Console Event-Handler auf Parameterebene:

Öffnen Sie eine Seite mit Formularparametern.
Klicken Sie auf einen Parameter.
Das Steuerfeld für Parameter wird geöffnet.
Scrollen Sie nach unten zum Abschnitt Ereignis-Handler für Aufforderungen und klicken Sie dann auf Ereignis-Handler hinzufügen.
Das Steuerfeld für den Ereignishandler wird geöffnet.
Geben Sie Event-Handler-Felder an.
Klicken Sie auf Speichern.

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

Öffnen Sie eine Seite mit Formularparametern.
Klicken Sie auf einen Parameter.
Das Steuerfeld für Parameter wird geöffnet.
Scrollen Sie nach unten zum Abschnitt Event-Handler für erneute Eingabeaufforderungen.
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: Conversational Agents (Dialogflow CX) erhalten eine leere Texteingabe vom Endnutzer. Conversational Agents (Dialogflow CX) erhalten eine leere Audioeingabe vom Endnutzer 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 mit nicht generativen Intents oder Parametern abgeglichen wird. Wenn nicht angegeben, behandelt Conversational Agents (Dialogflow CX) lange Nutzeräußerungen als `no-match`. Bei Streaming-Audioinputs 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 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 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.unavailable`	✔	✔		Der Webhook hat den Fehler 503 – Dienst nicht verfügbar 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.not-found`	✔	✔		Der Webhook-Aufruf ist fehlgeschlagen, weil die Webhook-URL nicht erreichbar war. 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.
`flow-cancelled`	✔	✔		Der Endnutzer hat den Ablauf abgebrochen. Dieses Ereignis wird durch die Seite „Ablauf mit Stornierung beenden“ ausgelöst. Weitere Informationen finden Sie unter `END_FLOW_WITH_CANCELLATION` symbolisches Umstellungsziel.
`flow-failed`	✔	✔		Mit diesem Ablauf konnte die Aufgabe nicht abgeschlossen werden. Dieses Ereignis wird durch die Seite „Ablauf mit Fehler beenden“ ausgelöst. Weitere Informationen finden Sie unter `END_FLOW_WITH_FAILURE` symbolisches Umstellungsziel.
`flow-failed-human-escalation`	✔	✔		Der Endnutzer möchte mit einem Kundenservicemitarbeiter sprechen. Dieses Ereignis wird durch die Seite „Ablauf mit manueller Eskalierung beenden“ ausgelöst. Weitere Informationen finden Sie unter `END_FLOW_WITH_HUMAN_ESCALATION` symbolisches Umstellungsziel.

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:

Nur Handler im Bereich werden ausgewertet.
Es können nur Handler aufgerufen werden, deren Anforderungen erfüllt sind.
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.
Wenn ein Handler mit einem Umstellungsziel aufgerufen wird, endet die Auswertung der Handler-Liste.
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.
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).
Wenn eine Bedingungsanforderung erfüllt ist, wird die Bedingung nicht verbraucht. Daher können mehrere Routen mit der Bedingung aufgerufen werden.
Wenn eine Ereignisanforderung erfüllt ist, wird das Ereignis verbraucht, sodass nur der erste Event-Handler für das Ereignis aufgerufen werden kann.
Der Handler-Aufrufstack kann sich auf die Auswertungsreihenfolge auswirken.

Die Auswertung erfolgt in drei Phasen:

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.
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.
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 Größe des Handler-Aufrufstacks und des Ablaufstacks.
`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 diese Umstellung mit dem eingebauten 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-Aufrufstack und Ablaufstack

Wenn eine Sitzung von einem Ablauf zu einem anderen mit bestimmten Übergangszielen übergeht, wird jeder Ablauf in den Ablaufstapel geschoben.

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:

Seite P hat drei Handler in dieser Reihenfolge: H1, H2, H3.
H1 wird ausgewertet, verursacht jedoch keine Umstellung.
H2 wird ausgewertet und führt zu einem Übergang zum AblaufF.
Eine Seite im Ablauf F geht zu END_FLOW über.
Die Sitzung kehrt zu Seite P zurück, die mit einem beibehaltenen Status wieder aktiv wird.
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. Wenn das maximale Stack-Limit überschritten wird, werden möglicherweise Abläufe aus dem Stack entfernt, was zu unerwartetem Verhalten bei der Verwendung der END_FLOW-Übergang führt. 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, wird die Sitzung durch die END_FLOW-Übergang beendet.

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