Webhook או בדיקה מחזורית: איך סוכן AI יודע שמשהו השתנה
# Webhook או בדיקה מחזורית: איך סוכן AI יודע שמשהו השתנה
Webhook הוא בדרך כלל הדרך הנכונה להודיע לסוכן AI שאירוע עסקי קרה. המערכת שבה התרחש האירוע שולחת הודעה יזומה, והסוכן מגיב. בדיקה מחזורית, או polling, פועלת בכיוון ההפוך: הסוכן פונה למערכת כל כמה דקות ושואל אם משהו השתנה.
זו אינה בחירה בין טכנולוגיה מודרנית לטכנולוגיה מיושנת. יש מערכות שלא מציעות Webhook, יש תהליכים שלא צריכים תגובה מיידית, ויש אירועים חשובים מדי מכדי להסתמך על הודעה אחת. הבחירה הטובה נקבעת לפי אופי האירוע, מגבלת הזמן והמחיר של פספוס.
השורה התחתונה: משתמשים ב־Webhook כדי להניע את התהליך, ובבדיקה מחזורית מצומצמת כדי לגלות מה לא הגיע. אם חייבים לבחור רק אחת, בוחרים לפי השאלה העסקית, לא לפי הנוחות של המפתח.
## שתי דרכים לענות על אותה שאלה
נניח שעסק רוצה שסוכן AI יטפל בהזמנה חדשה שנכנסה למערכת המסחר. הוא צריך לדעת שההזמנה קיימת לפני שיוכל לבדוק מלאי, להכין משימה או לעדכן את הצוות.
בחיבור מבוסס Webhook, מערכת המסחר שולחת אירוע לכתובת שהוגדרה מראש. האירוע אומר, למשל, שהזמנה 4821 נוצרה. הסוכן מקבל את האירוע, מאמת שהגיע מהמערכת המוכרת ומתחיל את התהליך המתאים.
בחיבור מבוסס בדיקה מחזורית, אין הודעה יזומה. אחת לחמש דקות נשאלת מערכת המסחר: "אילו הזמנות נוצרו מאז הבדיקה האחרונה?" התשובה עשויה לכלול אפס הזמנות, הזמנה אחת או כמה הזמנות.
בשני המקרים הסוכן יכול להגיע לאותה הזמנה. ההבדל נמצא בדרך: Webhook מעביר אירוע כשהוא קורה; בדיקה מחזורית מחפשת שינוי לפי לוח זמנים.
## כשהזמן העסקי קצר, האירוע צריך להגיע אל הסוכן
Webhook מתאים במיוחד כאשר יש משמעות לדקות הראשונות. בקשה לביטול הזמנה, פגישה ששינתה שעה, עסקה שעברה שלב או טופס דחוף אינם צריכים לחכות לסריקה הבאה.
GitHub מתארת Webhook כמנגנון שמספק מידע למערכת אחרת ברגע שאירוע מתרחש, במקום לסרוק את ה־API שוב ושוב. Stripe פועלת באותו עיקרון: אירועים נשלחים לכתובת שהעסק רשם, והמערכת המקבלת מחזירה אישור קבלה.
מבחינת העסק, היתרון אינו רק מהירות. Webhook גם מפחית פניות חסרות תוצאה. אם מגיעות שתי הזמנות בשעה, אין סיבה לשאול 60 פעמים אם נכנסה הזמנה. שתי הודעות יכולות להספיק.
אבל מהירות אינה ערובה לשלמות. הכתובת המקבלת יכולה להיות זמנית לא זמינה, ההודעה יכולה להגיע שוב, וסדר ההגעה אינו תמיד סדר ההתרחשות. לכן אסור לתרגם "קיבלתי אירוע" ל־"כל התהליך הושלם". האירוע הוא צלצול בדלת. אחרי הפתיחה עדיין בודקים מי הגיע ומה מותר לו לבקש.
## בדיקה מחזורית טובה כשעיכוב ידוע הוא מחיר סביר
Polling מתאים לתהליכים שבהם אין צורך להגיב ברגע השינוי. דוח הוצאות לילי, סנכרון קטלוג פעם בשעה או איסוף סטטוסים בסוף יום יכולים לעבוד היטב בבדיקה מתוזמנת.
הוא מתאים גם כאשר מערכת המקור פשוט אינה מציעה Webhook. בישראל יש לא מעט מערכות ותיקות עם API שמאפשר לקרוא נתונים, אך לא יודעות לדחוף אירועים החוצה. במצב כזה polling אינו פתרון מביך. הוא החיבור האפשרי, וצריך לתכנן אותו היטב.
הטעות היא לבחור תדירות שרירותית. בדיקה בכל דקה נשמעת זריזה, אבל היא יכולה להעמיס על מערכת המקור, להיתקל במגבלות שימוש ולייצר הרבה רישומים שלא מספרים דבר. בדיקה פעם ביום חוסכת פניות, אך עלולה להפוך טיפול של שעה לטיפול של מחר.
קובעים את הקצב לפי חלון התגובה העסקי. אם מנהלת הכספים צריכה דוח עד 08:30, אפשר לאסוף את הנתונים מעט קודם. אם שינוי בפגישה צריך להגיע לנציג בתוך עשר דקות, מרווח הבדיקה חייב להיות קצר מעשר דקות ולהשאיר זמן לביצוע הפעולה.
## מטריצת החלטה לפי מחיר האיחור ומחיר הפספוס
**זמן תגובה:** Webhook מגיע קרוב לזמן האירוע. בבדיקה מחזורית זמן התגובה תלוי במרווח שנקבע.
**פניות כשאין שינוי:** Webhook כמעט אינו מייצר פנייה בלי אירוע. בדיקה מחזורית פונה גם כאשר אין דבר חדש.
**תלות במערכת המקור:** Webhook דורש יכולת לשלוח אירועים. בדיקה מחזורית דורשת API שמאפשר לקרוא שינויים.
**נפילה זמנית:** Webhook נשען על ניסיונות חוזרים וקליטת אירועים עמידה. בבדיקה מחזורית, המחזור הבא יכול להשלים פער.
**מעקב:** בחיבור Webhook צריך לזהות הודעות כפולות ולאמת את המקור. בבדיקה מחזורית צריך לשמור נקודת זמן או סמן התקדמות.
**שימוש מתאים:** Webhook מתאים לאירוע שדורש תגובה מהירה. בדיקה מחזורית מתאימה לסנכרון שבו עיכוב מוגדר מתקבל.
הקריטריון החשוב ביותר הוא מחיר הפספוס. אם אירוע שלא הגיע משאיר לקוח בלי תשובה, עסקה בלי מעקב או שינוי תפעולי בלי טיפול, לא מספיק לבחור את הנתיב המהיר. צריך גם נתיב שמגלה חוסרים.
לעומת זאת, אם מדובר באיסוף נתונים לדוח פנימי, עיכוב קטן ומוכר עשוי להיות סביר. אין טעם לבנות מערכת אירועים מורכבת רק כדי שגרף של יום אתמול יתעדכן כמה דקות מוקדם יותר.
## Webhook אינו משימה, אלא הודעה על אירוע
אחת הטעויות הנפוצות היא להכניס את כל העבודה לתוך הטיפול הראשוני ב־Webhook. האירוע מגיע, ובאותה בקשה הסוכן קורא מסמכים, מעדכן CRM, מכין הודעה ושולח אותה. אם אחד השלבים איטי, מערכת המקור אינה מקבלת אישור בזמן ועלולה לשלוח את האירוע שוב.
עדיף שהקליטה תהיה קצרה. היא מאמתת את מקור ההודעה, שומרת את מזהה האירוע, בודקת אם כבר התקבל ומכניסה יחידת עבודה לתור. לאחר מכן היא מחזירה אישור. העבודה העסקית ממשיכה בנפרד.
ההפרדה הזאת מאפשרת לענות על שאלות שמופיעות ביום תקלה: האם האירוע הגיע, האם התקבל פעמיים, האם העבודה התחילה, ובאיזה שלב היא נעצרה. בלי ההפרדה נשארת שורה כללית שאומרת שהחיבור נכשל. זו אבחנה חלשה מדי כשיש הזמנה אמיתית בצד השני.
גם תוכן האירוע דורש החלטה. אירוע יכול להכיל את כל פרטי הרשומה, או רק מזהה שמאפשר לקרוא את הגרסה העדכנית מהמערכת. כשיש סיכוי שהנתונים השתנו מאז השליחה, קריאה לפי מזהה מונעת עבודה על צילום ישן. כשמערכת המקור איטית או מוגבלת, אפשר לשמור את פרטי האירוע ולהגדיר אילו שדות נחשבים מוסמכים.
## מנגנון גיבוי לא צריך להריץ את התהליך פעמיים
החיבור העמיד ביותר משלב בין שתי הגישות. Webhook מפעיל את העבודה בזמן אמת. בדיקה מחזורית, בתדירות נמוכה יותר, משווה בין האירועים שנרשמו במערכת המקור לבין אלה שנקלטו אצל הסוכן.
נניח שהסוכן אמור לטפל בכל עסקה שעברה לסטטוס "מאושר". האירוע מפעיל את הטיפול מיד. אחת לכמה שעות, בדיקת התאמה מחפשת עסקאות שאושרו אך אין להן רישום קליטה. אם נמצאה אחת, היא נכנסת לאותו תור עם אותו מזהה עסקי.
המילה "אותו" חשובה. מסלול הגיבוי אינו תהליך שני עם חוקים אחרים. הוא דרך נוספת להכניס את אותה יחידת עבודה. אחרת אירוע שהגיע באיחור ובדיקה שמצאה אותו במקביל עלולים ליצור שתי פעולות.
לכן שומרים מזהה יציב, למשל מזהה העסקה יחד עם סוג השינוי. לפני כל ביצוע בודקים אם יחידת העבודה כבר קיימת ומה מצבה. כך הגיבוי משלים חוסר במקום להכפיל הצלחה.
## ארבע שאלות שסוגרות את הבחירה לפני הפיתוח
התחילו בזמן: כמה איחור העסק יכול לסבול באירוע הזה? התשובה צריכה להיות מעשית. "כמה שיותר מהר" אינה דרישה שאפשר לתכנן לפיה. חמש דקות, שעה או עד הבוקר הן תשובות שימושיות.
אחר כך בדקו מה מערכת המקור יודעת לעשות. האם היא שולחת אירועים, אילו אירועים זמינים, האם יש מזהה ייחודי, ומה קורה כשהכתובת המקבלת אינה עונה. לא מניחים שכל Webhook כולל ניסיון חוזר או שכל API מאפשר לשאול מה השתנה מאז נקודת זמן מסוימת.
השאלה הבאה היא מה מחיר האירוע החסר. יש פער גדול בין שורת דוח שמגיעה במחזור הבא לבין הוראת ביטול שלא נקלטה. ככל שהמחיר גבוה יותר, כך נדרש מנגנון התאמה עצמאי.
לבסוף מחליטים מה תהיה הראיה. עבור כל אירוע חשוב צריך להיות אפשר לראות מתי נוצר, מתי נקלט, איזו עבודה נפתחה ומה התוצאה. בלי הראיה הזאת, ויכוח על Webhook מול polling הוא ויכוח על צינורות בלי שעון מים.
## הבחירה הנכונה היא חוזה זמן, לא העדפה טכנית
Webhook הוא ברירת מחדל טובה לאירועים שצריכים להניע פעולה. בדיקה מחזורית טובה לסנכרון איטי יותר, למערכות שאין בהן אירועים ולבקרת השלמה. השילוב ביניהם מתאים כאשר אסור שאירוע חשוב ייעלם בשקט.
לפני שמחברים סוכן AI ל־CRM, למייל או ליומן, כתבו ליד כל אירוע שני זמנים: מתי העסק רוצה לדעת עליו, ומתי מאוחר מדי לפעול. משם הבחירה נעשית הרבה פחות מסתורית.
אם יש לכם מערכת אחת עם כמה סוגי אירועים, [פגישת גילוי אוטומציה](/automation-discovery) היא מקום טוב למפות אותם. הביאו חמישה אירועים אמיתיים. נמיין אותם לפי חלון תגובה ומחיר פספוס, ונחליט אילו צריכים Webhook, אילו מתאימים לבדיקה מחזורית ואיפה נדרש מסלול גיבוי.
### מקורות
* [GitHub Docs: אודות Webhooks](https://docs.github.com/en/webhooks/about-webhooks)
* [Stripe Docs: קבלת אירועי Webhook](https://docs.stripe.com/webhooks)
* [Microsoft Graph: קבלת התראות שינוי דרך Webhooks](https://learn.microsoft.com/en-us/graph/change-notifications-delivery-webhooks)