שגיאת 403 עקב אסימון CSRF או פסק זמן של סשן בעת שילוב SAP עם אפליקציה ניידת היא בעיה אופיינית שגם צוותים מנוסים נתקלים בה. כמעט כל פרויקט שני מגיע אלינו לאחר ניסיון כושל "לעשות את זה לבד". שילוב אפליקציות ניידות עם SAP, בין אם באמצעות SAP OData mobile, SAP BAPI mobile או פרוטוקולים אחרים, דורש הבנה של סביבת SAP: גרסאות שונות (ECC 6.0, S/4HANA on-premise או Cloud), פרוטוקולים (OData v2, v4, BAPI) ודרישות אבטחה (OAuth 2.0, SAML). עם ניסיון של למעלה מ-10 שנים ויותר מ-30 פרויקטים מוצלחים, פיתחנו גישה מהירה פי 3 מבניית middleware משלכם. הלקח המרכזי: אל תתחילו לקודד ללא ביקורת API ובחירה נכונה של middleware — טעות שעולה בשבועות של עבודה חוזרת. ביקורת אופיינית עולה $2,000 ואורכת 3-5 ימים.
SAP Mobile Services אינו רק middleware אלא פלטפורמה מלאה שמאיצה את השילוב פי 3 בזכות מנגנוני caching, אימות וסנכרון לא מקוון מובנים. בניגוד לפתרונות Spring Boot מותאמים אישית, היא מבטלת את הצורך בטיפול ידני באסימוני CSRF, ניהול סשנים ופתרון קונפליקטים. אבל הגדרה נכונה היא חיונית: טעות נפוצה היא התעלמות ממדיניות סנכרון, מה שמוביל לאובדן נתונים בעת ניתוק חיבור. להודעות push, אנו משתמשים ב-Firebase Cloud Messaging (FCM) באנדרואיד וב-Apple Push Notification Service (APNs) ב-iOS, המשולבים עם SAP Mobile Services.
שלושה דורות של SAP API: השוואה
| דור | פרוטוקול | מתי להשתמש |
|---|---|---|
| BAPI / RFC | ABAP, דרך JCo/NCo | SAP ECC legacy, אם אין Gateway |
| SAP Gateway / OData v2 | REST, Atom XML/JSON | ECC 6.0, NetWeaver, S/4HANA on-premise |
| SAP BTP + CAP (OData v4) | REST, JSON | S/4HANA Cloud, פרויקטים חדשים |
כיצד להגדיר טיפול ב-CSRF באפליקציה ניידת?
התהליך הסטנדרטי עם אסימון CSRF ב-SAP OData כולל ארבעה שלבים. ראשית, בצעו בקשת GET לנקודת הקצה של השירות עם הכותרת X-CSRF-Token: Fetch. SAP מחזירה את האסימון בכותרת התגובה X-CSRF-Token. עבור כל הבקשות המשנות (POST, PUT, DELETE, PATCH), כללו את האסימון שהתקבל בכותרת X-CSRF-Token. בעת קבלת 403 CSRF token validation failed, חזרו על שלבים 1-3. אנו מיישמים אלגוריתם זה ב-Interceptor על Retrofit או Alamofire, ומחדשים את האסימון אוטומטית בעת שגיאה. האסימון תקף בתוך סשן, ולכן לאחר אימות מחדש, יש לקבל אסימון חדש. זה מבטל 90% משגיאות ההרשאה.
דוגמה באמצעות ה-SDK באנדרואיד:
val serviceManager = ServiceManager(
applicationContext,
SAPServiceManager.configUrl,
object : ServiceManager.ServiceManagerListener {
override fun onServiceManagerReady() {
// Готов к работе
initializeODataService()
}
}
)כיצד ליישם סנכרון לא מקוון עם SAP?
שימוש ב-OData Offline Store מ-SAP BTP SDK מפחית את צריכת הנתונים הניידת ב-60-70% בהשוואה לחיבור קבוע. לפי התיעוד הרשמי של SAP BTP SDK, סנכרון לא מקוון דורש הגדרת מדיניות קונפליקטים. הנתונים נשמרים במטמון מקומי ב-SQLite, וכאשר הרשת זמינה, מתבצע סנכרון דו-כיווני. קונפליקטים נפתרים באמצעות ETag — השרת בודק אם הנתונים השתנו מאז הקריאה האחרונה. עם זאת, מצב לא מקוון מגדיל את מורכבות השילוב: יש להגדיר כראוי מדיניות סנכרון. אנו בוחרים באסטרטגיית first writer או server version בהתאם ללוגיקה העסקית.
שיטות אימות: SAML לעומת OAuth
| שיטה | פרוטוקול | מתי להשתמש |
|---|---|---|
| SAML 2.0 | מבוסס XML, דפדפן | SAP ECC על NetWeaver |
| OAuth 2.0 | JWT, דרך Authorization Code | S/4HANA Cloud, SAP BTP |
| Basic Auth | HTTP Basic | רק לבדיקות |
אנו ממליצים להוסיף פרוקסי OAuth 2.0 דרך SAP BTP או Keycloak: האפליקציה הניידת משתמשת ב-OAuth סטנדרטי, בעוד SAP מקבלת בקשות SAML. זה מפחית את שבריריות השילוב.
מלכודות נפוצות ופתרונות
- ביצועי OData v2.
val serviceManager = ServiceManager( applicationContext, SAPServiceManager.configUrl, object : ServiceManager.ServiceManagerListener { override fun onServiceManagerReady() { // Готов к работе initializeODataService() } } )עבור מאפייני ניווט מבצע JOINs בצד SAP ABAP — עשוי לקחת 5-15 שניות. חלופה: בקשות מקבילות ללא expand או caching ב-middleware. - פאג'ינג ב-OData v2.
$expand+$skipאיטי על נפחים גדולים — עדיף פאג'ינג בצד השרת באמצעות SAP skiptoken. - הבדלים בין S/4HANA ל-ECC. ה-APIs לאותו אובייקט (לדוגמה, הזמנת מכירה) ב-S/4HANA OData (
$top) וב-ECC Gateway (API_SALES_ORDER_SRV) שונים. שכבת הפשטה ב-middleware היא חובה לתמיכה בשניהם.
בחירת API לשילוב
אם ללקוח יש S/4HANA Cloud, OData v4 דרך CAP היא הבחירה הברורה. אם יש ECC או S/4HANA on-premise, בדקו אם קיים SAP Gateway. Gateway מספק SAP ECC OData v2 אך עם מוזרויות: ZSHOP_SRV במקום ISO 8601, סינון ספציפי, Edm.DateTime עבור מאפייני ניווט. עבור ECC ללא Gateway, BAPI דרך middleware (SAP JCo או NCo) נשאר אפשרות. שכבת הפשטה ב-middleware היא חובה אם יש צורך בתמיכה בשני הווריאנטים. עבור אפליקציה ניידת SAP חזקה, סנכרון לא מקוון הוא חיוני. שילוב ERP נייד, ובמיוחד SAP, הוא מורכב.
מה כלול בעבודה
- תיעוד ארכיטקטורת API ושילוב
- גישה ל-SAP BTP או middleware (במידת הצורך)
- הכשרת צוות הלקוח לתפעול הפתרון
- 3 חודשי תמיכת אחריות לאחר הפריסה
תהליך העבודה
- ביקורת סביבת SAP ו-APIs זמינים — 3-5 ימים. קביעת גרסת SAP, בדיקת זמינות OData Gateway או BAPI, בדיקת ביצועים.
- עיצוב ארכיטקטורת השילוב — 1-2 שבועות. בחירת מחסנית (BTP SDK, אסטרטגיית offline, שיטת אימות).
- יישום אב טיפוס — 1-2 שבועות. קריאת נתונים, הגדרת אימות, סנכרון בסיסי.
- שילוב מלא — 2-4 חודשים. הוספת תמיכה ב-offline, טיפול ב-CSRF, פתרון קונפליקטים, הודעות push.
- תיעוד והכשרת צוות — 1-2 שבועות. העברת תיעוד API, תצורה ותפעול.
- תמיכת אחריות — 3 חודשים לאחר הפריסה. תיקון שגיאות, סיוע בשינויים.
העלות מחושבת באופן אישי לאחר הביקורת. הזמינו אב טיפוס תוך שבועיים — נראה פתרון עובד על הנתונים שלכם. צרו קשר לביקורת של סביבת ה-SAP שלכם וקבלו תוכנית שילוב מפורטת. אנו מבטיחים הפחתה של עד 50% בעלויות השילוב בהשוואה לפתרונות עצמאיים.