Dieser Leitfaden enthält verschiedene Beispiele für die Implementierung von Webhooks sowie Empfehlungen zur Fehlerbehebung bei Webhooks.
Sitzungsparameter festlegen
In den folgenden Beispielen wird gezeigt, wie Sie einen Sitzungsparameter festlegen.
Go
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Weitere Informationen finden Sie in der Kurzanleitung zu Webhooks.Java
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Node.js
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Python
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Fulfillment-Antwort zurückgeben
Die folgenden Beispiele zeigen, wie eine Antwort für die Auftragsausführung zurückgegeben wird.
Go
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Weitere Informationen finden Sie in der Kurzanleitung zu Webhooks.Java
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Node.js
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Python
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Formularparameter nach Bedarf festlegen
Die folgenden Beispiele zeigen, wie ein Parameter als erforderlich gekennzeichnet wird.
Java
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Node.js
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Formularparameter validieren
In den folgenden Beispielen wird gezeigt, wie ein Formularparameter validiert wird.
Java
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Node.js
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Python
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Sitzungs-ID protokollieren
Im folgenden Beispiel wird gezeigt, wie die session ID aus einer Webhook-Anfrage protokolliert wird.
Python
Richten Sie zur Authentifizierung bei Dialogflow CX Standardanmeldedaten für Anwendungen ein. Weitere Informationen finden Sie unter Authentifizierung für eine lokale Entwicklungsumgebung einrichten.
Fehlerbehebung
Lebenszyklus eines Webhook-Aufrufs
Webhook-Aufrufe werden immer von Dialogflow CX initiiert und über HTTPS an einen Webserver gesendet. Generische Webdienst-Webhook-Aufrufe stammen von einer Internet-IP-Adresse, die zu Google gehört, und können Webserver (Webhook-Server) erreichen, die im öffentlichen Internet verfügbar sind. Service Directory-Webhooks hingegen beginnen immer mit einer internenGoogle Cloud -Adresse und können nur Webhook-Server in privaten Netzwerken innerhalb von Google Clouderreichen.
Nützliche Logs zum Debuggen von Webhooks
Zum Debuggen von Webhook-Problemen müssen in der Regel die Dialogflow CX-Logs von Cloud Logging und die Webhook-Server-Logs erfasst werden. Wenn der Webhook-Server mit Cloud Run-Funktionen implementiert ist, befinden sich die Logs in Cloud Logging. Andernfalls befinden sich die Logs normalerweise dort, wo der Webhook-Server ausgeführt wird.
Standard-Webhook-Logs enthalten ein detectIntentResponseId-Feld mit einer UUID, die nützlich sein kann, um einen bestimmten Aufruf auf Webhook-Servern zu verfolgen. Dieses Log ist in den Dialogflow CX-Cloud Logging-Logs vorhanden, wenn Cloud Logging aktiviert ist.
Häufige Webhook-Probleme
In den Dialogflow CX-Logs für Webhook-Aufrufe können unter anderem folgende Fehler auftreten:
Fehler bei der Auflösung des Hostnamens des Webhook-Servers
Dialogflow CX hat den Hostnamen eines generischen Webhooks gesucht, der Hostname ist jedoch nicht im DNS vorhanden. Achten Sie darauf, dass der Hostname im öffentlichen DNS registriert ist. Wenn der Hostname neu ist, kann es einige Zeit dauern, bis der Eintrag übernommen wird. Cloud Logging-Nachricht: State: URL_ERROR, Reason: ERROR_DNS.
Der Webhook-Server gibt einen clientseitigen Fehler zurück.
Abgesehen von ERROR_DNS weist dieser Status auf eine 4xx-Antwort vom Webhook-Server hin. Dies kann ein nicht autorisierter Status (401 – ERROR_AUTHENTICATION) sein oder die URL wurde nicht auf dem Webhook-Server gefunden (404 – ERROR_NOT_FOUND).
Cloud Logging-Logeintrag: State: URL_ERROR.
Zeitüberschreitung beim Dialogflow-Agent, bevor der Webhook-Server eine Antwort zurückgibt
Dialogflow CX hat das Webhook-Zeitlimit erreicht, bevor der Webserver fertig war. Hier gibt es zwei Möglichkeiten: Sie können die Verarbeitungszeit des Webhook-Servers reduzieren oder die Zeit erhöhen, die Dialogflow CX auf den Webhook wartet. Die Verarbeitungszeit zu reduzieren, führt in der Regel zu den besten Ergebnissen, ist aber in vielen Fällen nicht einfach. Beachten Sie, dass es ein maximales Zeitlimit für Webhooks gibt und dass Endanrufer oder Nutzer länger auf eine Antwort des Agents warten müssen, bevor Sie diese Einstellung erhöhen. Cloud Logging-Nachricht: State: URL_TIMEOUT, Reason: TIMEOUT_WEB.
gRPC-Zeitüberschreitung, bevor der Webhook-Server eine Antwort zurückgibt
Das von gRPC im Dialogflow CX API-Aufruf festgelegte Zeitlimit wurde erreicht, bevor der Webhook-Aufruf abgeschlossen wurde. Dieses Limit wird normalerweise auf Integrationsebene festgelegt und ist unabhängig von den Dialogflow CX-Parametern und den Webhook-Zeitlimits. Weitere Informationen zu gRPC-Fristen finden Sie unter https://grpc.io/docs/guides/deadlines/.
Cloud Logging-Nachricht: State: URL_REJECTED, Reason: REJECTED_DEADLINE_EXCEEDED.
Dialogflow konnte den Webhook-Server nicht kontaktieren
Der Webhook-Server konnte aufgrund eines Netzwerkfehlers nicht erreicht werden oder die Verbindung wurde hergestellt und der Webhook-Server hat den HTTP-Status 5xx zurückgegeben, was auf ein Problem bei der Verarbeitung der Anfrage hinweist. Achten Sie darauf, dass Dialogflow CX die Webhook-Serveradresse auf Netzwerkebene erreichen kann. Wenn die Anfrage in den Webhook-Server-Logs angezeigt wird, finden Sie heraus, warum der Aufruf einen 5xx-Fehler zurückgegeben hat. Cloud Logging-Nachricht: State: URL_UNREACHABLE.
Webhook-Aufrufe verfolgen
Ein Standard-Webhook-Aufruf kann zwischen Dialogflow CX und einem Webhook-Server mithilfe der Sitzungs-ID, der detectIntentResponse-ID, der Trace-ID für Cloud Run-Funktionen und eines Zeitstempels des Aufrufs korreliert werden. Das flexible Webhook-Tracing kann mithilfe des Zeitstempels des Aufrufs und der Sitzungsparameterwerte erfolgen, die in der Webhook-Definition zur Entwurfszeit angegeben wurden. Weitere Informationen zu Standard- und flexiblen Webhook-Anfragen finden Sie unter Webhooks.
Die Sitzungs-ID wird im Feld sessionInfo.session des WebhookRequest angezeigt.
Diese Sitzungs-ID sollte für jede Unterhaltung eindeutig sein. Sie kann Ihnen helfen, Agentenprotokolle mit Webhook-Protokollen für Anfragen mit derselben Sitzungs-ID zu vergleichen.
Im vorherigen Abschnitt Logsitzungs-ID wird gezeigt, wie die Sitzungs-ID aus einem Webhook protokolliert wird.
Wenn Sie Ihren Webhook in Cloud Run Functions oder einer ähnlichen serverlosen Option von Google Cloud hosten, können Sie das Feld trace aus Logeinträgen als Logfilter verwenden.
Eine einzelne Ausführung einer Funktion führt zu mehreren Logeinträgen mit demselben Trace-Wert.
Im nächsten Beispiel werden sowohl die Sitzungs-ID als auch der Trace-Wert verwendet, um ein bestimmtes Fehlerlog des Dialogflow CX-Agenten mit den entsprechenden Webhook-Logeinträgen der Cloud Run-Funktionen zu verknüpfen. Im Beispiel werden Cloud Logging-Filter für einen Agent verwendet, für den Cloud Logging aktiviert ist.
1. Dialogflow CX-Logs nach den Fehlerlogs eines bestimmten Agents filtern
Verwenden Sie den folgenden Cloud Logging-Filter, um Ihre Dialogflow CX-Logs nach den Fehlerlogs eines bestimmten Agenten zu filtern:
labels.location_id="global"
labels.agent_id="AGENT_ID"
severity=ERROR
Ein Webhook-Logfehlereintrag sieht so aus:
{
"insertId": "-j4gkkre31e2o",
"jsonPayload": {
"code": 14,
"message": "Error calling webhook 'https://us-central1-PROJECT_ID.cloudfunctions.net/function-webhook': State: URL_UNREACHABLE, Reason: UNREACHABLE_5xx, HTTP status code: 500"
},
"labels": {
"agent_id": "e9e01392-1351-42dc-9b15-b583fb2d2881",
"environment_id": "",
"location_id": "global",
"session_id": "07c899-a86-78b-a77-569625b37"
},
"logName": "projects/PROJECT_ID/logs/dialogflow-runtime.googleapis.com%2Frequests",
"receiveTimestamp": "2024-10-28T21:49:04.288439054Z",
"resource": {
"labels": {
"project_id": "PROJECT_ID"
},
"type": "global",
},
"severity": "ERROR",
"timestamp": "2024-10-28T21:49:04.132548Z"
}
Beachten Sie das Feld labels.session_id, das die Sitzungs-ID enthält.
Sie benötigen die Sitzungs-ID im nächsten Schritt.
2. Cloud Run Functions-Logs nach Sitzungs-ID filtern
Verwenden Sie den folgenden Cloud Logging-Filter, um Ihre Cloud Run Functions-Logs nach Sitzungs-ID zu filtern:
resource.type = "cloud_run_revision"
resource.labels.service_name = "CLOUD_RUN_FUNCTION_NAME"
resource.labels.location = "CLOUD_RUN_FUNCTION_REGION"
textPayload="Debug Node: session ID = SESSION_ID"
Die resultierenden Logs entsprechen Webhook-Logs, die während der angegebenen Sitzung erstellt wurden. Beispiel:
{
"insertId": "671c42940007ebebdbb1d56e",
"labels": {
"execution_id": "pgy8jvvblovs",
"goog-managed-by": "cloudfunctions",
"instance_id": "004940b3b8e3d975a4b11a4ed7d1ded4ce3ed37467ffc5e2a8f13a1908db928f8200b01cc554a5eda66ffc9d23d76dd75cec1619a07cb5751fa2e8a93bc6cfc3df86dfa0650a"
},
"logName": "projects/PROJECT_ID/logs/run.googleapis.com%2Fstdout",
"receiveTimestamp": "2024-10-26T01:15:00.523313187Z",
"resource": {
"labels": {
"configuration_name": "function-webhook",
"location": "us-central1",
"project_id": "PROJECT_ID",
"revision_name": "function-webhook-00001-jiv",
"service_name": "function-webhook",
},
"type": "cloud_run_revision"
},
"spanId": "6938366936362981595",
"trace": "d1b54fbc8945dd59bdcaed37d7d5e185",
"textPayload": "Debug Node: session ID = 07c899-a86-78b-a77-569625b37",
"timestamp": "2024-10-26T01:15:00.519147Z"
}
Notieren Sie sich das Feld trace, das im nächsten Schritt verwendet wird.
3. Cloud Functions-Logs für einen bestimmten Trace filtern
Verwenden Sie den folgenden Cloud Logging-Filter, um Cloud Function-Logs für einen bestimmten Trace zu filtern:
resource.type = "cloud_run_revision"
resource.labels.service_name = "CLOUD_RUN_FUNCTION_NAME"
resource.labels.location = "CLOUD_RUN_FUNCTION_REGION"
trace="projects/PROJECT_ID/traces/TRACE_ID"
Dabei ist TRACE_ID das letzte Segment des Trace. Beispielsweise ist die TRACE_ID für projects/PROJECT_ID/traces/e41eefc1fac48665b442bfa400cc2f5e e41eefc1fac48665b442bfa400cc2f5e.
Das Ergebnis ist das Webhook-Serverprotokoll, das während der Ausführung der Webhook-Anfrage generiert wurde, die mit der Sitzungs-ID aus Schritt 1 und dem Trace aus Schritt 2 verknüpft ist. Das Log sieht in etwa so aus:
{
"insertId": "671c42940008465e29f5faf0",
"httpRequest": {
"requestMethod": "POST",
"requestUrl": "https://us-central1-TEST_PROJECT.cloudfunctions.net/function-webhook",
"requestSize": "2410",
"status": 200,
"responseSize": "263",
"userAgent": "Google-Dialogflow",
"remoteIp": "8.34.210.1",
"serverIp": "216.239.36.1",
"latency": "0.166482342s",
"protocol": "HTTP/1.1"
},
"resource": {
"type": "cloud_run_revision",
"labels": {
"project_id": "PROJECT_ID",
"service_name": "function-webhook",
"location": "us-central1",
"revision_name": "function-webhook-00001-jiv",
"configuration_name": "function-webhook"
}
},
"timestamp": "2024-10-26T01:15:00.352197Z",
"severity": "INFO",
"labels": {
"instanceId": "004940b3b813af8a656c92aac1bd07ffad5165f1353e1e346b6161c14bcde225f68f4a88ceedc08aa9020f387b1b59471f73de45f2882a710ced37dea921f05ad962347690be",
"goog-managed-by": "cloudfunctions"
},
"logName": "projects/test-project-12837/logs/run.googleapis.com%2Frequests",
"trace": "projects/test-project-12837/traces/d1b54fbc8945dd59bdcaed37d7d5e185",
"receiveTimestamp": "2024-10-26T01:15:00.548931586Z",
"spanId": "604a07f7b33b18db",
"traceSampled": true
}