Last updated on ספטמבר 9th, 2026 at 06:31 pm
למה אין Webhook יוצא מ-Linet, ומה עושים במקום
ה-API של Linet בנוי כולו על פעולות שהמערכת החיצונית שלכם יוזמת: Search, List, View, Create, Update, Delete, Print, Send. אין שם מנגנון שבו Linet "מתקשרת אליכם" ביוזמתה כשמשהו קורה, כמו מכירה, החזרה או העברה בין מחסנים. אם המערכת שלכם צריכה לדעת שמשהו השתנה, היא זו שצריכה לשאול, לא לחכות שיודיעו לה.
זו לא בעיה, זו פשוט אומרת שהאסטרטגיה הנכונה היא Polling, שאילתה תקופתית שבודקת מה השתנה מאז הבדיקה הקודמת, במקום להמתין להתראה שלא תגיע.
מהו Polling ולמה זו האסטרטגיה הנכונה כאן
Polling אומר שהמערכת שלכם שולחת בקשה ל-Linet בתדירות קבועה, כל דקה, כל חמש דקות, או כל שעה, בהתאם לרגישות הזמן שאתם צריכים, ובודקת אם יש שינויים חדשים מאז הבדיקה האחרונה. ל-Linet יש שני מודלים ב-API שמתאימים בדיוק למטרה הזו: transaction, שמתעד תנועות במערכת, ו-inventoryitem, שמתעד ספציפית תנועות מלאי בין מחסנים ותנועות נכנסות ויוצאות מול לקוחות וספקים. שני המודלים תומכים בפעולות search ו-list, ומכאן שאפשר לשלוף רק את מה שנוצר אחרי חותמת זמן מסוימת, בלי לשלוף מחדש את כל ההיסטוריה בכל פעם.
איך בונים לולאת Polling יעילה בלי להעמיס על המערכת
שתי טעויות נפוצות קורות כאן: לבדוק יותר מדי לעיתים קרובות ולהעמיס בקשות מיותרות, או לבדוק רחוק מדי בזמן ולפספס עדכונים קריטיים כמו מלאי שאזל. הגישה הנכונה:
- שמרו תמיד את חותמת הזמן של הבדיקה האחרונה שהצליחה
- בכל בקשת Polling, בקשו רק רשומות שנוצרו או עודכנו אחרי אותה חותמת זמן
- קבעו תדירות לפי הצורך האמיתי, מלאי קריטי יכול להצדיק כל דקה, בעוד שדוחות כלליים מסתפקים בפעם בשעה
- טפלו בעימוד (pagination) אם יש הרבה תנועות בין בדיקה לבדיקה, כדי לא לפספס רשומות שנחתכו
מעקב אחרי מכירה, החזרה והעברה בין מחסנים
כל אחד משלושת האירועים האלה משתקף אחרת דרך ה-API:
- מכירה, מתועדת כמסמך חדש דרך מודל
docs, ולרוב גם מייצרת תנועת מלאי מתאימה - החזרה, לרוב מתועדת כמסמך מסוג נגדי (כמו זיכוי), שגם הוא נשלף דרך
docsעם סוג המסמך המתאים מתוךdoctype - העברה בין מחסנים, מתועדת ספציפית דרך
inventoryitem, שנועד בדיוק למטרה הזו
חשוב לשים לב: המודלים האלה תומכים ביצירה, חיפוש, רשימה וצפייה בלבד, לא בעדכון או מחיקה. זה הגיוני מבחינה חשבונאית, תנועה שכבר נרשמה לא אמורה להשתנות רטרואקטיבית, אלא להתבטל דרך תנועה נגדית חדשה.
| אירוע | מודל API רלוונטי | מה בודקים |
|---|---|---|
| מכירה | docs | מסמכים חדשים מסוג חשבונית או קבלה |
| החזרה | docs | מסמכים חדשים מסוג זיכוי |
| העברה בין מחסנים | inventoryitem | תנועות מלאי חדשות בין מיקומים |
| שינוי כללי | transaction | כל תנועה חדשה בחשבון מאז הבדיקה הקודמת |
שאלות נפוצות
אם אין Webhook, איך יודעים שמלאי אזל בזמן אמת?
על ידי Polling תדיר מספיק על מודל ה-inventoryitem או item, ובדיקת הכמות הזמינה בכל בקשה. "זמן אמת" הופך בפועל ל"כמעט זמן אמת", בפער של דקה או שתיים, בהתאם לתדירות שתבחרו.
האם אפשר להשתמש בכלי כמו Zapier או Make כדי לייצר Webhook מלאכותי?
כלים כאלה יכולים לבצע Polling מתוזמן מטעמכם ולהפעיל פעולות בהתאם, אבל זה עדיין Polling מתחתיו, רק שהוא מנוהל בכלי חיצוני במקום בקוד שלכם.
כמה תכוף כדאי לבצע Polling בלי לפגוע בביצועים?
תלוי בעומס ובצורך העסקי. אין מספר קסם, אבל מומלץ להתחיל בתדירות נמוכה יחסית ולהדק אותה רק אם באמת מתגלה צורך במידע עדכני יותר.
מה קורה אם שתי בדיקות Polling חופפות בזמן?
צריך מנגנון נעילה פשוט שמוודא שלא רצות שתי בדיקות באותו רגע, אחרת אותה תנועה עלולה להיקלט פעמיים במערכת שלכם.
האם צריך לשמור לוג של כל בדיקת Polling?
מומלץ מאוד, גם כדי לדעת מתי הבדיקה האחרונה המוצלחת הייתה, וגם כדי לאתר בעיות אם משהו לא הגיע כמצופה.
