מערכת SAP כמעט אף פעם לא עובדת לבד. בארגון ממוצע היא מחוברת למערכות פיננסיות, אתרי אינטרנט, מערכות CRM, מערכות שכר, בנקים, מערכות לוגיסטיקה, מחסנים, מערכות BI, אפליקציות, ספקים ולעיתים גם לשירותים חיצוניים בענן.

מבחינת QA, זו בדיוק הנקודה שבה בדיקות אינטגרציה הופכות לקריטיות.

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

בדיקות אינטגרציה ב־SAP נועדו לוודא לא רק ש"ממשק עובד", אלא שהמידע עובר בצורה נכונה, מלאה, עקבית ובזמן הנכון בין המערכות.

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

מהן בדיקות אינטגרציה ב־SAP?

בדיקות אינטגרציה הן בדיקות שבוחנות את התקשורת והעברת המידע בין SAP לבין מערכת אחרת.

לדוגמה:

SAP → מערכת בנקאית

SAP מייצר קובץ תשלומים → הקובץ נשלח לבנק → הבנק מעבד אותו → מתקבלת תשובה → SAP מעדכן את סטטוס התשלום.

או:

מערכת מסחר → SAP

מערכת חיצונית שולחת הזמנה → SAP מקבל את הנתונים → נוצרת הזמנה במערכת → הנתונים החשבונאיים והלוגיסטיים מתעדכנים.

לכן, בדיקת אינטגרציה אינה מסתכמת בשאלה:

"האם ההודעה הגיעה?"

צריך לבדוק גם:

• האם היא הגיעה בזמן?
• האם כל השדות הגיעו?
• האם הערכים נכונים?
• האם הפורמט נכון?
• האם SAP פירש את הנתונים נכון?
• האם נוצר האובייקט העסקי המתאים?
• מה קורה במקרה של שגיאה?
• האם נוצרה הודעת שגיאה?
• האם המערכת מבצעת ניסיון חוזר?
• האם נוצרו כפילויות?
• האם המשתמש יכול לזהות ולתקן את התקלה?

למה בדיקות אינטגרציה ב־SAP מורכבות יותר מבדיקה רגילה?

בבדיקה פונקציונלית רגילה אפשר לעיתים להסתפק בזרימה:

קלט → פעולה → תוצאה

בממשק SAP יש בדרך כלל שרשרת ארוכה יותר:

מערכת מקור → ממשק → שכבת אינטגרציה → SAP → עיבוד עסקי → מערכת יעד

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

אתר → API → Middleware → SAP → מערכת פיננסית → BI

במקרה כזה, תקלה יכולה להתרחש כמעט בכל שלב.

לדוגמה, אם הזמנה לא מופיעה ב־SAP, הבעיה יכולה להיות:

1. האתר לא שלח את ההזמנה.
2. ה־API החזיר שגיאה.
3. ה־Middleware לא העביר את ההודעה.
4. ההודעה נשלחה בפורמט שגוי.
5. SAP דחה את הנתונים.
6. הנתונים נקלטו אך נוצרה שגיאה עסקית.
7. הנתונים נקלטו אך לא נוצר המסמך הצפוי.
8. המסמך נוצר אך לא הועבר למערכת הבאה.

לכן QA של ממשקים צריך להבין את כל שרשרת המידע, ולא רק את המסך שמופיע בסוף.

אילו סוגי ממשקים קיימים בסביבת SAP?

בסביבת SAP אפשר לפגוש מגוון רחב של מנגנוני אינטגרציה.

בין היתר:

• API
• REST
• SOAP
• OData
• IDoc
• RFC
• BAPI
• קבצים
• CSV
• XML
• JSON
• ממשקי בנקים
• ממשקי Middleware
• אינטגרציות באמצעות SAP PI/PO
• SAP Integration Suite
• ממשקים ישירים בין מערכות
• תהליכים אצווהיים (Batch)

לכל סוג ממשק יש מאפייני בדיקה מעט שונים.

לדוגמה, ב־REST API חשוב לבדוק HTTP status codes, headers, authentication ו־JSON.

ב־IDoc חשוב לבדוק את מבנה ההודעה, הסגמנטים, הסטטוסים והטיפול בשגיאות.

בממשק קובץ חשוב לבדוק את שם הקובץ, המבנה, encoding, delimiter, מיקום הקובץ, תזמון וקריאה חוזרת.

השלב הראשון: להבין את הארכיטקטורה

לפני שכותבים אפילו Test Case אחד, כדאי להבין איך הממשק עובד.

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

צריך לבנות תמונה פשוטה של הזרימה.

לדוגמה:

מערכת CRM
     ↓
    API
     ↓
Middleware
     ↓
    SAP
     ↓
מסמך מכירה
     ↓
מערכת פיננסית

לאחר מכן יש לשאול:

• מי שולח את הנתונים?
• מי מקבל אותם?
• באיזה פרוטוקול משתמשים?
• האם יש Middleware?
• האם הממשק סינכרוני או אסינכרוני?
• האם יש Queue?
• האם יש Retry?
• מהו זמן העיבוד הצפוי?
• איפה ניתן לראות Log?
• איפה ניתן לראות שגיאות?
• מהו מזהה העסקה?
• איך יודעים שההודעה עובדה בהצלחה?

המידע הזה צריך להיות חלק מתכנון הבדיקות.

בדיקות Inbound מול Outbound

אחת החלוקות החשובות בבדיקות SAP היא בין ממשקים נכנסים לממשקים יוצאים.

Inbound

בממשק Inbound הנתונים מגיעים אל SAP.

לדוגמה:

אתר → SAP

או:

CRM → SAP

במקרה כזה צריך לבדוק:

• האם SAP קיבל את ההודעה?
• האם המבנה תקין?
• האם הנתונים עברו Mapping נכון?
• האם נוצר האובייקט העסקי?
• האם כל השדות החשובים עודכנו?
• האם נתונים לא חוקיים נדחו?
• האם התקבלה הודעת שגיאה מתאימה?

Outbound

בממשק Outbound SAP שולח נתונים למערכת חיצונית.

לדוגמה:

SAP → בנק

או:

SAP → מערכת BI

כאן צריך לבדוק:

• האם SAP יצר את ההודעה?
• האם כל הנתונים הנדרשים נשלחו?
• האם הפורמט תקין?
• האם הנתונים תואמים למקור?
• האם המערכת החיצונית קיבלה את הנתונים?
• האם SAP קיבל Confirmation?
• מה קורה אם המערכת החיצונית אינה זמינה?

בדיקת Mapping – אחת הבדיקות החשובות ביותר

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

כלומר, ההתאמה בין שדה במערכת אחת לשדה במערכת אחרת.

לדוגמה:

צריך לבדוק לא רק שהשדות קיימים, אלא שהערך הנכון עובר ביניהם.

לדוגמה:

מערכת מקור:
Currency = ILS
SAP:
WAERS = ILS

אם במקום זאת מתקבל:

WAERS = USD

הממשק יכול להיחשב "תקין טכנית", אבל התהליך העסקי שגוי.

זו דוגמה מצוינת להבדל בין בדיקה טכנית לבין בדיקה עסקית.

בדיקות שדות בממשק

לכל שדה משמעותי כדאי להגדיר לפחות כמה סוגי בדיקות.

בדיקת ערך תקין

לדוגמה:

Currency = ILS

ערך חסר

Currency = NULL

ערך לא חוקי

Currency = ABC

אורך שדה

אם שדה מוגבל ל־10 תווים:

1234567890

צריך לבדוק גם:

12345678901

תווים מיוחדים

לדוגמה:

ישראל & שותפים

עברית

חשוב במיוחד בסביבות ישראליות לבדוק:

• עברית
• אנגלית
• מספרים
• שילוב עברית ואנגלית
• תווים מיוחדים

בדיקת תאריכים

תאריכים הם מקור קלאסי לתקלות בממשקים.

מערכת אחת יכולה לשלוח:

14/09/2026

והמערכת השנייה לצפות ל:

2026-09-14

או:

20260914

צריך לבדוק גם:

• תאריך תקין
• תאריך עתידי
• תאריך עבר
• סוף חודש
• סוף שנה
• שנה מעוברת
• ערך ריק
• פורמט שגוי

בנוסף, במערכות בינלאומיות צריך לבדוק Time Zone.

בדיקות סכומים ומטבעות

במערכות ERP זו בדיקה קריטית.

נניח שמערכת המקור שולחת:

Amount = 1,250.50
Currency = ILS

צריך לוודא שב־SAP מתקבל בדיוק אותו סכום ובהתאם לכללי העיגול שהוגדרו.

יש לבדוק גם:

• מספרים שליליים
• אפס
• סכום גדול
• ספרות עשרוניות
• עיגול
• המרת מטבע
• שער חליפין
• מטבע חסר
• הפרשי אגורות

בדיקת IDoc ב־SAP

IDoc הוא מנגנון נפוץ מאוד בסביבות SAP, ולכן QA שעובד בפרויקטי SAP צריך להכיר לפחות את עקרונות הבדיקה שלו.

בבדיקת IDoc חשוב לבדוק:

1. האם ה־IDoc נוצר?
2. האם הוא התקבל?
3. האם הסטטוס תקין?
4. האם כל הסגמנטים הנדרשים קיימים?
5. האם הערכים נכונים?
6. האם יש שגיאה באחד הסגמנטים?
7. האם נוצר המסמך העסקי?

לדוגמה, ייתכן שה־IDoc עצמו התקבל בהצלחה, אבל במהלך העיבוד נוצרת שגיאה עסקית.

לכן:

IDoc התקבל ≠ התהליך העסקי הצליח.

זו נקודה חשובה מאוד בבדיקות SAP.

בדיקת API בין SAP למערכת חיצונית

כאשר SAP מתקשר באמצעות API, כדאי לבדוק את הממשק בכמה שכבות.

שכבה ראשונה – תקשורת

• האם ניתן להתחבר?
• האם ה־Endpoint זמין?
• האם authentication עובד?
• האם authorization תקין?

שכבה שנייה – מבנה

• האם JSON/XML תקין?
• האם כל השדות קיימים?
• האם datatype נכון?
• האם שדות חובה קיימים?

שכבה שלישית – נתונים

• האם הנתונים נכונים?
• האם Mapping תקין?
• האם הערכים העסקיים נכונים?

שכבה רביעית – תוצאה

• האם SAP ביצע את הפעולה?
• האם נוצר המסמך?
• האם המערכת החיצונית קיבלה תשובה?

בדיקות חיוביות ושליליות

בדיקות אינטגרציה טובות לא בודקות רק את ה־Happy Path.

צריך לבדוק גם מה קורה כאשר הדברים משתבשים.

לדוגמה:

תרחיש תקין

מערכת חיצונית שולחת לקוח חדש.

Expected Result:

הלקוח נוצר ב־SAP עם כל הנתונים הנדרשים.

תרחיש שלילי

מערכת חיצונית שולחת לקוח ללא מספר מזהה.

Expected Result:

SAP דוחה את הרשומה ומחזיר שגיאה ברורה.

מה קורה כאשר SAP לא זמין?

זהו Test Case חשוב מאוד.

נניח שהמערכת החיצונית שולחת 500 הזמנות בזמן ש־SAP אינו זמין.

צריך לדעת:

• האם ההודעות נשמרות?
• האם הן אובדות?
• האם מתבצע Retry?
• כמה פעמים?
• באיזה מרווח?
• האם נוצרת התראה?
• האם לאחר חזרת SAP ההודעות מעובדות?
• האם הודעה יכולה להיקלט פעמיים?

בדיקת כפילויות

Duplicate הוא אחד הסיכונים המשמעותיים בממשקים.

נניח שמערכת חיצונית שולחת הזמנה:

Order 12345

התקבלה שגיאת Timeout.

המערכת אינה יודעת אם SAP כבר קיבל את ההזמנה ולכן שולחת אותה שוב.

עכשיו SAP מקבל:

Order 12345
Order 12345

צריך לבדוק האם המערכת יודעת לזהות שמדובר באותה עסקה.

זה נקרא לעיתים Idempotency – היכולת לעבד אותה בקשה יותר מפעם אחת בלי ליצור תוצאה עסקית כפולה.

בדיקות Retry

במערכות אינטגרציה רבות קיימת יכולת Retry.

לדוגמה:

ניסיון 1 → נכשל
ניסיון 2 → נכשל
ניסיון 3 → הצליח

QA צריך לבדוק:

• כמה ניסיונות מתבצעים?
• מהו הזמן בין הניסיונות?
• האם כל שגיאה גורמת ל־Retry?
• האם שגיאה עסקית גורמת ל־Retry?
• מה קורה לאחר מספר ניסיונות כושלים?
• האם נוצרת התראה?
• האם המשתמש יכול לבצע Reprocess?

חשוב להבדיל בין:

שגיאת תקשורת

לבין:

שגיאה עסקית.

לדוגמה, אם השרת לא זמין, Retry עשוי להיות הגיוני.

אבל אם חסר מספר לקוח, שליחה חוזרת של אותה הודעה לא בהכרח תפתור את הבעיה.

בדיקת תהליך עסקי End-to-End

בדיקת ממשק בפני עצמה אינה מספיקה.

צריך לבדוק גם את התהליך העסקי המלא.

לדוגמה, בתהליך הזמנה:

לקוח מבצע הזמנה
        ↓
מערכת Web
        ↓
API
        ↓
SAP
        ↓
יצירת Sales Order
        ↓
אספקה
        ↓
חשבונית
        ↓
מערכת פיננסית

ה־QA צריך לוודא שכל השרשרת עובדת.

זו בדיוק הסיבה שבדיקות E2E חשובות כל כך בפרויקטי SAP.

באתר כבר יש מדריך בנושא בדיקות E2E ומה זה E2E Testing, והוא יכול לשמש בסיס להבנת ההבדל בין בדיקת רכיב לבין בדיקת התהליך המלא.

בדיקות אינטגרציה לעומת בדיקות מערכת SAP

חשוב להבדיל בין שני סוגי בדיקות.

בדיקת מערכת SAP יכולה לבדוק:

האם SAP יוצר הזמנה בצורה נכונה?

בדיקת אינטגרציה שואלת:

האם ההזמנה שנוצרה במערכת החיצונית הגיעה ל־SAP בצורה נכונה?

בדיקת E2E שואלת:

האם כל התהליך, מהפעולה של המשתמש ועד התוצאה העסקית הסופית, עובד?

לכן בפרויקט SAP רציני כדאי לשלב את שלושת הרבדים.

בדיקות ממשקים בפרויקט שדרוג SAP

ממשקים הם אחד התחומים הרגישים ביותר בשדרוג SAP.

כאשר מבצעים Upgrade או מעבר לגרסה חדשה, לא מספיק לבדוק שהמסכים עובדים.

צריך לבדוק גם את כל הממשקים הקיימים.

לדוגמה:

• ממשקי בנקים
• ממשקי לקוחות
• ממשקי ספקים
• מערכות CRM
• מערכות BI
• מערכות שכר
• מערכות לוגיסטיות
• מערכות ממשלתיות
• APIs
• קבצים
• IDocs

באתר ניתן לקרוא גם את המדריך בנושא בדיקות שדרוג גרסת SAP ומה חייבים לבדוק לפני העלייה לייצור.

בנוסף, חשוב לבדוק את הממשקים גם במהלך בדיקות שדרוג ועדכון גרסה ב־SAP.

בדיקות לאחר הסבת נתונים

גם בפרויקטי Data Migration הממשקים יכולים להיות מושפעים.

לדוגמה:

מערכת ישנה
    ↓
הסבת נתונים
    ↓
SAP חדש
    ↓
מערכות חיצוניות

אם Customer ID השתנה, לדוגמה, צריך לוודא שכל המערכות שמסתמכות עליו עדיין מסוגלות לזהות את הלקוח.

באתר יש מדריך ייעודי בנושא הסבת נתונים ב־SAP: מה זה, איך בודקים ומהן הטעויות הנפוצות.

בדיקות נפח וביצועים לממשקים

ממשק שעובד עבור עסקה אחת לא בהכרח יעבוד עבור 100,000 עסקאות.

לכן כדאי לבצע גם בדיקות עומס ונפח.

לדוגמה:

10 הודעות
100 הודעות
1,000 הודעות
10,000 הודעות

יש לבדוק:

• זמן עיבוד
• זמני תגובה
• Queue
• זמני המתנה
• שיעור שגיאות
• צריכת משאבים
• הצטברות הודעות
• Recovery לאחר עומס

צריך לשאול גם:

מה קורה אם המערכת מקבלת את כל הודעות סוף החודש בבת אחת?

זו שאלה רלוונטית במיוחד במערכות פיננסיות ו־ERP.

בדיקות אבטחה בממשקים

גם QA צריך להתייחס להיבטי אבטחה.

בין היתר:

• Authentication
• Authorization
• Tokens
• Certificates
• הרשאות משתמש
• גישה ל־API
• נתונים רגישים
• הצפנת תקשורת
• חשיפה של מידע ב־Logs

צריך לבדוק למשל שמשתמש או מערכת ללא הרשאה מתאימה אינם יכולים לשלוח מידע ל־SAP או לקבל מידע שאינם אמורים לראות.

בדיקות Logging ו־Monitoring

אחד הדברים החשובים ביותר בממשק הוא היכולת להבין מה קרה כאשר משהו השתבש.

ממשק טוב מבחינת QA הוא לא רק ממשק שעובד.

הוא ממשק שאפשר לאבחן כאשר הוא לא עובד.

צריך לבדוק:

• האם נוצר Log?
• האם ניתן לזהות את העסקה?
• האם מופיע Timestamp?
• האם מופיע Error Code?
• האם מופיע מקור התקלה?
• האם ניתן לבצע Reprocess?
• האם נוצרת התראה?

לדוגמה, הודעת שגיאה כמו:

Error occurred

אינה מועילה במיוחד.

לעומת:

Customer 45872 rejected:
Missing mandatory field: Country

שמאפשרת לצוות להבין מה קרה.

טבלת Test Cases מומלצת

אפשר להתחיל מתבנית כזו:

Checklist לבדיקות אינטגרציה ב־SAP

לפני אישור ממשק לייצור, כדאי לעבור לפחות על הרשימה הבאה:

תקשורת

• Endpoint זמין
• Authentication עובד
• Authorization תקין
• Timeout מוגדר
• Retry נבדק

נתונים

• Mapping נבדק
• שדות חובה נבדקו
• ערכים תקינים נבדקו
• ערכים לא תקינים נבדקו
• תאריכים נבדקו
• סכומים נבדקו
• מטבעות נבדקו
• עברית נבדקה

תהליך עסקי

• המסמך נוצר ב־SAP
• הנתונים העסקיים נכונים
• הסטטוס נכון
• המידע עובר למערכת הבאה
• התהליך End-to-End תקין

תקלות

• מערכת מקור אינה זמינה
• SAP אינו זמין
• מערכת יעד אינה זמינה
• Timeout
• Duplicate
• נתונים שגויים
• הודעה חלקית
• Retry
• Reprocess

ניטור

• Log קיים
• Error ברור
• Transaction ID קיים
• ניתן לאתר את העסקה
• קיימת אפשרות לטיפול בתקלה

הטעות הגדולה ביותר בבדיקות ממשקים

הטעות הנפוצה ביותר היא לבדוק רק את השאלה:

"האם הממשק עבר?"

זו שאלה טכנית מדי.

השאלה החשובה יותר היא:

האם התהליך העסקי כולו הסתיים בצורה נכונה?

לדוגמה, אם מערכת חיצונית שולחת הזמנה ו־SAP מחזיר HTTP 200, זה עדיין לא מוכיח שההזמנה נוצרה בצורה תקינה.

יכול להיות שהתקבלה תשובה טכנית חיובית, אבל:

• לקוח שגוי נבחר
• מטבע שגוי
• מחיר שגוי
• חומר שגוי
• כמות שגויה
• מסמך לא נוצר
• נתון מסוים לא עודכן

לכן בדיקות אינטגרציה מקצועיות צריכות לחבר בין הבדיקה הטכנית לבין הבדיקה העסקית.

איך לבנות אסטרטגיית בדיקות נכונה?

אני ממליץ לעבוד בשלושה שלבים.

שלב 1 – בדיקת הממשק

בודקים:

• תקשורת
• מבנה
• Mapping
• שדות
• שגיאות

שלב 2 – בדיקת SAP

בודקים:

• קליטת הנתונים
• עיבוד
• יצירת מסמך
• עדכון נתונים
• סטטוס

שלב 3 – בדיקת End-to-End

בודקים את כל התהליך:

מערכת מקור
     ↓
ממשק
     ↓
SAP
     ↓
עיבוד עסקי
     ↓
מערכת יעד
     ↓
תוצאה עסקית

רק כאשר שלושת השלבים תקינים אפשר לקבל ביטחון אמיתי באיכות האינטגרציה.

ומה לגבי אוטומציה?

לא כל בדיקת SAP חייבת להתבצע ידנית.

אפשר לבצע אוטומציה לחלקים משמעותיים מהבדיקות, במיוחד כאשר מדובר בממשקים עם API, קבצים או תהליכים שחוזרים על עצמם.

כלים כמו Postman יכולים לסייע בבדיקת APIs, בעוד שכלי אוטומציה יכולים לבצע תרחישים חוזרים ולבדוק תוצאות.

באתר יש גם מדריכים על Playwright למתחילים ועל השוואת Playwright, Cypress ו־Selenium, שיכולים להרחיב את הידע בנושא אוטומציה.

סיכום

בדיקות אינטגרציה ב־SAP הן הרבה יותר מבדיקה שהודעה עברה ממערכת אחת לאחרת.

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

QA מקצועי בממשקי SAP צריך לחשוב על כל שרשרת התהליך:

מערכת מקור → תקשורת → ממשק → SAP → עיבוד → מערכת יעד → תוצאה עסקית.

הבדיקות החשובות ביותר כוללות Mapping, שדות חובה, ערכים לא תקינים, IDoc/API, Timeout, Retry, כפילויות, נפחים, שגיאות, Logging ובדיקות End-to-End.

ובעיקר – לא להסתפק ב־"הממשק ירוק".

ממשק שעבר טכנית אבל העביר נתון עסקי שגוי הוא ממשק שנכשל.

זו בדיוק הסיבה שבפרויקטי SAP משמעותיים כדאי לשלב בדיקות אינטגרציה כבר בשלבי התכנון, ולא להמתין לסוף הפרויקט כדי לגלות שמערכות שלמות בארגון תלויות בממשק שלא נבדק מספיק.

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

קורס לבדיקות תוכנה מדויק

לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן