Hinweis zum Ende des Supports: Am 15. September 2025 AWS wird der Support für Amazon Lex V1 eingestellt. Nach dem 15. September 2025 können Sie nicht mehr auf die Amazon-Lex-V1-Konsole oder die Amazon-Lex-V1-Ressourcen zugreifen. Wenn Sie Amazon Lex V2 verwenden, lesen Sie stattdessen das [Amazon Lex V2-Handbuch](https://docs.aws.amazon.com/lexv2/latest/dg/what-is.html). Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Schritt 5 (optional): Prüfen der Details des Informationsflusses (Konsole) In diesem Abschnitt wird der Informationsfluss zwischen dem Client und Amazon Lex für jede Benutzereingabe erläutert, einschließlich der Integration der Lambda-Funktion. **Anmerkung** In diesem Abschnitt wird davon ausgegangen, dass der Client Anfragen über die `PostText` Runtime-API an Amazon Lex sendet, und zeigt die Anfrage- und Antwortdetails entsprechend an. Ein Beispiel für den Informationsfluss zwischen dem Client und Amazon Lex, bei dem der Client die `PostContent` API verwendet, finden Sie unter[Schritt 2a (optional): Prüfen der Details des Informationsflusses gesprochener Inhalte (Konsole)](gs-bp-details-postcontent-flow.md). Weitere Informationen über die `PostText`-Laufzeit-API und weitere Details zu den Anforderungen und Antworten, die in den folgenden Schritten gezeigt werden, finden Sie unter [PostText](API_runtime_PostText.md). 1. Benutzer: Ich möchte einige Blumen bestellen. 1. Der Client (Konsole) sendet die folgende [PostText](API_runtime_PostText.md)-Anforderung an Amazon Lex: ``` POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "I would like to order some flowers", "sessionAttributes": {} } ``` Sowohl die Anforderungs-URI als auch der Text stellen Amazon Lex Informationen zur Verfügung: + Anfrage-URI — Stellt den Bot-Namen (`OrderFlowers`), den Bot-Alias (`$LATEST`) und den Benutzernamen (eine zufällige Zeichenfolge zur Identifizierung des Benutzers) bereit. Der abschließende `text` zeigt an, dass es sich um eine `PostText`-API-Anforderung handelt (und nicht um `PostContent`). + Anforderungsinhalt: Enthält die Benutzereingabe (`inputText`) und leere `sessionAttributes`. Wenn der Client die erste Anforderung stellt, gibt es keine Sitzungsattribute. Die Lambda-Funktion initiiert sie später. 1. Anhand `inputText` von erkennt Amazon Lex die Absicht (`OrderFlowers`). Diese Absicht ist mit einer Lambda-Funktion als Code-Hook für die Initialisierung und Validierung von Benutzerdaten konfiguriert. Daher ruft Amazon Lex diese Lambda-Funktion auf, indem es die folgenden Informationen als Ereignisdaten weitergibt: ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": {}, "bot": { "name": "OrderFlowers", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": null, "FlowerType": null, "PickupDate": null }, "confirmationStatus": "None" } } ``` Weitere Informationen finden Sie unter [Eingabe-Ereignis-Format](lambda-input-response-format.md#using-lambda-input-event-format). Zusätzlich zu den Informationen, die der Kunde gesendet hat, enthält Amazon Lex auch die folgenden zusätzlichen Daten: + `messageVersion`— Derzeit unterstützt Amazon Lex nur die Version 1.0. + `invocationSource`— Zeigt den Zweck des Aufrufs der Lambda-Funktion an. In diesem Fall ist es die Durchführung der Initialisierung und Validierung von Benutzerdaten. Derzeit weiß Amazon Lex, dass der Benutzer nicht alle Slot-Daten bereitgestellt hat, um die Absicht zu erfüllen. + `currentIntent`-Daten, wobei alle Slot-Werte auf Null gesetzt sind. 1. Zu diesem Zeitpunkt sind alle Slot-Werte auf Null gesetzt. Die Lambda-Funktion muss nichts validieren. Die Lambda-Funktion gibt die folgende Antwort an Amazon Lex zurück: ``` { "sessionAttributes": {}, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": null, "PickupDate": null } } } ``` Weitere Informationen über das Antwortformat finden Sie unter [Reaktion-Format](lambda-input-response-format.md#using-lambda-response-format). Beachten Sie Folgendes: + `dialogAction.type`— Wenn Sie diesen Wert auf setzen`Delegate`, delegiert die Lambda-Funktion die Verantwortung für die Entscheidung über die nächste Vorgehensweise an Amazon Lex. **Anmerkung** Wenn die Lambda-Funktion etwas in der Benutzerdatenvalidierung erkennt, weist sie Amazon Lex an, was als Nächstes zu tun ist, wie in den nächsten Schritten gezeigt. 1. Laut dem `dialogAction.type` entscheidet Amazon Lex über die nächste Vorgehensweise. Da keiner der Slots ausgefüllt ist, entscheidet es, den Wert für den Slot `FlowerType` zu erfragen. Es wählt auch eine der Aufforderungen zur Angabe von Werten für diesen Slot aus ("Welche Art Blumen möchten Sie bestellen?") und sendet dann die folgende Antwort an den Client zurück: ![\[\]](http://docs.aws.amazon.com/de_de/lex/latest/dg/images/gs-1-details-10.png) Der Client zeigt die Mitteilung in der Antwort an. 1. Benutzer: Rosen 1. Der Client sendet die folgende [PostText](API_runtime_PostText.md) Anfrage an Amazon Lex: ``` POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "roses", "sessionAttributes": {} } ``` Im Anforderungstext liefert der `inputText` die Benutzereingabe. Die `sessionAttributes` bleiben leer. 1. Amazon Lex interpretiert das zunächst `inputText` im Kontext der aktuellen Absicht. Der Service "erinnert sich" daran, den spezifischen Benutzer nach Informationen über den Slot `FlowerType` gefragt zu haben. Es aktualisiert den Slot-Wert in der aktuellen Absicht und ruft die Lambda-Funktion mit den folgenden Ereignisdaten auf: ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": {}, "bot": { "name": "OrderFlowers", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": null }, "confirmationStatus": "None" } } ``` Beachten Sie Folgendes: + `invocationSource`: Ist immer noch `DialogCodeHook` (wir validieren einfach Benutzerdaten). + `currentIntent.slots`— Amazon Lex hat den `FlowerType` Slot auf Rosen aktualisiert. 1. Je nach `invocationSource` Wert von `DialogCodeHook` führt die Lambda-Funktion eine Benutzerdatenvalidierung durch. Es wird `roses` als gültiger Slot-Wert erkannt (und `Price` als Sitzungsattribut festgelegt) und gibt die folgende Antwort an Amazon Lex zurück. ``` { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": null } } } ``` Beachten Sie Folgendes: + `sessionAttributes`— Die Lambda-Funktion hat `Price` (von den Rosen) als Sitzungsattribut hinzugefügt. + `dialogAction.type`: Wird auf `Delegate` gesetzt. Die Benutzerdaten waren gültig, sodass die Lambda-Funktion Amazon Lex anweist, die nächste Vorgehensweise zu wählen.   1. Laut dem `dialogAction.type` wählt Amazon Lex die nächste Vorgehensweise. Amazon Lex weiß, dass mehr Steckplatzdaten benötigt werden, und wählt daher den nächsten unbesetzten Steckplatz (`PickupDate`) mit der höchsten Priorität entsprechend der Absichtskonfiguration aus. Amazon Lex wählt eine der Eingabeaufforderungen zur Wertermittlung aus: „An welchem Tag sollen die Rosen abgeholt werden?“ — für diesen Slot entsprechend der Intent-Konfiguration und sendet dann die folgende Antwort zurück an den Client: ![\[\]](http://docs.aws.amazon.com/de_de/lex/latest/dg/images/gs-1-details-20.png) Der Client zeigt einfach die Mitteilung in der Antwort an: "An welchem Tag möchten Sie die Rosen abholen?" 1. Benutzer: morgen 1. Der Client sendet die folgende [PostText](API_runtime_PostText.md) Anfrage an Amazon Lex: ``` POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "tomorrow", "sessionAttributes": { "Price": "25" } } ``` Im Anforderungstext liefert `inputText` die Benutzereingabe und der Client gibt die Sitzungsattribute an den Service zurück. 1. Amazon Lex erinnert sich an den Kontext — dass es Daten für den Slot abgerufen hat. `PickupDate` In diesem Kontext weiß es, dass der Wert `inputText` für den Slot `PickupDate` ist. Amazon Lex ruft dann die Lambda-Funktion auf, indem es das folgende Ereignis sendet: ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": { "Price": "25" }, "bot": { "name": "OrderFlowersCustomWithRespCard", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": "2017-01-05" }, "confirmationStatus": "None" } } ``` Amazon Lex hat das aktualisiert, `currentIntent.slots` indem es den `PickupDate` Wert festgelegt hat. Beachten Sie auch, dass der Dienst das `sessionAttributes` unverändert an die Lambda-Funktion weitergibt. 1. Gemäß dem `invocationSource` Wert von `DialogCodeHook` führt die Lambda-Funktion eine Benutzerdatenvalidierung durch. Es erkennt, dass der `PickupDate` Slot-Wert gültig ist, und gibt die folgende Antwort an Amazon Lex zurück: ``` { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": null, "FlowerType": "roses", "PickupDate": "2017-01-05" } } } ``` Beachten Sie Folgendes: + `sessionAttributes`: Keine Änderung. + `dialogAction.type`: Wird auf `Delegate` gesetzt. Die Benutzerdaten waren gültig, und die Lambda-Funktion weist Amazon Lex an, die nächste Vorgehensweise zu wählen. 1. Laut dem `dialogAction.type` wählt Amazon Lex die nächste Vorgehensweise. Amazon Lex weiß, dass mehr Steckplatzdaten benötigt werden, und wählt daher den nächsten unbesetzten Steckplatz (`PickupTime`) mit der höchsten Priorität entsprechend der Absichtskonfiguration aus. Amazon Lex wählt eine der Aufforderungsnachrichten aus („Um welche Uhrzeit am 05.01.2017 sollen die Rosen geliefert werden?“) für diesen Slot entsprechend der Intent-Konfiguration und sendet die folgende Antwort zurück an den Client: ![\[\]](http://docs.aws.amazon.com/de_de/lex/latest/dg/images/gs-1-details-30.png) Der Client zeigt in der Antwort die folgende Meldung an: „Um welche Uhrzeit sollen die Rosen am 05.01.2017 geliefert werden?“ 1. Benutzer: 16 Uhr 1. Der Client sendet die folgende [PostText](API_runtime_PostText.md) Anfrage an Amazon Lex: ``` POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "4 pm", "sessionAttributes": { "Price": "25" } } ``` Im Anforderungstext liefert der `inputText` die Benutzereingabe. Der Client übergibt die `sessionAttributes` in der Anforderung. 1. Amazon Lex versteht den Kontext. Es versteht, dass es Daten für den Slot `PickupTime` erfragt hat. In diesem Zusammenhang weiß es, dass der `inputText` Wert für den `PickupTime` Slot gilt. Amazon Lex ruft dann die Lambda-Funktion auf, indem es das folgende Ereignis sendet: ``` { "messageVersion": "1.0", "invocationSource": "DialogCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": { "Price": "25" }, "bot": { "name": "OrderFlowersCustomWithRespCard", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" }, "confirmationStatus": "None" } } ``` Amazon Lex hat das aktualisiert, `currentIntent.slots` indem es den `PickupTime` Wert festgelegt hat. 1. Je nach `invocationSource` Wert von `DialogCodeHook` führt die Lambda-Funktion eine Benutzerdatenvalidierung durch. Es erkennt, dass der `PickupDate` Slot-Wert gültig ist, und gibt die folgende Antwort an Amazon Lex zurück. ``` { "sessionAttributes": { "Price": 25 }, "dialogAction": { "type": "Delegate", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" } } } ``` Beachten Sie Folgendes: + `sessionAttributes`: Keine Änderung am Sitzungsattribut. + `dialogAction.type`: Wird auf `Delegate` gesetzt. Die Benutzerdaten waren gültig, sodass die Lambda-Funktion Amazon Lex anweist, die nächste Vorgehensweise zu wählen. 1. Derzeit weiß Amazon Lex, dass es über alle Slot-Daten verfügt. Diese Absicht wurde mit einer Bestätigungsaufforderung konfiguriert. Daher sendet Amazon Lex die folgende Antwort an den Benutzer mit der Bitte um Bestätigung, bevor die Absicht erfüllt wird: ![\[\]](http://docs.aws.amazon.com/de_de/lex/latest/dg/images/gs-1-details-45.png) Der Client zeigt einfach die Mitteilung in der Antwort an und wartet auf die Antwort des Benutzers. 1. Benutzer: Ja 1. Der Client sendet die folgende [PostText](API_runtime_PostText.md) Anfrage an Amazon Lex: ``` POST /bot/OrderFlowers/alias/$LATEST/user/ignw84y6seypre4xly5rimopuri2xwnd/text "Content-Type":"application/json" "Content-Encoding":"amz-1.0" { "inputText": "yes", "sessionAttributes": { "Price": "25" } } ``` 1. Amazon Lex interpretiert das `inputText` im Zusammenhang mit der Bestätigung der aktuellen Absicht. Amazon Lex geht davon aus, dass der Benutzer mit der Bestellung fortfahren möchte. Diesmal ruft Amazon Lex die Lambda-Funktion auf, um die Absicht zu erfüllen, indem das folgende Ereignis gesendet wird, das `FulfillmentCodeHook` in dem Ereignis, das `invocationSource` an die Lambda-Funktion gesendet wird, auf setzt. Amazon Lex legt auch das `confirmationStatus` auf fest`Confirmed`. ``` { "messageVersion": "1.0", "invocationSource": "FulfillmentCodeHook", "userId": "ignw84y6seypre4xly5rimopuri2xwnd", "sessionAttributes": { "Price": "25" }, "bot": { "name": "OrderFlowersCustomWithRespCard", "alias": null, "version": "$LATEST" }, "outputDialogMode": "Text", "currentIntent": { "name": "OrderFlowers", "slots": { "PickupTime": "16:00", "FlowerType": "roses", "PickupDate": "2017-01-05" }, "confirmationStatus": "Confirmed" } } ``` Beachten Sie Folgendes: + `invocationSource`— Diesmal hat Amazon Lex diesen Wert auf gesetzt und die Lambda-Funktion angewiesen`FulfillmentCodeHook`, die Absicht zu erfüllen. + `confirmationStatus`: Wird auf `Confirmed` gesetzt. 1. Diesmal erfüllt die Lambda-Funktion die `OrderFlowers` Absicht und gibt die folgende Antwort zurück: ``` { "sessionAttributes": { "Price": "25" }, "dialogAction": { "type": "Close", "fulfillmentState": "Fulfilled", "message": { "contentType": "PlainText", "content": "Thanks, your order for roses has been placed and will be ready for pickup by 16:00 on 2017-01-05" } } } ``` Beachten Sie Folgendes: + Legt fest `dialogAction.type` — Die Lambda-Funktion setzt diesen Wert auf und weist Amazon Lex an`Close`, keine Benutzerantwort zu erwarten. + `dialogAction.fulfillmentState`: ist auf Fulfilled eingestellt und enthält eine geeignete `message` zur Übermittlung an den Benutzer. 1. Amazon Lex überprüft das `fulfillmentState` und sendet die folgende Antwort an den Kunden zurück. Amazon Lex gibt dann Folgendes an den Client zurück: ![\[\]](http://docs.aws.amazon.com/de_de/lex/latest/dg/images/gs-1-details-48.png) Beachten Sie Folgendes: + `dialogState`— Amazon Lex legt diesen Wert auf fest`fulfilled`. + `message`— ist dieselbe Nachricht, die die Lambda-Funktion bereitgestellt hat. Der Client zeigt die Mitteilung an. 1. Testen Sie nun den Bot erneut. Um einen neuen (Benutzer-)Kontext zu etablieren, wählen Sie den Link **Clear** im Testfenster aus. Geben Sie jetzt ungültige Slot-Daten für die Absicht `OrderFlowers` an. Diesmal führt die Lambda-Funktion die Datenvalidierung durch, setzt den ungültigen Slot-Datenwert auf Null zurück und fordert Amazon Lex auf, den Benutzer zur Eingabe gültiger Daten aufzufordern. Versuchen Sie zum Beispiel Folgendes: + Jasmin als Blumenart (zählt nicht zu den unterstützten Blumenarten) + Gestern als den Tag, an dem Sie die Blumen abholen möchten + Nachdem Sie Ihre Bestellung aufgegeben haben, geben Sie eine andere Blumensorte ein, statt zur Bestätigung der Bestellung mit "Ja" zu antworten. Als Reaktion darauf aktualisiert die Lambda-Funktion das Attribut `Price` in der Sitzung und behält so die laufende Gesamtzahl der Blumenbestellungen bei. Die Lambda-Funktion führt auch die Fulfillment-Aktivität durch. **Nächster Schritt** [Schritt 6: Aktualisieren der Absichtskonfiguration zum Hinzufügen einer Äußerung (Konsole)](gs-bp-utterance.md)