API, Webhooks או ממשק טעינה: איך מחברים מערכת ל-Priority

שתי שאלות לפני הטכנולוגיה

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

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

1. REST API — ברירת המחדל

ה-API של Priority מבוסס על פרוטוקול OData. הוא מאפשר לקרוא, ליצור, לעדכן ולמחוק רשומות במסכים, כולל תתי-מסכים — למשל הזמנה עם השורות שלה בפעולה אחת. ההזדהות יכולה להיות בשם משתמש וסיסמה, ב-Personal Access Token או ב-OAuth2 (התיעוד של Priority).

שני דברים כדאי לדעת לפני שמתכננים. הראשון הוא כסף: לפי התיעוד, השימוש ב-API נמדד בטרנזקציות שנמכרות בחבילות של 10,000 ומתחדשות כל חודש, ואפליקציה יכולה לעבוד עם רישוי ייעודי משלה או עם רישוי API כללי. השני הוא קצב: ב-Priority Cloud יש מדיניות שימוש הוגן — עד 100 קריאות בדקה לכל משתמש, מספר מוגבל של בקשות במקביל, ותקרה של 5,000 בקשות בכל חלון של חמש דקות. בקשה שחורגת נדחית עם שגיאה 429.

המשמעות המעשית: חיבור שבודק כל דקה כל מוצר באתר מול Priority ישרוף טרנזקציות וייתקע על המגבלות. חיבור טוב מעביר רק מה שהשתנה, מקבץ קריאות, ומטפל בשגיאה 429 בהמתנה ובניסיון חוזר — לא בכשל שקט.

ועוד פרט קטן שמפיל דוחות: מגרסה 25.1 מספר הרשומות שחוזרות בקריאה אחת מוגבל בהגדרת מערכת, וברירת המחדל היא 2,000. מי שמושך טבלה גדולה בלי דפדוף יקבל רק את תחילתה.

2. Webhooks — כש-Priority צריך להודיע

במקום שהמערכת השנייה תשאל את Priority כל כמה דקות אם משהו השתנה, Priority יכול לשלוח הודעה בעצמו. ה-Webhook מופעל מתוך חוק עסקי או משלב בתרשים זרימה (BPM) — למשל כשמשלוח עובר לסטטוס "בדרך" — ושולח רק את השדות שהוגדרו בהודעה (תיעוד ה-Webhooks).

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

3. ממשקי טעינה — כשהנתון מגיע כקובץ

לא לכל מערכת יש API. מחסן חיצוני, חברת שילוח או מערכת ותיקה מוציאים לעיתים קרובות קובץ. ממשק טעינה של Priority קולט את הנתונים דרך המסך עצמו ולא ישירות לטבלאות. לפי תיעוד ה-SDK, מגרסה 26.0 ממשקי טעינה מפעילים את כל הטריגרים הרלוונטיים של המסך, כאילו משתמש הקליד את הנתונים (תיעוד ה-SDK).

זה מתאים לטעינות מרוכזות: מחירון חדש, קליטת תנועות מהמחסן בסוף יום, או הסבת נתונים ממערכת קודמת.

4. רכיב מוכן — לפעמים זה מספיק

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

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

הדבר שלא עושים: לכתוב ישר לטבלאות

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

קריאה היא סיפור אחר. לדוחות ול-BI, Priority מציע חיבור ODBC לכלים חיצוניים, שנותן גישה לנתונים ושומר על שכבת הלוגיקה העסקית (Priority). על החיבור ל-Power BI כתבתי בנפרד.

אז מה בוחרים

ברוב החיבורים התשובה היא שילוב. זו נקודת ההתחלה שלי לכל מצב:

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