בקצרה
משאירים את ההתנהגות הייחודית לכל ערוץ בשכבת החיבור ואת ההחלטות העסקיות בשירות משותף. מאמתים מי עומד מאחורי ההודעה, בודקים גישה לכל רשומה, מפרידים הקשר בין שיחות ועוקבים אחר פעולות שאושרו. מתחילים בערוץ אחד ומוסיפים את השני כשהתהליך כבר מדיד.
בוחרים את המשימה העסקית לפני הערוץ
ניקח לדוגמה, להמחשה בלבד, עוזר תפעול פנימי: עובד שואל איפה נמצא משלוח, מקבל סטטוס עדכני ויכול לבקש העברה לטיפול. Slack ו־Telegram הם דרכי גישה לתהליך הזה. אף ממשק שיחה לא אמור להפוך למקור האמת של רשומת המשלוח.
מתחילים במקום שבו המשתמשים המיועדים כבר עובדים ושבו הארגון יכול לנהל זהויות והרשאות. לא משיקים שני ערוצים רק כדי שההדגמה תיראה מלאה. קודם מוכיחים שתהליך מחובר אחד חוסך עבודה ומטפל בחריגים.
משתפים את התהליך, לא את כל ההנחות על הערוץ
משאירים את קליטת ההודעות ועיצוב התשובות במתאמים ייעודיים לערוצים. שירות משותף מבצע בדיקות זהות, מאתר משלוחים ומפעיל פעולות מותרות. כך יש לצוות מקום אחד לתחזוקת הכללים העסקיים, תוך שמירה על ההתנהגות של כל ערוץ.
ה־Events API של Slack מצפה לתשובת HTTP 2xx לכל בקשת אירוע תוך שלוש שניות, וכברירת מחדל מנסה למסור שוב עד שלוש פעמים אירוע שמסירתו נכשלה; התיעוד ממליץ לטפל באירועים נכנסים דרך תור. לפי התיעוד של Telegram, מה שבוט מקבל תלוי בסוג השיחה, בכך שהוא מוגדר כמנהל בקבוצה ובמצב הפרטיות (privacy mode) שלו. אין להניח שבוט מקבל כל מה שאדם רואה. אלה שיקולים מתועדים של הפלטפורמות, ולא תוצאות של בדיקת הטמעה.
שם שמופיע בצ'אט אינו החלטת הרשאה
מוודאים שכל בקשה אכן מגיעה מהפלטפורמה: Slack חותמת על הבקשות שלה, ו־webhook של Telegram יכול לכלול טוקן סודי שמגדירים מראש. ממפים את הזהות המאומתת בערוץ לזהות המשתמש בארגון באמצעות תהליך קישור מפורש, ואז בודקים את הרשאת המשתמש למשלוח המבוקש. שם מוכר או כתובת אימייל שמישהו הקליד בשיחה אינם מספיקים.
מגבילים את הקשר העבודה לארגון, למשתמש המורשה ולשיחה. אסור ששאלה בקבוצה תקבל מידע פרטי משיחה אחרת. אם אדם עובר מ־Slack ל־Telegram, מבקשים להמשיך בתהליך העברה מורשה במקום להעתיק את השיחה הקודמת לקהל חדש.
- מי שואל, ואיך החשבון שלו קושר לזהות הארגונית?
- לאיזה ארגון ולאיזו רשומה עסקית הבקשה שייכת?
- מי יכול לראות את התשובה בערוץ הזה?
- מה קורה כאשר הרשאה נשללת או החברות בקבוצה משתנה?
מנהלים פעולות עם מעקב
הצגת סטטוס משלוח ופתיחת בקשה לטיפול הן פעולות שונות. לפני פתיחת בקשה, מציגים את הפעולה המוצעת, בודקים הרשאה בזמן הביצוע ומתעדים את מזהה הפעולה העסקית. מדווחים על השלמה רק לאחר אישור מהמערכת המקבלת.
אסור שמסירה חוזרת של הודעה תיצור בקשות טיפול כפולות. שומרים את מזהה האירוע של הפלטפורמה (event_id ב־Slack, update_id ב־Telegram) ואת מזהה הפעולה מחוץ לשיחה של המודל, ומגדירים איך מבררים תוצאות לא ודאיות. הסוכן יכול לסכם את המצב; הוא לא אמור להמציא הצלחה רק כי המשתמש מחכה.
מפעילים מסלול אחד ואז מרחיבים
בודקים עם רשומות סינתטיות ומשתמשים בעלי הרשאות שונות. כוללים אירוע חוזר, מערכת עסקית שאינה זמינה, משתמש שהרשאתו נשללה ובקשה שנשלחה בשיחה הלא נכונה. מוודאים שאנשי הצוות יכולים למצוא מקרה שלא הושלם ולסיים את הטיפול בו.
מודדים משימות שהושלמו, התערבות של איש צוות, זמן תגובה ועלות למשימה שהושלמה. מוסיפים ערוץ שני רק כאשר יש לתהליך הראשון אחראי ברור ותוצאות מספקות. UVISION יכולה לספק מפתחים ייעודיים ופרויקטים מנוהלים לעבודה המתמשכת הזאת, עם לפחות מפתח אחד במשרה מלאה בכל פרויקט. תחזוקת החיבור למערכת הקריטית היא חלק מהמוצר, ולא התקנת בוט חד־פעמית.
רוצים לבחון איך זה מתאים למערכות שלכם?
לשירות הרלוונטי