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

קטגוריה: אינטגרציות | תאריך: אוקטובר 2026

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

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

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

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

סדר יכול להשתנות כאשר:

• אירועים של אותה ישות נשלחים דרך תורים שונים.
• אירוע ישן נשלח שוב אחרי שאירוע חדש כבר נקלט.
• שירות אחד מפרסם מיד ושירות אחר רק בתום job מתוזמן.
• webhook פועל במקביל ל־polling או לסנכרון תקופתי.
• מערכת יעד מגבילה קצב וחלק מההודעות ממתינות.
• consumer חוזר לעבודה מתוך checkpoint ישן.

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

להתחיל ממכונת מצבים עסקית

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

עבור כל מעבר הגדירו:

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

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

לתת לכל ישות מזהה וגרסה יציבים

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

בנוסף, השתמשו במנגנון גרסה שאפשר להשוות:

• מספר גרסה שעולה בכל שינוי.
• sequence שמוקצה על ידי מקור סמכות אחד.
• offset מתוך stream שבו מובטח סדר לאותה ישות.
• מונה שינוי שנשמר עם הרשומה.

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

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

להפריד בין סדר מסירה לסדר יישום

התור מספר באיזה סדר הודעות נמסרו. התהליך העסקי קובע באיזה סדר מותר ליישם אותן. partition לפי מזהה ישות מצמצם שינויי סדר בתוך stream, אך אינו פותר אירוע שהתעכב לפני התור, עדכון משני מקורות, replay או פעולה ידנית במערכת היעד.

לכן consumer צריך לבדוק את מצב הישות ואת גרסת האירוע לפני היישום. אם גרסה 12 כבר יושמה, גרסה 10 אינה אמורה לדרוס אותה. היא יכולה להירשם כמאוחרת, להישמר לבדיקה או להפעיל מדיניות מיוחדת לפי סוג האירוע.

לבחור מדיניות לכל אירוע מאוחר

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

להתעלם ולתעד

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

ליישם באופן מצטבר

מתאים לאירוע שמוסיף עובדה, למשל מסמך או הערה. גם כאן נדרש idempotency כדי לא להוסיף אותו פעמיים.

לשמור עד השלמת פער

אם הגיעה גרסה 8 וגרסה 7 חסרה, אפשר להמתין זמן מוגדר. קבעו timeout, מגבלת buffer ומה קורה אם הגרסה החסרה לא מגיעה. המתנה ללא גבול יוצרת רשומות תקועות.

לבצע התאמה מול מקור האמת

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

להעביר לחריג עסקי

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

למנוע כפילות בנפרד מסדר

retry יכול להביא שוב אירוע ישן אחרי שהפעולה כבר הצליחה. שמרו מזהה אירוע או idempotency key ובדקו אותו לפני פעולה בעלת השפעה. בפעולות כמו יצירת מסמך או פתיחת משימה, עדיף שגם מערכת היעד תכבד את המפתח. בדיקה מקומית עלולה להיכשל אם הפעולה הצליחה אך התשובה אבדה.

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

להגדיר מקור אמת לכל החלטה

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

• איזו מערכת קובעת את סטטוס האישור.
• מי מוסמך לשנות פרטי קשר.
• איפה נקבע אם בקשה בוטלה.
• מי מנהל מסמכים וגרסאות.
• מה קורה לשינוי ממערכת שאינה הבעלים.

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

לבנות reconciliation שאינו תלוי באירוע יחיד

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

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

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

לתכנן replay לפני שצריכים אותו

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

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

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

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

ב־POC ובבדיקות קבלה הזרימו בכוונה:

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

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

שאלות נפוצות

האם תור FIFO פותר את הבעיה?

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

האם אפשר להסתמך על זמן האירוע?

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

מה עושים אם אירוע חסר לעולם לא מגיע?

ממתינים רק עד timeout מוגדר, ואז קוראים ממקור האמת או מעבירים לחריג. אין להשאיר buffer פתוח ללא בעלים ומועד טיפול.

האם כל אירוע ישן צריך להידחות?

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

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

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

Adaptico עוסקת ב[אינטגרציות, אוטומציה ופתרונות למערכות ארגוניות](/#services). אם תהליך קיים מקבל עדכונים מאוחרים, כפולים או סותרים, אפשר [לקבוע שיחת התאמה](/#contact) ולמפות את מכונת המצבים, מקור האמת ומדיניות ההתאמה עבור תהליך אחד.