מעבדי מצב

רכיבי State handlers, שנקראים גם handlers, משמשים לשליטה בשיחה על ידי יצירת תשובות למשתמשי הקצה או על ידי מעבר לדף הנוכחי. בכל תור בשיחה, המערכת מעריכה את ה-handlers, והם עשויים להשפיע על הסשן. יש שלושה סוגים כלליים של נתונים במטפלים:

מונח הגדרה
דרישות לגבי המטפל אלה הדרישות שצריך לעמוד בהן כדי שה-handler ישפיע על הסשן. אומרים ש-handler מופעל כשהוא עומד בדרישות שלו ומשפיע על הסשן בצורה כלשהי.
מילוי הזמנות על ידי מטפל אם מופעל handler, נעשה שימוש בfulfillment אופציונלי כדי ליצור תשובות למשתמשי הקצה. התשובות האלה מוגדרות בנתונים סטטיים של הסוכן או מאוחזרות באופן דינמי משירות ה-webhook שלכם.
יעד מעבר של רכיב Handler אם מפעילים handler, משתמשים ביעד מעבר אופציונלי כדי לשנות את הדף הנוכחי. הדף הבא יכול להיות רק דף התחלה של תהליך או דף בתהליך הפעיל הנוכחי.

יש שני סוגים של רכיבי handler של מצב עם דרישות שונות:

מונח הגדרה
מסלולים מסלולים מופעלים כשקלט של משתמש קצה תואם לכוונה או כשמתקיים תנאי מסוים בסטטוס הסשן. מסלול עם דרישה לכוונת המשתמש נקרא גם מסלול לכוונת המשתמש. נתיב עם דרישת תנאי בלבד נקרא גם נתיב תנאי.
גורמים מטפלים באירועים גורמים מטפלים באירועים נקראים כשמופעל אירוע. חלק מהאירועים המובנים מופעלים כשמתקבל קלט לא צפוי ממשתמש הקצה, או כשמתרחשת שגיאת webhook. אפשר גם להגדיר אירועים מותאמים אישית שמופעלים כשקורה משהו מחוץ לשיחה.

תהליך העיבוד של רכיב לניהול מצב כולל שלושה שלבים:

מונח הגדרה
1. היקף כדי שה-handler ישפיע על הסשן, הוא צריך להיות בהיקף. ההיקף נקבע לפי האופן שבו מוחל handler על זרימה, על דף או על פרמטר של טופס, ולפי המצב של הזרימה המשויכת (פעילה או לא), של הדף המשויך (פעיל או לא) או של הסוכן (מנסה כרגע למלא את הפרמטר המשויך של הטופס).
2. הערכה כל רכיב handler בהיקף נבדק לפי הסדר. אם הדרישות של אמצעי הטיפול מתקיימות, הוא עובר את ההערכה.
3. התקשרות אם handler נמצא בהיקף ועובר את ההערכה, הוא נקרא. כל פעולת מילוי משויכת מופעלת, וכל יעד מעבר משויך מוחל על הסשן.

היקף

כדי שמטפל ינותח, הוא צריך להיות בטווח. היקף הטיפול הוא כלי חשוב ועוצמתי שעוזר לכם לשלוט בשיחה. כששולטים בהיקף של רכיב handler, אפשר לשלוט ב:

X פריט
מתי אפשר להתאים כוונה
מתי צריך לבדוק תנאי
מתי אפשר לטפל באירוע מסוים
מתי יכולה להתרחש העברה בין דפים
כשמספקים תשובה סטטית למילוי בקשה
כשמפעילים webhook כדי לקבל תשובות דינמיות

ההיקף נקבע לפי המקום שבו מוחל רכיב handler: בתהליך, בדף או בפרמטר של טופס. הוא נקבע גם לפי המצב של התהליך המשויך (פעיל או לא), של הדף המשויך (פעיל או לא) או של הסוכן (מנסה למלא את הפרמטר המשויך של הטופס).

כללי ההיקף המפורטים הם:

  • מסלולים שהוחלו על התהליך הפעיל:
    • אם הדף הנוכחי הוא דף ההתחלה של התהליך, הוא נכלל בהיקף.
    • אם הדף הנוכחי הוא לא דף ההתחלה של התהליך, הם רלוונטיים רק אם יש להם דרישת כוונת חיפוש.
  • המסלולים שחלים על הדף הנוכחי נמצאים בהיקף.
  • הגורמים שמטפלים באירועים שמוחלים על ה-Flow הפעיל נמצאים בהיקף.
  • הגורמים המטפלים באירועים שחלים על הדף הנוכחי נמצאים בהיקף.
  • ה-Event handlers שמוחלים על פרמטר של טופס שהסוכן מנסה למלא כרגע נמצאים בהיקף.

מסלולים

יש שתי דרישות לגבי מסלולים, וצריך לספק אחת מהן או את שתיהן. אם מספקים את שתי הדרישות, שתיהן צריכות להתקיים כדי להפעיל את המסלול:

מונח הגדרה
דרישה לכוונת רכישה כוונה שצריך להתאים לקלט של משתמש הקצה בתור הנוכחי בשיחה. כשמסלול מכיל דרישת כוונה, הוא נקרא מסלול כוונה.
דרישת תנאי תנאי שצריך להתקיים. כשנתיב כולל דרישת תנאי, הוא נקרא נתיב תנאי.

אפשר להחיל מסלולים על תהליכים (מסלולים ברמת התהליך) ועל דפים (מסלולים ברמת הדף). לדוגמה, אפשר להשתמש בנתיבים במצבים הבאים:

X פריט
כשקלט של משתמש קצה תואם ליעד, התאמה צריכה להפעיל תגובה של מילוי סטטי.
כשקלט של משתמש קצה תואם ליעד, ההתאמה צריכה להפעיל מילוי עם webhook כדי לקבל תגובה דינמית.
כשקלט של משתמש קצה מספק את פרמטר הטופס הסופי הנדרש, בדיקת תנאי מפעילה מעבר של סשן לדף אחר.
כשקלט ממשתמש קצה מספק פרמטר ספציפי של טופס, בדיקת תנאי מפעילה תגובה של מילוי סטטי.
בדיקת תנאי שהוגדרה ל-true שכופה מעבר בין דפים.

הפצת כוונות

בדרך כלל, כשקוראים למסלול בגלל כוונת משתמש שתאמה, כוונת המשתמש נצרכת. אי אפשר להתאים שוב כוונת משתמש שכבר נעשה בה שימוש, אלא אם קלט חדש של משתמש הקצה מפעיל התאמה של כוונת משתמש חדשה. עם זאת, אפשר להעביר התאמה של כוונת משתמש מזרימה אחת לאחרת בתרחיש הבא:

  • מסלול ב-flow F1 כולל את intent I1 כדרישה ואת flow F2 כיעד מעבר.
  • ב-Flow F2 יש מסלול שגם בו נדרש intent I1.

במקרה הזה, כשמתבצעת קריאה למסלול ב-flow F1, מתבצעת התאמה של intent I1 פעמיים עבור קלט יחיד של משתמש קצה, ומתבצעת קריאה לשני המסלולים.

הפצת כוונות שימושית כדי:

X פריט
שינוי הדף הנוכחי לדף ספציפי בזרימה אחרת (למסלול של זרימת היעד של המעבר יש דף יעד ספציפי למעבר).
יצירת הודעת כניסה לדף ההתחלה של זרימה (למסלול של זרימת היעד למעבר יש מילוי).

קבוצות ניתוב

כשמפתחים סוכן, יכול להיות שתגלו שלדפים רבים יש קבוצה משותפת של נתיבים. כדי שאפשר יהיה להשתמש במסלולים שוב, אפשר להגדיר קבוצות מסלולים. אפשר ליצור את משאבי הקבוצה האלה לשימוש חוזר בתהליך או בסוכן כולו.

לדוגמה, יכול להיות שתרצו שהזרימה תטפל בקלט של משתמש קצה כמו "אני רוצה להוסיף תוספת לפיצה" ו "אני רוצה לשנות את גודל המשקה". צריך לטפל בקלט הזה כשדף אחד או יותר מתוך כמה דפים בתהליך פעילים. אפשר להגדיר שני מסלולים עם כוונות לטיפול בקלט הזה בכל הדפים הרלוונטיים, אבל זה כרוך בהרבה עבודה כפולה. במקום זאת, אפשר להגדיר את קבוצת המסלולים פעם אחת ולהוסיף הפניה לקבוצה בכל הדפים הרלוונטיים.

קבוצות של נתיבים ברמת הדימום

קבוצות ניתוב ברמת התהליך הן משאבים של קבוצות ניתוב שנוצרים עם תהליך כהורה. אפשר להשתמש בהם שוב במהלך התהליך.

קבוצות של מסלולים ברמת הסוכן

קבוצות של מסלולים ברמת הסוכן הן משאבים של קבוצות מסלולים שנוצרים עם סוכן כהורה. אפשר להשתמש בהם שוב בכל הנציג, אבל הם לא מאפשרים מסלולים שמובילים לדף לא סמלי כיעד.

מסלולים ברמת הדימום

נתיבים ברמת התהליך הם נתיבים שמוחלים על תהליך על ידי הוספה שלהם לדף ההתחלה של התהליך. אלה תרחישי השימוש בסוגים האלה של רכיבי Handler:

X פריט
רכיבי Handler עם דרישה של כוונת משתמש או תנאי בהיקף של דף ההתחלה של התהליך.
רכיבי Handler עם דרישת כוונה בהיקף של כל הדפים בתהליך.

כדי ליצור מסלולים ברמת הזרימה דרך המסוף:

  1. פותחים את דף ההתחלה של רצף הפעולות.
  2. לוחצים על לחצן ההוספה בכותרת נתיבים.
  3. תיפתח חלונית עריכת המסלול.
  4. צריך לספק את השדות של המסלול.
  5. לוחצים על Save.

כדי לשנות את הסדר של מסלולים ברמת הזרימה במסוף:

  1. פותחים את דף ההתחלה של רצף הפעולות.
  2. לוחצים על הכותרת מסלולים.
  3. תיפתח החלונית של רשימת המסלולים.
  4. גוררים את המסלולים לפי הסדר הרצוי. לחלופין, לוחצים על האפשרות בתפריט ואז בוחרים באפשרות העברה אל.

כדי למחוק מסלולים ברמת הזרימה מהמסוף:

  1. פותחים את דף ההתחלה של רצף הפעולות.
  2. לוחצים על הכותרת מסלולים.
  3. תיפתח החלונית של רשימת המסלולים.
  4. לוחצים על התפריט .
  5. בוחרים את האפשרות Delete.

מסלולים ברמת הדף

מסלולים ברמת הדף הם מסלולים שמוחלים על דף. אלה תרחישי השימוש בסוגים האלה של רכיבי Handler:

X פריט
רכיבי Handler עם דרישה של כוונה או תנאי במסגרת כשהדפים הספציפיים פעילים.

כדי ליצור מסלולים ברמת הדף מהמסוף:

  1. פותחים את הדף (לא את דף ההתחלה של התהליך).
  2. לוחצים על לחצן ההוספה בכותרת נתיבים.
  3. תיפתח חלונית עריכת המסלול.
  4. צריך לספק את השדות של המסלול.
  5. לוחצים על Save.

כדי לשנות את הסדר של מסלולים ברמת הדף דרך המסוף:

  1. פותחים את הדף (לא את דף ההתחלה של התהליך).
  2. לוחצים על הכותרת מסלולים.
  3. תיפתח החלונית של רשימת המסלולים.
  4. גוררים את המסלולים לפי הסדר הרצוי. לחלופין, לוחצים על האפשרות בתפריט ואז בוחרים באפשרות העברה אל.

כדי למחוק מסלולים ברמת הדף מהמסוף:

  1. פותחים את הדף (לא את דף ההתחלה של התהליך).
  2. לוחצים על הכותרת מסלולים.
  3. תיפתח החלונית של רשימת המסלולים.
  4. לוחצים על התפריט .
  5. בוחרים את האפשרות Delete.

גורמים מטפלים באירועים

יש דרישה אחת כדי להפעיל את הגורמים המטפלים באירועים:

מונח הגדרה
דרישה לגבי אירוע אירוע שצריך להפעיל. האירועים מזוהים לפי השם שלהם. חלק מהאירועים המובנים מופעלים כשמתקבל קלט לא צפוי ממשתמש הקצה, או כשמתרחשת שגיאת webhook. אפשר גם להגדיר אירועים מותאמים אישית שמופעלים כשקורה משהו מחוץ לשיחה.

אפשר להחיל מטפלים באירועים על תהליכים (מטפלים באירועים ברמת התהליך), על דפים (מטפלים באירועים ברמת הדף) ועל פרמטרים (מטפלים באירועים ברמת הפרמטר). לדוגמה, אפשר להשתמש בגורמים שמטפלים באירועים במצבים הבאים:

X פריט
כשקלט של משתמש קצה לא תואם לאף כוונה, גורם מטפל באירועים של אירוע no-match מספק תגובה ספציפית של static fulfillment.
הטיימר במערכת שלכם הסתיים, ואתם רוצים לספק למשתמש הקצה מידע על התזכורת באמצעות תגובה ספציפית של השלמת הזמנה סטטית.

גורמים שמטפלים באירועים ברמת התהליך

הגורמים המטפלים באירועים ברמת הזרימה הם גורמים מטפלים באירועים שמוחלים על זרימה. אלה תרחישי השימוש בסוגים האלה של רכיבי Handler:

X פריט
‫Handlers עם דרישת אירוע בהיקף של דף התחלת התהליך.
‫Handlers עם דרישת אירוע בהיקף של כל הדפים בתהליך.
טיפול בקלט לא צפוי של משתמשי קצה, משותף לכל הדפים בתהליך.
טיפול בשגיאות של webhook, שמשותפות לכל הדפים בתהליך.
טיפול באירועים מותאמים אישית שהופעלו על ידי המערכת, שמשותפים לכל הדפים בתהליך.

לכל תהליך יש מטפלי אירועים עבור no-match וno-input אירועים מובנים. ה-event handlers האלה נוצרים אוטומטית כשיוצרים זרימת עבודה, ואי אפשר למחוק אותם.

כדי ליצור מטפלים באירועים ברמת הזרימה מהמסוף:

  1. פותחים את דף ההתחלה של רצף הפעולות.
  2. לוחצים על לחצן ההוספה בכותרת Event handlers (מטפלים באירועים).
  3. תיפתח החלונית של גורם מטפל באירועים.
  4. מזינים את השדות של הגורם שמטפל באירועים.
  5. לוחצים על Save.

כדי למחוק מהמסוף גורמים שמטפלים באירועים ברמת הזרימה:

  1. פותחים את דף ההתחלה של רצף הפעולות.
  2. לוחצים על הכותרת Event handlers (פונקציות לטיפול באירועים).
  3. תיפתח החלונית של רשימת גורמים מטפלים באירועים.
  4. להציב את הסמן מעל גורם מטפל באירועים, ואז ללחוץ על לחצן המחיקה .

גורמים שמטפלים באירועים ברמת הדף

גורמים מטפלים באירועים ברמת הדף הם גורמים מטפלים באירועים שמוחלים על דף. אלה תרחישי השימוש בסוגים האלה של רכיבי Handler:

X פריט
‫Handlers עם דרישת אירוע בהיקף כשדפים ספציפיים פעילים.
טיפול בקלט בלתי צפוי של משתמשי קצה, ספציפי לדף.
טיפול בשגיאות של webhook, שספציפיות לדף.
טיפול באירועים מותאמים אישית שמופעלים על ידי המערכת, ספציפיים לדף.

כדי ליצור מטפלי אירועים ברמת הדף מהמסוף:

  1. פותחים דף (לא את דף ההתחלה של התהליך).
  2. אם לא מופיעה הכותרת Event handlers (מטפלים באירועים), לוחצים על Add state handler (הוספת מטפל במצב), בוחרים באפשרות Event handlers (מטפלים באירועים), ואז לוחצים על Apply (החלה).
  3. לוחצים על לחצן ההוספה בכותרת Event handlers (מטפלים באירועים).
  4. תיפתח החלונית של גורם מטפל באירועים.
  5. מזינים את השדות של הגורם שמטפל באירועים.
  6. לוחצים על Save.

כדי למחוק מהמסוף גורמים שמטפלים באירועים ברמת הדף:

  1. פותחים דף (לא את דף ההתחלה של התהליך).
  2. לוחצים על הכותרת Event handlers (פונקציות לטיפול באירועים).
  3. תיפתח החלונית של רשימת גורמים מטפלים באירועים.
  4. להציב את הסמן מעל גורם מטפל באירועים, ואז ללחוץ על לחצן המחיקה .

מטפלים באירועים ברמת הפרמטר

גורמים מטפלים באירועים ברמת הפרמטר הם גורמים מטפלים באירועים שמוחלים על פרמטר של טופס. הם נקראים גם reprompt handlers. ה-event handlers האלה לא מאפשרים אירועים מותאמים אישית, כי הם מיועדים לטפל בקלט לא תקין של משתמשי קצה במהלך מילוי טופס.

אלה תרחישי השימוש בסוגים האלה של רכיבי Handler:

X פריט
משתמש הקצה לא סיפק קלט תקין כשנשאל למלא פרמטר בטופס.

כדי ליצור מטפלים באירועים ברמת הפרמטר מהמסוף:

  1. פותחים דף שמכיל פרמטרים של טופס.
  2. לוחצים על פרמטר.
  3. תיפתח חלונית הפרמטרים.
  4. גוללים למטה לקטע Reprompt event handlers (הוספת גורמים מטפלים באירועים של הנחיות חוזרות) ולוחצים על Add event handler (הוספת גורם מטפל באירועים).
  5. תיפתח החלונית של גורם מטפל באירועים.
  6. מזינים את השדות של הגורם שמטפל באירועים.
  7. לוחצים על Save.

כדי למחוק מהמסוף גורמים שמטפלים באירועים ברמת הפרמטר:

  1. פותחים דף שמכיל פרמטרים של טופס.
  2. לוחצים על פרמטר.
  3. תיפתח חלונית הפרמטרים.
  4. גוללים למטה לקטע Reprompt event handlers (הפעלת הגורמים שמטפלים באירועים של הפעלה מחדש).
  5. להציב את הסמן מעל גורם מטפל באירועים, ואז ללחוץ על לחצן המחיקה .

אירועים מובנים

האירועים הבאים הם מובנים ומופעלים על ידי Dialogflow CX. חלק מהאירועים מוגבלים לרמות מסוימות.

שם האירוע
 ברמת ה-Flow ברמת הדף ברמת הפרמטר מופעל כאשר
sys.no-match-default ✔ ✔ ✔
  • ברמת הזרימה או הדף: הקלט של משתמש הקצה לא תואם לאף כוונה של רכיבי handler שנמצאים בהיקף.
  • ברמת הפרמטר: הקלט של משתמש הקצה לא עומד בדרישות של פרמטר הטופס.
sys.no-match-[1-6] ✔ ✔ ✔ אם מספקים פונקציות לטיפול באירועים כלשהם מתוך האירועים האלה שמסודרים לפי מספר, הן מופעלות במקום sys.no-match-default ובסדר הבא: sys.no-match-1,‏ sys.no-match-2 וכו'.
sys.no-input-default ✔ ✔ ✔ לא התקבלה קלט ממשתמש הקצה. הפעולה הזו יכולה להתבצע במקרים הבאים:
  • ‫Dialogflow CX מקבל קלט טקסט ריק ממשתמש הקצה.
  • מערכת Dialogflow CX מקבלת קלט אודיו ריק ממשתמש הקצה, או שהקלט לא מכיל דיבור מזוהה.
  • פסק זמן ללא דיבור מתרחש לפני שקלט האודיו של משתמש הקצה מכיל דיבור מזוהה.
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 (סיום התהליך עם ביטול). אפשר לראות את END_FLOW_WITH_CANCELLATION יעד המעבר הסמלי.
flow-failed ✔ ✔ התהליך הזה לא הצליח להשלים את המשימה שצוינה. האירוע הזה מופעל על ידי הדף End Flow With Failure (סיום התהליך עם כשל), ראו את END_FLOW_WITH_FAILURE יעד המעבר הסמלי.
flow-failed-human-escalation ✔ ✔ משתמש הקצה ביקש לדבר עם נציגים אנושיים. האירוע הזה מופעל על ידי הדף End Flow With Human Escalation (סיום התהליך עם העברה לטיפול אנושי). אפשר לראות את END_FLOW_WITH_HUMAN_ESCALATION יעד המעבר הסמלי.

אירועים מותאמים אישית

אפשר ליצור אירועים בהתאמה אישית ומטפלים באירועים. אירועים בהתאמה אישית משמשים לטיפול בדברים שקורים מחוץ לשיחה עם משתמש הקצה. לדוגמה, משתמש הקצה לחץ על לחצן, עבר פרק זמן מסוים, המלאי הזמין השתנה במהלך השיחה, וכך הלאה.

האירועים מזוהים רק לפי השם. כדי למנוע התנגשות עם אירועים מובנים, לא מומלץ להשתמש בשמות אירועים שמתחילים ב-sys. או ב-webhook..

כדי להפעיל אירוע באמצעות ה-API, צריך לעיין בשדה queryInput.event של השיטה detectIntent עבור הסוג Session.

בוחרים פרוטוקול וגרסה להפניה של הסשן:

פרוטוקול V3 V3beta1
REST Session resource Session resource
RPC ממשק הסשן ממשק הסשן
C++‎ SessionsClient לא זמין
C#‎ SessionsClient לא זמין
המשך SessionsClient לא זמין
Java SessionsClient SessionsClient
Node.js SessionsClient SessionsClient
PHP לא זמין לא זמין
Python SessionsClient SessionsClient
Ruby לא זמין לא זמין

סדר ההערכה

הערכת ה-Handlers מתבצעת בסדר מסוים. יש להקפיד על כללי האצבע הבאים:

  1. רק מטפלים בscope מוערכים.
  2. אפשר לקרוא רק ל-handlers שהדרישות שלהם מתקיימות.
  3. אם מתבצעת קריאה ל-handler ללא יעד מעבר, ההערכה של רשימת ה-handlers נמשכת. בגלל הכלל הזה, יכול להיות שיהיו כמה מקרים של מילוי הזמנות שיוסיפו כמה הודעות לתור התגובות.
  4. אם מפעילים רכיב handler עם יעד מעבר, ההערכה של רשימת רכיבי ה-handler מסתיימת.
  5. אם מופעלת פונקציית handler עם מימוש, והמימוש גורם לשגיאת webhook:
    • אם ל-handler מוגדר יעד מעבר, ה-webhook נכשל ללא הודעה.
    • אם הגורם המטפל באירועים נמצא בהיקף של האירוע, הוא מטפל באירוע וההערכה של רשימת הגורמים המטפלים מסתיימת.
    • אם אין גורם מטפל באירועים בהיקף של האירוע, ה-webhook נכשל בלי להציג הודעה.
  6. כשדרישה של כוונת משתמש מתקיימת, הכוונה נצרכת, ולכן אפשר לקרוא רק ל-handler הראשון של המסלול שנמצא עבור הכוונה (במאמר הפצת כוונת משתמש מפורטים היוצאים מן הכלל).
  7. כשדרישה של תנאי מסוים מתקיימת, התנאי לא נצרך, ולכן אפשר להפעיל כמה מסלולים עם התנאי.
  8. כשדרישה לאירוע מתקיימת, האירוע נצרך, ולכן אפשר לקרוא רק לגורם המטפל באירועים הראשון שנמצא עבור האירוע.
  9. סטאק הביצוע יכול להשפיע על סדר ההערכה.

תהליך ההערכה כולל שלושה שלבים:

  1. הערכת המסלולים שנדרשת בהם כוונה מתבצעת לפי הסדר הבא:
    1. ברמת הדף: מסלולים נפרדים שמוחלים על הדף הנוכחי, בסדר שבו הם סופקו.
    2. קבוצות ברמת הדף: קבוצות של נתיבים שחלות על הדף הנוכחי, בסדר שצוין.
    3. ברמת התהליך: מסלולים שחלים על התהליך הפעיל, בסדר שבו הם סופקו.
    4. קבוצות ברמת הזרימה: קבוצות של נתיבים שחלות על הזרימה הפעילה, בסדר שסופק.
  2. מסלולים שכוללים רק דרישת תנאי מוערכים לפי הסדר הזה:
    1. ברמת הדף: מסלולים נפרדים שמוחלים על הדף הנוכחי, בסדר שבו הם סופקו.
    2. קבוצות ברמת הדף: קבוצות של נתיבים שחלות על הדף הנוכחי, בסדר שצוין.
    3. ברמת התהליך (רק אם הדף הנוכחי הוא דף התחלת התהליך): מסלולים שחלים על התהליך הפעיל, לפי הסדר שצוין.
    4. קבוצות ברמת הזרימה (רק אם הדף הנוכחי הוא דף ההתחלה של הזרימה): קבוצות של נתיבים שחלות על הזרימה הפעילה, לפי הסדר שצוין.
  3. הערכת הגורמים המטפלים באירועים מתבצעת לפי הסדר הבא:
    1. ברמת הפרמטר: מטפלים באירועים שמוחלים על פרמטר הטופס של הדף הנוכחי שהסוכן מנסה למלא כרגע (מטפלים בהצגת הנחיות חוזרות), בסדר שבו הם מסופקים.
    2. ברמת הדף: מטפלי אירועים שחלים על הדף הנוכחי, בסדר שבו הם מופיעים.
    3. ברמת ה-Flow: גורמים מטפלים באירועים שמוחלים על ה-Flow הפעיל, לפי הסדר שבו הם סופקו.

יעדים של מעברים סמליים

כשמזינים יעד מעבר ל-handler, אפשר להזין זרימות או דפים ספציפיים, אבל אפשר גם להזין יעדי מעבר סמליים:

יעד מעבר סמלי
 תיאור
START_PAGE מעבר אל דף ההתחלה של התהליך הפעיל עם אותו שם.
END_FLOW סיום התהליך הפעיל כרגע וחזרה לדף שגרם למעבר לתהליך הנוכחי. אפשר גם לעיין במאמר בנושא מגבלות על Call stack ו-Flow stack של רכיב Handler.
END_FLOW_WITH_CANCELLATION סיום התהליך הפעיל כרגע וחזרה לדף שגרם למעבר לתהליך הנוכחי. הדף שממנו מתבצעת הקריאה יכול לטפל במעבר הזה באמצעות flow-cancelled אירוע מובנה. אפשר גם לעיין במאמר בנושא מגבלות על Call stack ו-Flow stack של רכיב Handler.
END_FLOW_WITH_FAILURE סיום התהליך הפעיל כרגע וחזרה לדף שגרם למעבר לתהליך הנוכחי. הדף שממנו מתבצעת הקריאה יכול לטפל במעבר הזה באמצעות flow-failed אירוע מובנה. אפשר גם לעיין במאמר בנושא מגבלת סטאק הביצוע של רכיב ה-Handler ומגבלת סטאק הזרימה.
END_FLOW_WITH_HUMAN_ESCALATION סיום התהליך הפעיל כרגע וחזרה לדף שגרם למעבר לתהליך הנוכחי. הדף שממנו מתבצעת הקריאה יכול לטפל במעבר הזה באמצעות flow-failed-human-escalation אירוע מובנה. אפשר גם לעיין במאמר בנושא מגבלות על Call stack ו-Flow stack של רכיב Handler.
END_SESSION ניקוי הסשן הנוכחי ומעבר לדף המיוחד שנקרא END_SESSION. הקלט הבא של המשתמש יפעיל מחדש את הסשן בדף הפתיחה של זרימת ההתחלה שמוגדרת כברירת מחדל.
PREVIOUS_PAGE מעבר לדף הקודם שגרם למעבר לדף הנוכחי. מצב הדף מהדף הקודם ישוחזר אחרי המעבר.
CURRENT_PAGE מעבר מחדש לדף הנוכחי. האפשרות הזו שימושית אם רוצים שהסוכן יחזור על משהו.

מגבלת סטאק של רכיבי Handler ו-Flow

כשסשן עובר מתהליך לתהליך עם יעדי מעבר ספציפיים, כל תהליך נדחף אל מחסנית התהליכים.

סטאק ביצוע של ה-handler

כשסשן עובר למצב END_FLOW, הוא חוזר לדף השיחה שגרם למעבר לתהליך שהושלם. במצב כזה, סטאק הביצוע של ה-handler נשמר. המערכת תדלג על כל אמצעי הטיפול שהוערכו קודם בדף שממנו מתבצעת הקריאה, ותעריך את אמצעי הטיפול שנותרו לפי הסדר.

לדוגמה:

  1. בדף P יש שלושה רכיבי handler בסדר הזה: H1, ‏ H2, ‏ H3.
  2. התנאי H1 מוערך, אבל הוא לא גורם למעבר.
  3. התנאי H2 מוערך, וגורם למעבר לזרימת F.
  4. דף בתהליך F עובר לEND_FLOW.
  5. הסשן חוזר לדף P, שחוזר להיות פעיל עם מצב שנשמר.
  6. הערכת ה-handler בדף P נמשכת מהסטטוס שנשמר, ולכן מתבצעת הערכה של H3.

מגבלת מחסנית של תהליכים

המגבלה המקסימלית של מחסנית זרימה היא 25. חריגה ממגבלת המקסימום של המחסנית עלולה לגרום להוצאת תהליכים מהמחסנית, מה שיוביל להתנהגות לא צפויה כשמשתמשים במעבר END_FLOW. כדי למנוע בעיות פוטנציאליות כאלה, כדאי לצמצם את מספר המעברים בין זרימות שלפני המעבר END_FLOW.

אם מחסנית ה-Flow ריקה, המעבר END_FLOW מסיים את הסשן.

הגדרת תנאים

כדי להגדיר תנאים באמצעות המסוף, צריך לספק כללי תנאים עם אחת משלוש אפשרויות לוגיות:

  • התאמה לכלל אחד לפחות (או)
  • התאמה לכל כלל (וגם)
  • התאמה אישית של הביטוי

כדי להקל על התהליך, אפשר להשתמש באפשרויות AND/OR כדי ליצור תנאים פשוטים או מורכבים לערכי פרמטרים.

אתם יכולים להשתמש באפשרות פריסה גמישה להתאמה אישית של הביטוי לכל סוגי התנאים, כולל פונקציות מערכת וקבועים בוליאניים.

לדוגמה, כדי להגדיר תנאי שיש לו סיכוי של 10% לעבור את ההערכה, בוחרים באפשרות התאמה אישית של הביטוי ומזינים $sys.func.rand() < 0.1 בשדה תנאי:

צילום מסך של הגדרת תנאי מותאם אישית

הקודם
Pages
הבא
Intents