קיבלנו הרבה פניות בנושא חיבור למערכות חיצוניות. גיבשנו רעיון ראשוני למודול API ונשמח לשמוע אם הכיוון עונה על הצרכים שלכם!
המודל מבוסס על מערך של פועולות עם הגדרה לאיזה פעולה לעבור בסיום או ע"פ הקשה
ניתן להגדיר פעולות בשני דרכים:
בהגדרה הראשונית צריך להגדיר מה הפעולה הראשונה שיבצע (עדיף לכאורה מאשר שיבחר באופן אוטומטי את הפעולה הראשונה במערך)
היתרונות המשמעותיים:
השרת לא צריך להגדיר את כל הפעולות מראש, אלא יכול להוסיף פעולות בהתאם לתשובות המשתמש והתקדמות השיחה כל פעולת curl יכולה לתקשר עם שרת שונה, מה שמאפשר אינטגרציה עם מערכות מרובות בזרימת שיחה אחת המערכת שומרת משתנים באופן מקומי ומשתמשת בהם לפי הצורך, ללא צורך בתקשורת מול השרת בכל שלב סוגי פעולות בסיסיות play_and_get_digits: השמעת הודעה וקבלת קלט playback: השמעת הודעה curl: שליחת בקשה ל-API hangup: ניתוק השיחהבהמשך כנראה נוסיף פעולות כמו הקלטה או העברה למודל API אחר וכדו'
מבנה הפעולותכל פעולה במערך מוגדרת עם:
{ "uuid": "שם_ייחודי", "type": "סוג_הפעולה", "next_action": "הפעולה_הבאה", // או "conditional_map": { "תנאי": "פעולה_הבאה" } }בפעולת curl יש מפתח מיוחד:
{ "type": "curl", "curl_command": "...", "next_action_on_error": "הפעולה_במקרה_שגיאה" } משתנים דינמיים שמירת משתנים: "save_variable": "שם_המשתנה" שימוש במשתנים: {{שם_המשתנה}} משתנה מובנה: {{user}} - מזהה שיחה ייחודי דוגמה מלאה: אימות PINהנה דוגמה מקיפה שמדגימה את כל היכולות. בוא נעקוב אחר המשתמש בתהליך:
תחילת השיחה:
המערכת משמיעה: "ברוכים הבאים למערכת האימות. אנא הקישו קוד PIN בן 3 ספרות" המשתמש מקיש את הקוד, נניח 123 אם המשתמש לא מקיש כלום או מקיש קוד לא תקין, המערכת תעבור להשמעת הודעת שגיאהבדיקת הקוד:
המערכת שולחת את הקוד לבדיקה בשרת בזמן זה המשתמש ממתין לתשובה אם יש בעיית תקשורת, המשתמש ישמע: "מצטערים, אירעה שגיאה. אנא נסו שוב מאוחר יותר"אישור הקוד:
אם הקוד תקין, המערכת משמיעה: "הקשתם את המספר..." ואז משמיעה כל ספרה בנפרד: "אחת... שתיים... שלוש..." לאחר מכן: "לאישור הקישו 1, להקשה מחודשת הקישו 2" המשתמש בוחר: אם מקיש 1 - ממשיך לאישור סופי, אם מקיש 2 - חוזר להקשת הקוד מחדשסיום מוצלח:
אם המשתמש אישר והכל תקין, ישמע: "הקוד אומת בהצלחה, תודה ולהתראות" השיחה מסתיימתטיפול בשגיאות:
אם הקוד שגוי, המשתמש ישמע: "הקוד שהקשתם שגוי" וחוזר להתחלה אם אין קלט או יש שגיאה, המשתמש ישמע הודעת שגיאה מתאימההנה ההגדרה הראשונית שתוגדר בממשק שמממש את התהליך הזה:
{ "first_action": "get_pin", "actions": [ { "uuid": "get_pin", "type": "play_and_get_digits", "audio_files": ["enter_pin.wav"], "min_digits": 3, "max_digits": 3, "tries": 3, "timeout": 5000, "terminator_key": "#", "regex_pattern": "\\d+", "save_variable": "pin", "conditional_map": { "no_input": "fail", "default": "verify_pin" } }, { "uuid": "verify_pin", "type": "curl", "curl_command": "https://server1.dev/verify?pin={{pin}}", "next_action_on_error": "fail" } ] } דוגמאות לתשובות שרת תשובה תקינה - הוספת פעולות חדשות: { "next_action": "play_pin", "new_actions": [ { "uuid": "play_pin", "type": "playback", "audio_files": [ "you_entered.wav", "digits/1.wav", "digits/2.wav", "digits/3.wav" ], "next_action": "get_confirmation" }, { "uuid": "get_confirmation", "type": "play_and_get_digits", "audio_files": ["confirm.wav"], "min_digits": 1, "max_digits": 1, "tries": 3, "timeout": 5000, "terminator_key": "#", "regex_pattern": "[12]", "conditional_map": { "1": "confirm_pin", "2": "get_pin", "no_input": "fail" } } ] } תשובת שגיאה - חזרה למצב קודם: { "next_action": "invalid_pin", "new_actions": [ { "uuid": "invalid_pin", "type": "playback", "audio_files": ["invalid_pin.wav"], "next_action": "get_pin" } ] }נשמח לשמוע מכם:
האם המבנה ברור ומספק? האם חסרים שדות או יכולות טכניות? האם יש לכם הצעות לשיפור המודל? האם הדוגמאות מספיק ברורות? האם נראה לכם שעבודה בצורה כזאת נוחה בפיתוח מערכות מורכבות?