הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
המדיניות ParseDialogflowRequest מאפשרת לשלב את Dialogflow עם Apigee. מידע נוסף זמין במאמר שילוב של Apigee עם Contact Center AI.
המדיניות הזו היא מדיניות שניתנת להרחבה, והשימוש בה עשוי להשפיע על העלויות או על הניצול, בהתאם לרישיון שלכם ל-Apigee. למידע על סוגי מדיניות והשלכות השימוש, אפשר לעיין במאמר בנושא סוגי מדיניות.
המדיניות ParseDialogflowRequest מעבדת את WebhookRequest מסוכן Dialogflow לפני שליחת נתוני הבקשה למערכות העורפיות שלכם. המדיניות מחלצת נתונים מ-WebhookRequest לתוך משתני התהליך שזמינים לכם למשך כל הקריאה ל-API. אפשר להשתמש במשתנים ב-callout, בחיפושים או בלוגיקה המאורגנת הבאים. המדיניות הזו שימושית במיוחד אם רוצים שהסוכן של Dialogflow יקיים אינטראקציה עם מערכות קצה עורפיות מדור קודם. לפני ששולחים את הנתונים של הסוכן למערכות העורפיות, אפשר לנתח את הנתונים ולבנות אותם בצורה שהמערכות העורפיות יכולות לעבד.
אם אתם משלבים שירותים עורפיים, אתם לא צריכים להשקיע זמן בהבנת הפורמט של Dialogflow WebhookRequest. המדיניות ParseDialogflowRequest שמוכנה לשימוש מטפלת בעיבוד של נתוני הבקשה בצורה חלקה.
כדי לגשת אל WebhookRequest של סוכן Dialogflow ב-Apigee, צריך להגדיר את webhook URL (מילוי הבקשה) של הסוכן ל-ProxyEndpoint שהגדרתם ב-Apigee. ה-ProxyEndpoint צריך להיות נגיש לכולם. מידע נוסף מופיע במאמר בנושא דרישות של שירות webhook.
<ParseDialogflowRequest>
הגדרת מדיניות ParseDialogflowRequest.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | חובה |
| סוג | אובייקט מורכב |
| רכיב אב | לא רלוונטי |
| רכיבי צאצא |
<DialogflowVersion><DisplayName><VariablePrefix> |
בטבלה הבאה מפורט תיאור כללי של רכיבי המשנה שספציפיים למדיניות ParseDialogflowRequest:
| רכיב צאצא | חובה? | תיאור |
|---|---|---|
<VariablePrefix> |
אופציונלי | מציין קידומת מותאמת אישית למשתני הזרימה. |
<DialogflowVersion> |
אופציונלי | מציינת את הגרסה של Dialogflow. |
דוגמה
בדוגמה הבאה מוצגת בקשת webhook לדוגמה, מדיניות ParseDialogflowRequest תואמת ומשתני הזרימה שנוצרו אחרי החלת המדיניות:
תחביר
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ParseDialogflowRequest continueOnError="false" enabled="true" name="POLICY_NAME"> <!-- The display name for this policy --> <DisplayName>DISPLAY_NAME</DisplayName> <!-- The optional prefix to be added to all variables created from the Dialogflow Webhook request. Note that all variables created from the WebhookRequest object will be within a container named "google.dialogflow" --> <VariablePrefix>CUSTOM_PREFIX</VariablePrefix> <!-- The version of Dialogflow for which this request policy is written up. This policy supports only the CX version. This element is optional and defaults to CX if unspecified --> <DialogflowVersion>DIALOGFLOW_VERSION</DialogflowVersion> </ParseDialogflowRequest>
בקשת webhook
בדוגמה הבאה מוצגת בקשת ה-webhook (בפורמט JSON) מסוכן Dialogflow.
{
"fulfillmentInfo": {
"tag": "check-claim-status"
},
"sessionInfo": {
"session": "projects/apigee-test/locations/global/agents/ea45003d-3f5c-46ba-ac6b-f4c6dc8db707/sessions/5ea2e8-7c1-cf4-2cf-8e4d89e72",
"parameters": {
"claimId": "1234",
"policyId": "abcd"
}
},
"sentimentAnalysisResult": {
"score": -0.7,
"magnitude": 0.7
}
}כדי לראות את השדות השונים שאפשר להגדיר בבקשה, אפשר לעיין ב- WebhookRequest.
בדוגמה הבאה מוסבר איך מגדירים את המדיניות ParseDialogflowRequest.
מדיניות ParseDialogflowRequest
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ParseDialogflowRequest continueOnError="false" enabled="true" name="DialogflowRequest-InsuranceAgent"> <DisplayName>Insurance Agent Webhook Request Policy</DisplayName> <VariablePrefix>my-prefix</VariablePrefix> <DialogflowVersion>CX</DialogflowVersion> </ParseDialogflowRequest>
בדוגמה הבאה אפשר לראות את משתני הזרימה שנוצרו על ידי המדיניות.
משתנים בתהליך
google.dialogflow.my-prefix.fulfillment.tag = "check-claim-status" google.dialogflow.my-prefix.session.id = "5ea2e8-7c1-cf4-2cf-8e4d89e72" google.dialogflow.my-prefix.session.project.id = "apigee-test" google.dialogflow.my-prefix.session.agent.id = "ea45003d-3f5c-46ba-ac6b-f4c6dc8db707" google.dialogflow.my-prefix.session.parameters.claimId = "1234" google.dialogflow.my-prefix.session.parameters.policyId = "abcd" google.dialogflow.my-prefix.sentimentAnalysisResultScore = -0.7 google.dialogflow.my-prefix.sentimentAnalysisResultMagnitude = 0.7
כל משתני הזרימה שנוצרו מתחילים ב-google.dialogflow ואחריהם התחילית (my-prefix) כפי שצוין באלמנט <VariablePrefix>.
לרכיב הזה יש את המאפיינים הבאים שמשותפים לכל המדיניות:
| מאפיין | ברירת מחדל | חובה? | תיאור |
|---|---|---|---|
name |
לא רלוונטי | חובה |
השם הפנימי של המדיניות. הערך של מאפיין אפשר להשתמש ברכיב |
continueOnError |
FALSE | אופציונלי | מגדירים את הערך false כדי להחזיר שגיאה אם המדיניות נכשלת. זו התנהגות צפויה ברוב המקרים. הגדרה ל-true מאפשרת להמשיך את הביצוע של התהליך גם אחרי שמדיניות נכשלת. מאמרים קשורים:
|
enabled |
TRUE | אופציונלי | מגדירים את הערך true כדי לאכוף את המדיניות, או את הערך false כדי להשבית את המדיניות. המדיניות לא נאכפת גם אם היא עדיין משויכת לזרימה. |
async |
FALSE | הוצא משימוש | המאפיין הזה הוצא משימוש. |
הפניה לרכיב צאצא
בקטע הזה מתוארים רכיבי הבן של<ParseDialogflowRequest>.
<DisplayName>
אפשר להשתמש במאפיין הזה בנוסף למאפיין name כדי לתת למדיניות שם אחר, שנשמע יותר טבעי, ב-UI של עורך ה-proxy לניהול.
הרכיב <DisplayName> משותף לכל סוגי המדיניות.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | זה שינוי אופציונלי. אם לא מציינים את <DisplayName>, המערכת משתמשת בערך של מאפיין name של המדיניות. |
| סוג | String |
| רכיב אב | <PolicyElement> |
| רכיבי צאצא | ללא |
רכיב <DisplayName> משתמש בתחביר הבא:
תחביר
<PolicyElement> <DisplayName>POLICY_DISPLAY_NAME</DisplayName> ... </PolicyElement>
דוגמה
<PolicyElement> <DisplayName>My Validation Policy</DisplayName> </PolicyElement>
לרכיב <DisplayName> אין מאפיינים או רכיבי צאצא.
<VariablePrefix>
מציינים קידומת מותאמת אישית למשתני התהליך. הקידומת שמוגדרת ברכיב הזה מתווספת לכל שמות המשתנים שנוצרים על ידי מדיניות ParseDialogflowRequest. כברירת מחדל, הקידומת google.dialogflow מתווספת לכל המשתנים שנוצרים על ידי המדיניות. אם הגדרתם את הרכיב VariablePrefix, הקידומת המותאמת אישית שלכם מתווספת אחרי google.dialogflow. לכן, שם המשתנה מתחיל ב-google.dialogflow.CUSTOM_PREFIX.
אם לא מציינים את הרכיב VariablePrefix, שם המשתנה יתחיל רק ב-google.dialogflow.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | אופציונלי |
| סוג | String |
| רכיב אב |
<ParseDialogflowRequest>
|
| רכיבי צאצא | ללא |
<VariablePrefix> משתמש בתחביר הבא:
תחביר
<VariablePrefix>VARIABLE_PREFIX</VariablePrefix>
דוגמה
בדוגמה הבאה, הערך של VariablePrefix מוגדר ל-my-prefix:
<VariablePrefix>my-custom-prefix</VariablePrefix>
בהתאם להגדרה הזו, כל שמות המשתנים מתחילים ב-google.dialogflow.my-custom-prefix.
<DialogflowVersion>
מציינת את הגרסה של Dialogflow. המדיניות ParseDialogflowRequest תומכת רק בגרסה CX. אם לא מציינים את הרכיב הזה במדיניות, ברירת המחדל של הגרסה היא CX.
| ערך ברירת המחדל | לא רלוונטי |
| חובה? | אופציונלי |
| סוג | String |
| רכיב אב | לא רלוונטי |
| רכיבי צאצא | ללא |
<DialogflowVersion> משתמש בתחביר הבא:
תחביר
<DialogflowVersion>DIALOGFLOW_VERSION</DialogflowVersion>
דוגמה
בדוגמה הבאה, הערך של DialogflowVersion מוגדר ל-CX:
<DialogflowVersion>CX</DialogflowVersion>
קודי שגיאה
בקטע הזה מתוארים קודי התקלה והודעות השגיאה שמוחזרים, ומשתני התקלה שמוגדרים על ידי Apigee כשמדיניות כזו מפעילה שגיאה. חשוב לדעת את המידע הזה אם אתם מפתחים כללי תקלות לטיפול בתקלות. מידע נוסף על שגיאות שקשורות למדיניות ועל טיפול בשגיאות
שגיאות זמן ריצה
השגיאות האלה יכולות להתרחש כשהמדיניות מופעלת.
| קוד תקלה | סטטוס HTTP | מטרה | תיקון |
|---|---|---|---|
steps.parsedialogflowrequest.InvalidSessionInfo |
500 |
השגיאה הזו מתרחשת אם יש שדה sessionInfo.session לא תקין בבקשת Dialogflow. תגובה לפעולה מאתר אחר (webhook) יכולה להשתמש בשדה הזה כדי לזהות סשן. מידע על פורמט הסשן הנתמך זמין במאמר Class SessionInfo. | |
steps.parsedialogflowrequest.MalformedInput |
500 |
השגיאה הזו מתרחשת כשקובץ ה-JSON שסופק למדיניות הזו לא תקין או שהפורמט שלו שגוי. |
שגיאות בהטמעה
השגיאות האלה יכולות להתרחש כשפורסים שרת proxy שמכיל את המדיניות הזו.
| שם השגיאה | מטרה | תיקון |
|---|---|---|
UnsupportedOperation |
השגיאה הזו מתרחשת אם ציינתם גרסה לא נתמכת של Dialogflow ברכיב DialogflowVersion. המדיניות ParseDialogflowRequest תומכת רק בגרסה CX. |
משתני תקלות
בכל פעם שמתרחשות שגיאות בהרצת מדיניות, מערכת Apigee יוצרת הודעות שגיאה. אפשר לראות את הודעות השגיאה האלה בתגובת השגיאה. לפעמים, הודעות שגיאה שנוצרות על ידי המערכת לא רלוונטיות בהקשר של המוצר שלכם. כדאי להתאים אישית את הודעות השגיאה בהתאם לסוג השגיאה, כדי שההודעות יהיו משמעותיות יותר.
כדי להתאים אישית את הודעות השגיאה, אפשר להשתמש בכללי תקלות או במדיניות RaiseFault. מידע על ההבדלים בין כללי תקלות לבין מדיניות RaiseFault זמין במאמר FaultRules לעומת מדיניות RaiseFault.
צריך לבדוק את התנאים באמצעות הרכיב Condition גם בכללי השגיאה וגם במדיניות RaiseFault.
Apigee מספק משתני שגיאה שייחודיים לכל מדיניות, והערכים של משתני השגיאה מוגדרים כשמדיניות מפעילה שגיאות בזמן ריצה.
באמצעות המשתנים האלה, אפשר לבדוק תנאי שגיאה ספציפיים ולנקוט פעולות מתאימות. מידע נוסף על בדיקת תנאי שגיאה זמין במאמר יצירת תנאים.
בטבלה הבאה מתוארים משתני השגיאה שספציפיים למדיניות הזו.
| משתנים | כאשר: | דוגמה |
|---|---|---|
fault.name="FAULT_NAME" |
FAULT_NAME הוא שם התקלה, כפי שמופיע בטבלה Runtime errors. שם התקלה הוא החלק האחרון של קוד התקלה. | fault.name Matches "UnresolvedVariable" |
ParseDialogflowRequest.POLICY_NAME.failed |
POLICY_NAME הוא השם שהמשתמש הגדיר למדיניות שגרמה לשגיאה. | ParseDialogflowRequest.My-Parse-Dialogflow-Req.failed = true |
נושאים קשורים
הטמעות לדוגמה של פרוקסי Apigee ותהליכים משותפים שמציגים את השימוש במדיניות ParseDialogflowRequest זמינות ב-Apigee GitHub. מידע נוסף זמין במאמר בנושא הטמעות לדוגמה של AI בממשק שיחה.