איך להשתמש ב-correlation ID כדי לאתר בקשה שחוצה כמה מערכות

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

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

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

קודם להגדיר מה בדיוק עוקבים אחריו

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

כדאי להפריד בין כמה סוגי מזהים:

• מזהה עסקי: מספר הזמנה, בקשה, מסמך או לקוח שמוכר למשתמשים.
• correlation ID: מחבר את כל התחנות ששייכות למופע תהליך אחד.
• event ID או message ID: מזהה הודעה מסוימת, כולל אירועים חוזרים או מפוצלים.
• attempt ID: מבדיל בין ניסיונות retry של אותה פעולה.
• idempotency key: מונע מאותה פעולה עסקית ליצור השפעה כפולה.
• trace ID ו-span ID: משמשים כלי observability למדידת קריאות ותתי-פעולות.

לפעמים ערך אחד יכול לשרת יותר ממטרה אחת, אך לא כדאי להניח זאת אוטומטית. correlation ID שמתחלף בכל retry לא מאפשר לעקוב אחר המקרה כולו; idempotency key שמשותף לכל שלבי התהליך עלול להיות רחב מדי למניעת כפילות בפעולה מסוימת.

ליצור את המזהה בנקודת הכניסה הראשונה

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

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

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

להעביר את המזהה בכל גבול, לא רק בין שירותים סמוכים

המזהה שימושי רק אם הוא שורד את כל המעברים. בחיבור HTTP מקובל להעביר אותו ב-header מוסכם; בהודעות אסינכרוניות הוא נשמר במאפייני ההודעה או ב-envelope; בטבלת staging מוסיפים עמודה; ובקריאה למערכת שלא תומכת בשדה כזה שומרים טבלת קישור בין המזהה המקומי למזהה שהמערכת החזירה.

בכל תחנה מבצעים ארבע פעולות:

1. קוראים את המזהה מהקלט ומאמתים אותו.
2. מצרפים אותו לכל לוג ואירוע תפעולי רלוונטי.
3. מעבירים אותו לקריאה או להודעה הבאה.
4. שומרים לידו את מזהה התוצאה שהתקבל מהמערכת הבאה.

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

לשמור קשרי הורה וילד בפיצול ובאיחוד

תהליכים ארגוניים אינם תמיד קו ישר. בקשה אחת יכולה להתפצל לעדכון SAP, הפקת מסמך ושליחת משימה, ובהמשך להמתין לכך שכל התוצאות יחזרו. אפשר לשמור correlation ID משותף לכל התהליך, ולתת לכל ענף event ID או span נפרד. אם ענף יוצר תהליך עצמאי עם מחזור חיים אחר, שומרים גם parent_correlation_id.

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

לבנות לוגים שאפשר לחפש ולהבין

correlation ID אינו מועיל אם הוא מופיע רק בטקסט חופשי. עדיף לוג מובנה שבו כל רשומה כוללת שדות עקביים:

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

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

להציג את המזהה גם לצוות התמיכה

במקרה של כשל או בקשה לטיפול, כדאי להציג למשתמש או לנציג התמיכה מזהה מעקב בטוח להעתקה. אין צורך לחשוף ארכיטקטורה פנימית או stack trace. הודעה כמו "הבקשה נקלטה, מזהה מעקב: ..." נותנת נקודת פתיחה מדויקת לחקירה.

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

להבחין בין retry לאותה בקשה לבין בקשה חדשה

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

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

לחבר correlation בלי ליצור תלות בכלי אחד

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

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

שאלות שהחקירה צריכה לענות עליהן

מנגנון המעקב צריך לאפשר לצוות לענות במהירות על שאלות מעשיות:

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

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

בדיקות שכדאי לבצע לפני ייצור

יש לבדוק את המנגנון לאורך תרחישים מלאים ולא רק לוודא שה-header קיים בקריאה אחת:

1. בקשה סינכרונית שעוברת כמה APIs וחוזרת למשתמש.
2. מעבר מ-API לתור וממנו ל-workflow או למערכת ליבה.
3. retry ששומר correlation ID ומחליף attempt ID.
4. פיצול לכמה ענפים ואיחוד התוצאות.
5. מערכת יעד שלא יכולה לשמור את המזהה ומחייבת טבלת קישור.
6. בקשה עם correlation ID חיצוני ארוך או לא תקין.
7. שגיאה לפני שנוצר מזהה עסקי במערכת היעד.
8. חיפוש של משתמש שאינו מורשה לראות את תוכן הבקשה.
9. replay של הודעה ישנה בלי אובדן הקישור למקרה המקורי.
10. שמירה ומחיקה לפי מדיניות retention מאושרת.

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

שאלות נפוצות

האם correlation ID חייב להיות UUID?

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

האם משתמשים באותו מזהה לכל החיים של לקוח או הזמנה?

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

מה עושים כשמערכת חיצונית מחזירה correlation ID משלה?

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

האם correlation ID מספיק ל-reconciliation?

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

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

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

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