לא רשימת פיצ'רים - השוואה של איך זה באמת להתחבר לכל אחת מהמערכות. מודלי אימות, איך מגלים את הסכימה האמיתית, מגבלות אצווה, דחיפת אירועים, והשאלות שקובעות מה מתאים.
עיקרי הדברים
- לשתיהן יש API אמיתי ומתועד. ההבדל אינו ביכולת - הוא בצורת מודל האימות ובכמה התאמות ספציפיות להתקנה צריך לגלות לפני שכותבים קוד.
- פריוריטי משתמשת ב-Basic חסר-מצב או בטוקן; SAP B1 משתמשת ב-session מצבי של 30 דקות עם שתי עוגיות. מודל SAP עולה לך בטיפול בהתחברות מחדש בכל תהליך ארוך.
- לפריוריטי יש מנגנון webhook יוצא מובנה דרך כללי BPM. אם אתה צריך שה-ERP ידחוף אירועים במקום שתתשאל אותו, זה הבדל ארכיטקטוני אמיתי.
- בשתיהן, מה שמתחברים אליו הוא ההתקנה ולא המוצר. טפסים, שדות ו-UDF מותאמים גורמים לכך ששני לקוחות על אותה גרסה יכולים לדרוש קוד שונה - ולכן קוראים את המטא-דאטה לפני שמתמחרים.
ההשוואה הזו לא עוסקת בפיצ'רים, במודולים או במחיר רישוי - שלושתם משתנים לפי ההסכם הספציפי ולפי הסוכן שמטמיע. היא עוסקת בשאלה שקובעת את התקציב האמיתי של הפרויקט: איך זה להתחבר לכל אחת מהן.
מודל האימות - ההבדל המעשי הגדול ביותר
| Priority | SAP Business One | |
|---|---|---|
| שיטה | HTTP Basic, או Personal Access Token מגרסה 19.1, או OAuth2 עם רישיון External ID | POST ל-/Login עם משתמש, סיסמה ו-CompanyDB |
| מצב | חסר מצב - כל קריאה נושאת את פרטי האימות | מצבי - session עם עוגיות |
| פקיעה | אין session שפג | 30 דקות חוסר פעילות, שגיאה -5002 |
מה זה אומר בפועל: ב-Priority, קריאה בודדת מ-cron או מ-worker היא קריאה בודדת. ב-SAP B1, כל תהליך שרץ יותר מחצי שעה חייב מנגנון שתופס את -5002 ומתחבר מחדש - וגם צריך להחזיק session אחד ולא להתחבר בכל קריאה, כי יש מגבלה על sessions מקבילים למשתמש.
נוסף לכך, ב-SAP B1 מוחזרת עוגיית ROUTEID לצד B1SESSION. מאחורי מאזן עומסים היא זו שמנתבת חזרה למופע הנכון, ולקוח HTTP שמתעלם ממנה יסבול מכשלי אימות אקראיים. זו לא בעיה קשה, אבל היא עולה יום ניפוי שגיאות למי שלא מכיר אותה מראש.
נקודה שקל לפספס ב-Priority: אי אפשר להשתמש ב-Basic Authentication בזמן שגישת External ID מופעלת. הפעלת External ID מסיבה שאין לה קשר אליך תשבור אינטגרציה שרצה שנה.
גילוי הסכימה
בשתי המערכות, מה שמתחברים אליו הוא ההתקנה, לא המוצר. שני לקוחות על אותה גרסה יכולים לדרוש קוד שונה לגמרי, בגלל טפסים ושדות שנוספו לאורך השנים.
- Priority: נקודת הקצה
/$metadataמחזירה את הסכימה המלאה של אותה התקנה - ישויות, שדות, טיפוסים וקשרים. - SAP B1: אותו עיקרון דרך המטא-דאטה של ה-Service Layer, עם שדות משתמש (UDF) ואובייקטים מותאמים שנצברים בהתקנה.
בשני המקרים המסקנה זהה ומעשית: אל תתמחר אינטגרציה בלי גישה לסכימה של ההתקנה הספציפית. תשובה שמצאת בפורום על שם שדה נכונה עבור ההתקנה של מי שכתב אותה.
דחיפת אירועים - כאן יש הבדל אמיתי
לפריוריטי יש מנגנון Webhooks מובנה: מגדירים נקודת קצה בטופס ייעודי, ואז כלל BPM בתרשים הזרימה של המסמך מפעיל אותה בשינוי סטטוס. הקריאה היוצאת נושאת כותרות מזהות וטוקן אימות.
המשמעות: כשצריך עדכון בזמן אמת - לקוח שמקבל הודעה ברגע שנוצרה תעודת משלוח, למשל - Priority מציעה נתיב מובנה. חשוב לסייג: נדרש רישיון מודול Webhooks, אין מדיניות retry מתועדת, ויומן השגיאות נשמר 7 ימים בלבד - ולכן גם שם צריך תהליך השלמה יומי.
ב-SAP B1 המודל הרווח הוא תשאול מתוזמן. אפשר לבנות דחיפה, אבל זה מגיע מחוץ ל-Service Layer עצמו.
שאלה מעשית לאפיון: האם התהליך שאתה רוצה לתפוס מתבטא במעבר סטטוס של מסמך? אם כן, המנגנון של Priority מתאים לו ישירות. אם לא - גם שם תצטרך לתשאל, וההבדל מצטמצם.
כתיבה ומגבלות
| Priority | SAP Business One | |
|---|---|---|
| יצירת מסמך עם שורות | בקשה אחת, מערך תת-טופס מקונן | בקשה אחת, שורות מקוננות |
| אצווה | עד 100 בקשות בקריאה (היה 1,000 לפני גרסה 21.0) | יש הגבלה, לבדוק מול הגרסה |
| מלכודת ידועה | אי אפשר PATCH לפי מפתח אוטומטי | session שפג באמצע תהליך ארוך |
| פורמט שגיאות | XML עם InterfaceErrors, גם ב-API של JSON | JSON עם קוד שגיאה מספרי |
שינוי האצווה בפריוריטי ראוי לתשומת לב: ייבוא שנכתב מול התקנה ישנה והסתמך על 1,000 יישבר אחרי שדרוג הלקוח לגרסה 21.0 ומעלה.
פורמט השגיאות של פריוריטי הוא מלכודת אמיתית: לקוח HTTP שמפרסר כל תשובה כ-JSON יראה כל שגיאת ולידציה כשגיאת פרסור, וההודעה המדויקת תיזרק. פירוט בשגיאות ה-REST API של פריוריטי.
מה באמת קובע את הבחירה
ברוב המקרים ההחלטה אינה מתקבלת על בסיס ה-API, וזה בסדר. השאלות שכן קובעות:
- מי מטמיע ומי מתחזק? זמינות הסוכן והיכרותו עם התחום שלך משפיעות על הפרויקט הרבה יותר מהבדלי הממשק.
- מה כבר קיים בעסק? מעבר בין ERPs הוא פרויקט נתונים גדול. אם אחת מהן כבר מותקנת, הרף לעבור לשנייה גבוה מאוד.
- האם צריכים אירועים בזמן אמת? אם כן, ה-webhooks של Priority הם יתרון מובנה.
- מי כותב את האינטגרציה? אם זה גורם חיצוני בלי גישה שוטפת למערכת, Priority מקלה בכך שהיא חסרת-מצב - אבל מקשה בכך שכל שינוי בכלל BPM דורש גישה פנימית.
מה שלא כדאי לעשות: לבחור ERP לפי ה-API. ה-API הוא עלות שולית בפרויקט הטמעה; התאמת התהליכים העסקיים והעברת הנתונים הן העיקר. אבל כן כדאי לתמחר את האינטגרציה אחרי שראית את ההתקנה - בשתי המערכות, הפער בין הערכה על סמך התיעוד להערכה על סמך הסכימה האמיתית הוא פער של פי כמה.
שאלות נפוצות
עם מי קל יותר להתחבר, פריוריטי או SAP Business One?
פריוריטי מעט פשוטה יותר כי האימות חסר-מצב - Basic או טוקן שנישא בכל קריאה - בעוד SAP B1 משתמשת ב-session שפג אחרי 30 דקות חוסר פעילות ומחזיר שגיאה 5002-, מה שמחייב טיפול בהתחברות מחדש בכל תהליך ארוך. לשתיהן יש API אמיתי ומתועד, ובשתיהן העלות הדומיננטית היא ההתאמות הספציפיות להתקנה ולא הממשק עצמו.
האם פריוריטי ו-SAP Business One יכולות לדחוף אירועים למערכת חיצונית?
לפריוריטי יש מנגנון webhook יוצא מובנה: נקודת קצה שמוגדרת תחת תחזוקת BPM, שמופעלת על ידי כלל BPM בשינוי סטטוס של מסמך. הוא דורש רישיון מודול Webhooks, אין לו מדיניות retry מתועדת, והוא שומר שגיאות שבעה ימים. ב-SAP Business One המודל הרווח הוא תשאול מתוזמן; אפשר לבנות דחיפה אבל היא מגיעה מחוץ ל-Service Layer.
למה שני לקוחות על אותה גרסת ERP יכולים לדרוש קוד אינטגרציה שונה?
כי גם פריוריטי וגם SAP Business One צוברות טפסים, שדות ושדות משתמש מותאמים לאורך שנות שימוש. מתחברים להתקנה, לא למוצר. יש לקרוא את הסכימה של ההתקנה עצמה - נקודת הקצה /$metadata של פריוריטי או המטא-דאטה של ה-Service Layer - לפני שכותבים קוד, ולעולם לא לתמחר אינטגרציה בלי הגישה הזו.
האם לבחור ERP לפי ה-API שלו?
לא. ה-API הוא עלות שולית בתוך פרויקט הטמעת ERP, שבו התאמת התהליכים, הסוכן המטמיע והעברת הנתונים הם העיקר. מה שהשוואת ה-API אמורה להשפיע עליו הוא הערכת האינטגרציה, לא ההחלטה על ה-ERP - וההערכה הזו צריכה להיווצר רק אחרי שרואים את הסכימה של ההתקנה בפועל.
להמשך קריאה
שירות רלוונטי
אינטגרציות
לגרום למערכות שאתם כבר משלמים עליהן לדבר זו עם זו.
על הכותב
יהונתן סעדיה
מהנדס פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מהנדס בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.