| מונח | הגדרה |
|---|---|
| הדרישות מהמטפלים | אלה הדרישות שצריך לעמוד בהן כדי שה-handler ישפיע על הסשן. קריאה ל-handler מתבצעת כשהוא עומד בדרישות שלו ומשפיע על הסשן בדרך כלשהי. |
| מילוי בקשות של Handler | אם מתבצעת קריאה ל-handler, מילוי הבקשה האופציונלי משמש ליצירת תשובות למשתמשי הקצה. התשובות האלה מוגדרות בנתונים הסטטיים של הנציג או מאוחזרות באופן דינמי משירות ה-webhook. |
| יעד המעבר של ה-handler | אם מופעל handler, יעד מעבר אופציונלי משמש לשינוי הדף הנוכחי. הדף הבא יכול להיות רק דף התחלה של תהליך או דף בתהליך הפעיל כרגע. |
יש שני סוגים של פונקציות handler של מצבים, עם דרישות שונות:
| מונח | הגדרה |
|---|---|
| מסלולים | מסלולים נקראים כשקלט של משתמש קצה תואם לכוונה ו/או כשמתקיים תנאי מסוים בסטטוס הסשן. נתיב עם דרישת כוונה נקרא גם נתיב כוונה. נתיב עם דרישת תנאי בלבד נקרא גם נתיב תנאי. |
| גורמים מטפלים באירועים | גורמים מטפלים באירועים נקראים כשמופעל אירוע. אירועים מובנים מסוימים מופעלים כשמתקבל קלט לא צפוי ממשתמש הקצה, או כשמתרחשת שגיאת webhook. אפשר גם להגדיר אירועים בהתאמה אישית שמופעלים כשמשהו קורה מחוץ לשיחה. |
יש שלושה שלבים לעיבוד של handler של מצב:
| מונח | הגדרה |
|---|---|
| 1. היקף | כדי ש-handler ישפיע על הסשן, הוא צריך להיות בהיקף. ההיקף נקבע לפי השאלה אם ה-handler מוחל על תהליך, דף או פרמטר של טופס, ולפי השאלה אם התהליך המשויך פעיל, הדף המשויך פעיל או שהנציג מנסה כרגע למלא את הפרמטר של הטופס המשויך. |
| 2. הערכה | כל handler בהיקף נבדק לפי הסדר. אם הדרישות של ה-handler מתקיימות, הוא עובר את ההערכה. |
| 3. התקשרות | אם ה-handler נמצא בהיקף ועובר את ההערכה, הוא נקרא. כל מילוי בקשה משויך נקרא, וכל יעד מעבר משויך מוחל על הסשן. |
היקף
כדי שה-handler יופעל, הוא צריך להיות בהיקף. היקף ה-handler הוא כלי חשוב ורב-עוצמה שעוזר לכם לשלוט בשיחה. היקף ה-handler מאפשר לכם לקבוע:
| X | פריט |
|---|---|
| כשיש התאמה ל-Intent | |
| מתי צריך לבדוק תנאי | |
| מתי אפשר לטפל באירוע מסוים | |
| מתי יכול להתרחש מעבר בין דפים | |
| כשמתקבלת תשובה סטטית למילוי בקשה | |
| כשמתבצעת קריאה למילוי בקשה עם תמיכה ב-webhook לתשובות דינמיות |
ההיקף נקבע לפי השאלה אם ה-handler מוחל על תהליך, דף או פרמטר של טופס, ולפי השאלה אם התהליך המשויך פעיל, הדף המשויך פעיל או שהנציג מנסה כרגע למלא את הפרמטר המשויך של הטופס.
אלה הכללים המפורטים להגדרת היקף:
- המסלולים שמוגדרים בתהליך הפעיל:
- אם הדף הנוכחי הוא דף ההתחלה של התהליך, הם נמצאים בהיקף.
- אם הדף הנוכחי הוא לא דף ההתחלה של התהליך, הם נכללים בהיקף רק אם יש להם דרישת כוונה.
- המסלולים שחלים על הדף הנוכחי נמצאים בהיקף.
- גורמים מטפלים באירועים שמוחלים על התהליך הפעיל נמצאים בהיקף.
- הגורמים המטפלים באירועים שמוחלים על הדף הנוכחי נמצאים בהיקף.
- גורמים מטפלים באירועים שחלים על פרמטר של טופס שהנציג מנסה למלא כרגע נמצאים בהיקף.
מסלולים
למסלולים יש שתי דרישות, וצריך לספק אחת מהן או את שתיהן. אם שתי הדרישות מסופקות, שתיהן צריכות להתקיים כדי לקרוא לנתיב:
| מונח | הגדרה |
|---|---|
| דרישת Intent | כוונה שצריכה להתאים לקלט של משתמש הקצה בתור הנוכחי בשיחה. כשמסלול כולל דרישה לכוונה, הוא נקרא מסלול כוונה. |
| דרישת התנאי | תנאי שצריך להתקיים. כשבנתיב יש דרישה לתנאי, הוא נקרא נתיב תנאי. |
אפשר להחיל נתיבים על תהליכים (נתיבים ברמת התהליך) ועל דפים (נתיבים ברמת הדף). לדוגמה, אפשר להשתמש בנתיבים במצבים הבאים:
| X | פריט |
|---|---|
| כשקלט של משתמש קצה תואם ל-intent, ההתאמה אמורה להפעיל תגובה של מילוי בקשה סטטי. | |
| כשהקלט של משתמש הקצה תואם ל-intent, ההתאמה צריכה להפעיל מילוי בקשה (fulfillment) עם תמיכה ב-webhook כדי לקבל תשובה דינמית. | |
| כשקלט של משתמש הקצה מספק את הפרמטר האחרון הנדרש בטופס, בדיקת תנאי מפעילה מעבר של הסשן לדף אחר. | |
| כשקלט של משתמש קצה מספק פרמטר טופס ספציפי, בדיקת תנאי מפעילה תגובה של מילוי בקשה סטטי. | |
בדיקת תנאי שמוגדרת לערך true
שמאלצת מעבר דף. |
הפצת כוונה
בדרך כלל, כשמסלול נקרא בגלל כוונה תואמת, הכוונה נצרכת. לא ניתן להתאים שוב כוונה שכבר נעשה בה שימוש, אלא אם קלט חדש של משתמש הקצה מפעיל התאמה של כוונה חדשה. עם זאת, אפשר להפיץ התאמה של כוונה מתהליך אחד לאחר בתרחיש הבא:
- במסלול ב-
flow F1,intent I1הוא דרישה ו-flow F2הוא יעד מעבר. - ל-
Flow F2יש מסלול שגםintent I1נדרש בו.
במקרה הזה, כשמתבצעת קריאה למסלול ב-flow F1,
מתבצעת התאמה של intent I1 פעמיים לקלט יחיד של משתמש קצה,
ושני המסלולים נקראים.
הפצת כוונות שימושית כדי:
| X | פריט |
|---|---|
| שינוי הדף הנוכחי לדף ספציפי בתהליך אחר (המסלול של תהליך היעד למעבר כולל דף יעד ספציפי למעבר). | |
| יצירת הודעת כניסה לדף ההתחלה של תהליך (לנתיב של תהליך היעד של המעבר יש מילוי בקשה). |
קבוצות של מסלולים
כשיוצרים נציג, יכול להיות שתגלו שלדפים רבים יש קבוצה משותפת של נתיבים. כדי להשתמש בנתיבים שוב, אפשר להגדיר קבוצות של נתיבים. אתם יכולים ליצור את המשאבים הקבוצתיים האלה לשימוש חוזר בתוך ה-flow או בכל הנציג.
לדוגמה, יכול להיות שתרצו שהתהליך יטפל בקלט של משתמש הקצה כמו "אני רוצה להוסיף תוספת לפיצה" ו "אני רוצה לשנות את גודל המשקה". צריך לטפל בקלט הזה כשאחד מהדפים הרבים בתהליך פעיל. אפשר להגדיר שני נתיבים עם כוונות כדי לטפל בקלט הזה בכל הדפים הרלוונטיים, אבל זו עבודה כפולה. במקום זאת, אתם יכולים להגדיר את קבוצת המסלולים פעם אחת, ולהוסיף הפניה לקבוצה בכל הדפים הרלוונטיים.
קבוצות של מסלולים ברמת התהליך
קבוצות של נתיבים ברמת התהליך הן משאבים של קבוצות נתיבים שנוצרו עם תהליך כהורה. אפשר להשתמש בהם שוב בתהליך.
קבוצות של נתיבים ברמת הסוכן
קבוצות של נתיבים ברמת הנציג הן משאבים של קבוצות נתיבים שנוצרו עם נציג כהורה. אפשר להשתמש בהם שוב בכל הסוכן, אבל הם לא מאפשרים מסלולים שעוברים לדף לא סימבולי כיעד.
מסלולים ברמת התהליך
נתיבים ברמת התהליך הם נתיבים שמוחלים על תהליך על ידי הוספה שלהם לדף ההתחלה של התהליך. אלה תרחישי השימוש של סוגי ה-handlers האלה:
| X | פריט |
|---|---|
| רכיבי handler עם דרישה ל-intent או לתנאי בהיקף של דף ההתחלה של התהליך. | |
| רכיבי handler עם דרישת Intent בהיקף של כל הדפים בתהליך. |
כדי ליצור נתיבים ברמת התהליך מהמסוף:
- פותחים את דף ההתחלה של התהליך.
- לוחצים על כפתור ההוספה בכותרת Routes.
- חלונית עריכת המסלול נפתחת.
- מציינים את שדות המסלול.
- לוחצים על Save.
כדי לשנות את הסדר של הנתיבים ברמת התהליך מהמסוף:
- פותחים את דף ההתחלה של התהליך.
- לוחצים על הכותרת מסלולים.
- חלונית רשימת המסלולים נפתחת.
- גוררים את המסלולים לפי הסדר הרצוי. אפשר גם ללחוץ על תפריט האפשרויות ואז על העברה אל.
כדי למחוק מסלולים ברמת התהליך מהמסוף:
- פותחים את דף ההתחלה של התהליך.
- לוחצים על הכותרת מסלולים.
- חלונית רשימת המסלולים נפתחת.
- לוחצים על תפריט האפשרויות .
- בוחרים את האפשרות Delete.
נתיבים ברמת הדף
נתיבים ברמת הדף הם נתיבים שמוחלים על דף. אלה תרחישי השימוש של סוגי ה-handlers האלה:
| X | פריט |
|---|---|
| רכיבי handler עם דרישה לכוונה או לתנאי בהיקף שבו דפים ספציפיים פעילים. |
כדי ליצור נתיבים ברמת הדף מהמסוף:
- פותחים את הדף (לא את דף ההתחלה של התהליך).
- לוחצים על כפתור ההוספה בכותרת Routes.
- חלונית עריכת המסלול נפתחת.
- מציינים את שדות המסלול.
- לוחצים על Save.
כדי לשנות את הסדר של הנתיבים ברמת הדף מהמסוף:
- פותחים את הדף (לא את דף ההתחלה של התהליך).
- לוחצים על הכותרת מסלולים.
- חלונית רשימת המסלולים נפתחת.
- גוררים את המסלולים לפי הסדר הרצוי. אפשר גם ללחוץ על תפריט האפשרויות ואז על העברה אל.
כדי למחוק מסלולים ברמת הדף מהמסוף:
- פותחים את הדף (לא את דף ההתחלה של התהליך).
- לוחצים על הכותרת מסלולים.
- חלונית רשימת המסלולים נפתחת.
- לוחצים על תפריט האפשרויות .
- בוחרים את האפשרות Delete.
גורמים מטפלים באירועים
כדי להפעיל גורמים מטפלים באירועים, צריך לעמוד בדרישה אחת:
| מונח | הגדרה |
|---|---|
| דרישות לגבי אירועים | אירוע שצריך להפעיל. האירועים מזוהים לפי השם שלהם. חלק מהאירועים המובנים מופעלים כשמתקבל קלט לא צפוי ממשתמש הקצה, או כשמתרחשת שגיאה ב-webhook. אתם יכולים גם להגדיר אירועים בהתאמה אישית שיופעלו כשמשהו קורה מחוץ לשיחה. |
אפשר להחיל גורמים מטפלים באירועים על תהליכים (גורמים מטפלים באירועים ברמת התהליך), דפים (גורמים מטפלים באירועים ברמת הדף) ופרמטרים (גורמים מטפלים באירועים ברמת הפרמטר). לדוגמה, אתם יכולים להשתמש בגורמים מטפלים באירועים במצבים הבאים:
| X | פריט |
|---|---|
| כשקלט של משתמש קצה לא תואם לאף כוונה, גורם מטפל באירועים ללא התאמה מספק תגובה ספציפית של מילוי בקשה סטטי. | |
| טיימר מסתיים במערכת שלכם, ואתם רוצים להציג למשתמש הקצה מידע על תזכורת באמצעות תגובה ספציפית של מילוי בקשה סטטי. |
גורמים מטפלים באירועים ברמת התהליך
גורמים מטפלים באירועים ברמת התהליך הם גורמים מטפלים באירועים שמוחלים על תהליך. אלה תרחישי השימוש של סוגי ה-handlers האלה:
| X | פריט |
|---|---|
| רכיבי handler עם דרישות לגבי אירועים בהיקף של דף ההתחלה של התהליך. | |
| רכיבי handler עם דרישות לגבי אירועים בהיקף של כל הדפים בתהליך. | |
| טיפול בקלט לא צפוי של משתמשי קצה, שמשותף לכל הדפים בתהליך. | |
| טיפול בשגיאות של תגובות לפעילות אינטראקטיבית (webhook), שמשותפות לכל הדפים בתהליך. | |
| טיפול באירועים בהתאמה אישית שהמערכת שלכם מפעילה, שמשותפים לכל הדפים בתהליך. |
לכל תהליך יש גורמים מטפלים באירועים no-match ו-no-input
מובנים.
הגורמים המטפלים באירועים האלה נוצרים באופן אוטומטי כשיוצרים תהליך, ואי אפשר למחוק אותם.
כדי ליצור גורמים מטפלים באירועים ברמת התהליך מהמסוף:
- פותחים את דף ההתחלה של התהליך.
- לוחצים על כפתור ההוספה בכותרת גורם מטפל באירועים.
- החלונית של הגורם המטפל באירועים נפתחת.
- ממלאים את השדות של הגורם המטפל באירועים.
- לוחצים על Save.
כדי למחוק גורמים מטפלים באירועים ברמת התהליך מהמסוף:
- פותחים את דף ההתחלה של התהליך.
- לוחצים על הכותרת גורמים מטפלים באירועים.
- חלונית הרשימה של הגורמים המטפלים באירועים נפתחת.
- מעבירים את העכבר מעל גורם מטפל באירועים ולוחצים על כפתור המחיקה .
גורמים מטפלים באירועים ברמת הדף
גורמים מטפלים באירועים ברמת הדף הם גורמים מטפלים באירועים שמוחלים על דף. אלה תרחישי השימוש של סוגי ה-handlers האלה:
| X | פריט |
|---|---|
| רכיבי handler עם דרישות לגבי אירועים בהיקף כשדפים ספציפיים פעילים. | |
| טיפול בקלט לא צפוי של משתמש קצה, ספציפי לדף. | |
| טיפול בשגיאות של תגובה לפעולה מאתר אחר (webhook) שספציפיות לדף. | |
| טיפול באירועים מותאמים אישית שהמערכת שלכם מפעילה, ספציפיים לדף. |
כדי ליצור גורמים מטפלים באירועים ברמת הדף מהמסוף:
- פותחים דף (לא את דף ההתחלה של התהליך).
- אם הכותרת גורם מטפל באירועים לא מופיעה, לוחצים על Add state handler, בוחרים באפשרות גורם מטפל באירועים ולוחצים על Apply.
- לוחצים על כפתור ההוספה בכותרת גורם מטפל באירועים.
- החלונית של הגורם המטפל באירועים נפתחת.
- ממלאים את השדות של הגורם המטפל באירועים.
- לוחצים על Save.
כדי למחוק גורמים מטפלים באירועים ברמת הדף מהמסוף:
- פותחים דף (לא את דף ההתחלה של התהליך).
- לוחצים על הכותרת גורמים מטפלים באירועים.
- חלונית הרשימה של הגורמים המטפלים באירועים נפתחת.
- מעבירים את העכבר מעל גורם מטפל באירועים ולוחצים על כפתור המחיקה .
גורמים מטפלים באירועים ברמת הפרמטר
גורמים מטפלים באירועים ברמת הפרמטר הם גורמים מטפלים באירועים שמוחלים על פרמטר של טופס. הם נקראים גם רכיבי handler של בקשות חוזרות. הגורמים המטפלים באירועים האלה לא מאפשרים אירועים בהתאמה אישית, כי הם מיועדים באופן ספציפי לטפל בקלט לא חוקי של משתמשי קצה במהלך מילוי טפסים.
אלה תרחישי השימוש של סוגי ה-handlers האלה:
| X | פריט |
|---|---|
| משתמש הקצה לא סיפק קלט תקין כשהתבקש למלא פרמטר בטופס. |
כדי ליצור גורמים מטפלים באירועים ברמת הפרמטר מהמסוף:
- פותחים דף שמכיל פרמטרים של טופס.
- לוחצים על פרמטר.
- חלונית הפרמטרים תיפתח.
- גוללים למטה לקטע גורמים מטפלים באירועי שאלה חוזרת ולוחצים על הוספת גורם מטפל באירועים.
- החלונית של הגורם המטפל באירועים נפתחת.
- ממלאים את השדות של הגורם המטפל באירועים.
- לוחצים על Save.
כדי למחוק מהמסוף גורמים מטפלים באירועים ברמת הפרמטר:
- פותחים דף שמכיל פרמטרים של טופס.
- לוחצים על פרמטר.
- חלונית הפרמטרים תיפתח.
- גוללים למטה לקטע Reprompt event handlers (גורמים מטפלים באירועים של בקשה חוזרת).
- מעבירים את העכבר מעל גורם מטפל באירועים ולוחצים על כפתור המחיקה .
אירועים מובנים
האירועים הבאים מובנים ומופעלים על ידי Dialogflow CX. חלק מהאירועים מוגבלים לרמות מסוימות.
שם האירוע |
ברמת התהליך | ברמת הדף | ברמת הפרמטר | מופעל כאשר |
|---|---|---|---|---|
sys.no-match-default |
✔ | ✔ | ✔ | |
sys.no-match-[1-6] |
✔ | ✔ | ✔ | אם אתם מספקים פונקציות טיפול לאירועים האלה שממוספרים לפי הסדר, הן מופעלות במקום sys.no-match-default ולפי הסדר: sys.no-match-1, sys.no-match-2, ... |
sys.no-input-default |
✔ | ✔ | ✔ | לא התקבל קלט ממשתמש הקצה. אפשר להפעיל את זה כש:
|
sys.no-input-[1-6] |
✔ | ✔ | ✔ | אם אתם מספקים פונקציות טיפול לאירועים האלה שממוספרים לפי הסדר, הן מופעלות במקום sys.no-input-default ולפי הסדר: sys.no-input-1, sys.no-input-2, ... |
sys.invalid-parameter |
✔ | מופעל כשתגובת webhook מבטלת את הפרמטר על ידי הגדרת WebhookResponse.pageInfo.formInfo.parameterInfo.state ל-INVALID. |
||
sys.long-utterance |
✔ | ✔ | ✔ | הקלט של משתמש הקצה חורג מהאורך המקסימלי המותר (256 תווים) שתואם לכוונות לא גנרטיביות או לפרמטרים. אם לא מציינים את הפרמטר, Dialogflow CX מתייחס לאמירה ארוכה של המשתמש כ-no-match. בקלט של שידור אודיו, האירוע הזה מופעל רק אחרי שהלקוח סוגר את שידור האודיו. |
webhook.error |
✔ | ✔ | הקריאה ל-webhook החזירה שגיאה. האירוע הזה מופעל רק: 1) אם אין גורם מטפל באירועים של webhook ברמת פירוט גבוהה (למשל webhook.error.timeout) שתואם לקוד השגיאה של ה-webhook, 2) אם לא הוגדר יעד מעבר בנתיב המקורי שקרא למילוי הבקשה באמצעות ה-webhook שנכשל. פרטים נוספים זמינים בקטע סדר ההערכה. | |
webhook.error.timeout |
✔ | ✔ | הזמן הקצוב לתפוגה של הקריאה ל-webhook הסתיים. אירוע webhook יופעל רק אם לא הוגדר יעד מעבר בנתיב המקורי שקרא למילוי הבקשה עם ה-webhook שנכשל. פרטים נוספים זמינים בקטע סדר ההערכה. | |
webhook.error.bad-request |
✔ | ✔ | ה-webhook החזיר את השגיאה 400 Bad Request. אירוע webhook יופעל רק אם לא הוגדר יעד מעבר בנתיב המקורי שקרא למילוי הבקשה עם ה-webhook שנכשל. פרטים נוספים זמינים בקטע סדר ההערכה. | |
webhook.error.rejected |
✔ | ✔ | ה-webhook החזיר את השגיאה 401 Unauthorized או 403 Forbidden. אירוע webhook יופעל רק אם לא הוגדר יעד מעבר בנתיב המקורי שקרא למילוי הבקשה עם ה-webhook שנכשל. פרטים נוספים זמינים בקטע סדר ההערכה. | |
webhook.error.unavailable |
✔ | ✔ | ה-webhook החזיר את השגיאה 503 Service Unavailable. אירוע webhook יופעל רק אם לא הוגדר יעד מעבר בנתיב המקורי שקרא למילוי הבקשה עם ה-webhook שנכשל. פרטים נוספים זמינים בקטע סדר ההערכה. | |
webhook.error.not-found |
✔ | ✔ | הקריאה ל-webhook נכשלה כי לא הייתה גישה לכתובת ה-URL של ה-webhook. אירוע webhook יופעל רק אם לא הוגדר יעד מעבר בנתיב המקורי שקרא למילוי הבקשה עם ה-webhook שנכשל. פרטים נוספים זמינים בקטע סדר ההערכה. | |
flow-cancelled |
✔ | ✔ | משתמש הקצה ביקש לבטל את התהליך. האירוע הזה מופעל על ידי הדף "סיום התהליך עם ביטול", ראו END_FLOW_WITH_CANCELLATION יעד המעבר הסמלי. |
|
flow-failed |
✔ | ✔ | התהליך הזה לא הצליח להשלים את המשימה הנתונה. האירוע הזה מופעל על ידי הדף "סיום התהליך עם כשל", ראו את END_FLOW_WITH_FAILURE יעד המעבר הסמלי. |
|
flow-failed-human-escalation |
✔ | ✔ | משתמש הקצה ביקש לדבר עם נציג אנושי. האירוע הזה מופעל על ידי הדף End Flow With Human Escalation, ראו END_FLOW_WITH_HUMAN_ESCALATION יעד המעבר הסמלי. |
אירועים בהתאמה אישית
אפשר ליצור אירועים וגורמים מטפלים באירועים בהתאמה אישית. אירועים בהתאמה אישית משמשים לטיפול בדברים שקורים מחוץ לשיחה עם משתמש הקצה. לדוגמה, משתמש הקצה לחץ על כפתור, עבר פרק זמן מסוים, המלאי הזמין השתנה במהלך השיחה, וכו'.
האירועים מזוהים פשוט לפי השם שלהם.
כדי למנוע התנגשות עם אירועים מובנים, אל תשתמשו בשמות של אירועים שמתחילים ב-sys. או ב-webhook..
כדי להפעיל אירוע באמצעות ה-API, עיינו בשדה queryInput.event של ה-method detectIntent לסוג Session.
בוחרים פרוטוקול וגרסה להפניה לסשן:
| פרוטוקול | V3 | V3beta1 |
|---|---|---|
| REST | משאב הסשן | משאב הסשן |
| RPC | ממשק הסשן | ממשק הסשן |
| C++ | SessionsClient | לא זמין |
| C# | SessionsClient | לא זמין |
| המשך | SessionsClient | לא זמין |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | לא זמין | לא זמין |
| Python | SessionsClient | SessionsClient |
| Ruby | לא זמין | לא זמין |
סדר ההערכה
ה-handlers נבדקים בסדר מסוים. יש להקפיד על כללי האצבע הבאים:
- רק ה-handlers ב-scope נבדקים.
- אפשר להפעיל רק פונקציות handler שהדרישות שלהן מתקיימות.
- אם מתבצעת קריאה ל-handler בלי יעד מעבר, הערכת רשימת ה-handlers נמשכת. בגלל הכלל הזה, כמה מילויים של בקשות יכולים להוסיף כמה הודעות לתור התגובות.
- אם מתבצעת קריאה ל-handler עם יעד מעבר, הערכת רשימת ה-handlers מסתיימת.
- אם מתבצעת קריאה ל-handler עם מילוי בקשה, והמילוי גורם לשגיאת webhook:
- אם ל-handler מוגדר יעד מעבר, ה-webhook נכשל בלי להציג הודעה.
- אם גורם מטפל באירועים נמצא בהיקף של האירוע, הוא מטפל באירוע וההערכה של רשימת הגורמים המטפלים מסתיימת.
- אם אין גורם מטפל באירועים בהיקף של האירוע, ה-webhook נכשל בלי להציג הודעה.
- כשדרישת ה-Intent מתקיימת, ה-Intent נצרך, כך שניתן לקרוא רק ל-route handler הראשון שנמצא עבור ה-Intent (למידע על החריגים, ראו הפצת Intent).
- כשהדרישה של התנאי מתקיימת, התנאי לא נצרך, כך שאפשר לקרוא לכמה נתיבים עם התנאי.
- כשדרישה של אירוע מתקיימת, האירוע נצרך, ולכן אפשר לקרוא רק לגורם המטפל באירועים הראשון שנמצא לאירוע.
- סטאק הביצוע של ה-handler יכול להשפיע על סדר ההערכה.
ההערכה כוללת שלושה שלבים:
- מסלולים שכוללים דרישה ל-Intent נבדקים לפי הסדר הבא:
- ברמת הדף: מסלולים ספציפיים שחלים על הדף הנוכחי, לפי הסדר שבו הם סופקו.
- קבוצות ברמת הדף: קבוצות של נתיבים שחלות על הדף הנוכחי, לפי הסדר שסופק.
- ברמת התהליך: הנתיבים שמוחלים על התהליך הפעיל, לפי הסדר שסופק.
- קבוצות ברמת התהליך: קבוצות של מסלולים שחלות על התהליך הפעיל, לפי הסדר שסופק.
- נתיבים עם דרישת תנאי בלבד נבדקים בסדר הבא:
- ברמת הדף: מסלולים ספציפיים שחלים על הדף הנוכחי, לפי הסדר שבו הם סופקו.
- קבוצות ברמת הדף: קבוצות של נתיבים שחלות על הדף הנוכחי, לפי הסדר שסופק.
- ברמת התהליך (רק אם הדף הנוכחי הוא דף ההתחלה של התהליך): נתיבים שמוחלים על התהליך הפעיל, לפי הסדר שסופק.
- קבוצות ברמת התהליך (רק אם הדף הנוכחי הוא דף ההתחלה של התהליך): קבוצות של נתיבים שחלות על התהליך הפעיל, לפי הסדר שסופק.
- הגורמים המטפלים באירועים נבדקים בסדר הבא:
- ברמת הפרמטר: גורמים מטפלים באירועים שחלים על פרמטר הטופס של הדף הנוכחי שהנציג מנסה למלא כרגע (גורמים מטפלים בבקשות חוזרות), לפי הסדר שסופק.
- ברמת הדף: גורמים מטפלים באירועים שמוחלים על הדף הנוכחי, לפי הסדר שסופק.
- ברמת התהליך: גורמים מטפלים באירועים שחלים על התהליך הפעיל, לפי הסדר שסופק.
יעדי מעבר סמליים
כשמזינים יעד מעבר ל-handler, אפשר להזין תהליכים או דפים ספציפיים, אבל אפשר גם להזין יעדי מעבר סמליים:
יעד מעבר סמלי |
תיאור |
|---|---|
START_PAGE |
מעבר לדף ההתחלה של התהליך הפעיל עם אותו שם. |
END_FLOW |
סיום התהליך הפעיל כרגע ומעבר חזרה לדף שגרם למעבר לתהליך הנוכחי. אפשר גם לעיין במאמר מגבלת סטאק הביצוע וסטאק הזרימה של ה-handler. |
END_FLOW_WITH_CANCELLATION |
סיום התהליך הפעיל כרגע ומעבר חזרה לדף שגרם למעבר לתהליך הנוכחי. הדף שממנו מתבצעת הקריאה יכול לטפל במעבר הזה באמצעות האירוע המובנה flow-cancelled. אפשר גם לעיין בקטע מגבלת סטאק הביצוע וסטאק הזרימה של ה-handler. |
END_FLOW_WITH_FAILURE |
סיום התהליך הפעיל כרגע ומעבר חזרה לדף שגרם למעבר לתהליך הנוכחי. הדף שממנו מתבצעת הקריאה יכול לטפל במעבר הזה באמצעות האירוע המובנה flow-failed. אפשר גם לעיין בקטע מגבלת סטאק הביצוע וסטאק הזרימה של ה-handler. |
END_FLOW_WITH_HUMAN_ESCALATION |
סיום התהליך הפעיל כרגע ומעבר חזרה לדף שגרם למעבר לתהליך הנוכחי. הדף שממנו מתבצעת הקריאה יכול לטפל במעבר הזה באמצעות האירוע המובנה flow-failed-human-escalation. אפשר גם לעיין בקטע מגבלת סטאק הביצוע וסטאק הזרימה של ה-handler. |
END_SESSION |
ניקוי הסשן הנוכחי ומעבר לדף המיוחד שנקרא END_SESSION. הקלט הבא של המשתמש יפעיל מחדש את הסשן בדף ההתחלה של תהליך ההתחלה שמוגדר כברירת מחדל. |
PREVIOUS_PAGE |
מעבר לדף הקודם שגרם למעבר לדף הנוכחי. מצב הדף מהדף הקודם ישוחזר אחרי המעבר. |
CURRENT_PAGE |
מעבר מחדש לדף הנוכחי. זה יכול להיות שימושי אם אתם רוצים שהסוכן יחזור על משהו. |
מגבלת סטאק הביצוע וסטאק התהליך של ה-handler
כשסשן עובר מתהליך לתהליך עם יעדי מעבר ספציפיים, כל תהליך נדחף למחסנית התהליכים.
סטאק ביצוע של ה-handler
כשהסשן עובר למצב END_FLOW,
הוא חוזר לדף שגרם למעבר לתהליך שהושלם.
במצב כזה, סטאק הביצוע של ה-handler נשמר.
המערכת תדלג על כל ה-handlers שכבר נבדקו בדף המקורי, ותבדוק את ה-handlers שנותרו לפי הסדר.
לדוגמה:
- בדף P יש שלושה רכיבי handler בסדר הבא: H1, H2, H3.
- H1 נבדק, אבל לא גורם למעבר.
- H2 נבדק וגורם למעבר ל-flow F.
- דף בתהליך F עובר אל
END_FLOW. - הסשן חוזר לדף P, שהופך שוב לפעיל עם מצב שמור.
- הערכת ה-handler בדף P ממשיכה מהסטטוס שנשמר, ולכן מתבצעת הערכה של H3.
מגבלת המחסנית של התהליך
המגבלה המקסימלית של מחסנית התהליכים היא 25. חריגה מהמגבלה המקסימלית של המחסנית עלולה לגרום להסרת תהליכים מהמחסנית, מה שיוביל להתנהגות בלתי צפויה בזמן השימוש במעבר END_FLOW.
כדי למנוע את הבעיות האלה, כדאי לצמצם את מספר המעברים בין תהליכים לפני המעבר אל END_FLOW.
אם מחסנית התהליכים ריקה, המעבר END_FLOW מסיים את הסשן.
הגדרת תנאים
כדי להגדיר תנאים באמצעות המסוף, צריך לספק כללי תנאים עם אחת משלוש אפשרויות לוגיות:
- התאמה של כלל אחד לפחות (או)
- התאמה לכל הכללים (וגם)
- התאמה אישית של הבעת הפנים
כדי להקל עליכם, אתם יכולים להשתמש באפשרויות AND/OR כדי ליצור תנאים פשוטים או מורכבים לערכי פרמטרים.
אפשר להשתמש באפשרות Customize expression לכל סוגי התנאים, כולל פונקציות מערכת וקבועים בוליאניים.
לדוגמה, כדי להגדיר תנאי שיש לו סיכוי של 10% לעבור את ההערכה, בוחרים באפשרות התאמה אישית של הביטוי ומזינים $sys.func.rand() < 0.1 בשדה תנאי:
