חיבור מערכות ישנות לעולם החדש - מה זה Legacy Integration ואיך עושים את זה נכון

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

מה זו בעצם מערכת Legacy?

"Legacy System" הוא שם יפה למערכת שנכתבה לפני עידן ה-API, לפני הענן, ולפעמים לפני שהאינטרנט הפך לתשתית עסקית. היא עובדת. היא יציבה. לפעמים היא עובדת טוב יותר ממה שייפותח היום. אבל היא לא מדברת עם שום דבר אחר.
ERP ישן שרץ על אותו שרת מאז 2005. מערכת חשבונות שנכתבה ב-VB6. מערכת ניהול ייצור שאף אחד כבר לא זוכר מי כתב אותה. אלה לא מקרים של רשלנות - אלה מקרים של מציאות. עלות ההחלפה, הכספית והארגונית, מפחידה יותר מהמשך החיים עם הבעיה.
הבעיה האמיתית לא מגיעה כשהמערכת הישנה רצה לבד. היא מגיעה כשהארגון רוצה להוסיף עליה - אפליקציה לשטח, פורטל לקוחות, דשבורד ניהולי - ומגלה שאין REST API, אין Webhook, ולפעמים אין תיעוד בכלל. יש רק בסיס נתונים ישן, קבצי FTP, או ממשק שמייצא ל-Excel.
כאן נכנס Legacy Integration.

מה זה Legacy Integration ואיך הוא עובד?

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

הארכיטקטורה תלויה במה שהמערכת הישנה מסוגלת לחשוף:
כשיש גישה לבסיס הנתונים ישירות - בונים SQL Linked Service שמושך נתונים בזמן אמת או בהפרשים ומנגיש אותם דרך API נקי. פתרון זה נפוץ עם ERP ישנים כמו Priority ו-SAP שגרסאות מסוימות שלהם לא חשפו API מלא מחוץ לקופסה.
כשיש ממשק Web Services ישן (SOAP / XML) - עוטפים אותו ב-RESTful Bridge שמתרגם בקשות לפורמט מודרני. האפליקציה החדשה מדברת עם API רגיל; מה שקורה מאחורי הקלעים זה כבר עניין של שכבת התיווך.
כשאין כלום (כשהמערכת מייצאת רק ל-Excel, ל-CSV, או לתיקיית FTP) - בונים מנגנון Polling שסורק שינויים, ממיר אותם לאירועים ומזין לצינור הנתונים. פחות אלגנטי, אבל עובד טוב מפתיע כשהמימוש נכון.

שלושה פרויקטים, שלוש גישות שונות

סולל בונה - Priority, איתוראן ומערכת הזמנות בטון
כשפנינו לפרויקט של שיכון ובינוי - סולל בונה, המשימה הייתה לבנות אפליקציה שתאפשר ללקוחות להזמין בטון ולעקוב בזמן אמת אחרי משאית הערבל. המורכבות: הצד האחר היה מורכב ממספר מערכות - ERP ארגוני (Priority), ניהול צי (איתוראן), מערכת ניהול הזמנות ישנה, ומערכת לוגיסטיקה נפרדת שלא תוכננה לחשוף נתונים.
הפתרון היה שכבת Middleware שאיחדה את המקורות השונים לממשק אחד נקי שהאפליקציה צרכה. מבחינת האפליקציה - API פשוט. מבחינת הצד השני - שום שינוי במערכות הקיימות. הפרויקט זכה בפרס בתחום הטרנספורמציה הדיגיטלית - מה שמוכיח שגישה זו עובדת גם בארגונים שמרנים שסבורים שאי אפשר לגעת בתשתית.
[לפרויקט המלא ←]

פרקומט - בין בקרי חניון למערכת תשלום
הדרישה של חניון בוגרשוב הרובוטי בתל אביב התבססה על איחוד שתי מערכות שלא דיברו זו עם זו: בקרת הכניסה והתשלום (Afcon), ומערכת החניה הרובוטית של פרקומט עצמם. לא היה API משותף, לא הייתה שפה אחידה, ולא היה מישהו שתכנן מראש שהן יצטרכו לעבוד יחד.
בנינו API שישב באמצע, תרגם בין שתי המערכות בזמן אמת, ובנוסף פיתחנו ממשק Backoffice שנתן לצוות ניהול תמונה מלאה, יומנים, דוחות, ניהול משתמשים. שום מערכת לא שונתה. הגשר עצמו עשה את העבודה.
[לפרויקט המלא ←]

ArcScanner - כשאין API בכלל
ArcScanner הוא מקרה קיצוני במובן הטוב. הלקוח רצה לחבר תהליך סריקת מסמכים (חשבוניות, קבלות, תעודות משלוח) למערכת חשבשבת - שלא חשפה API ישיר לסוג הנתונים הנדרש. הפתרון היה לבנות מנגנון שמייצר Meta Data בתצורת API מהצד של ArcScanner, ומזין אותו לחשבשב בפורמט שהמערכת מכירה - בלי לשנות שורה בחשבשבת, ובלי לדרוש מהלקוח לעבור מערכת.
[לפרויקט המלא ←]

מה ה-Middleware בעצם עושה — ומה לא

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

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

שתי טעויות נפוצות שכדאי להימנע מהן

שכפול לוגיקה עסקית - הטעות הנפוצה ביותר. לכתוב מחדש בצד החדש את מה שהמערכת הישנה כבר עושה, במקום לצרוך את הפלט שלה. זה יוצר שני "מקורות אמת" (Source of Truth) וכשהם שונים זה מזה, מתחילות הבעיות האמיתיות.
בנייה בלי תכנון ל-Downtime - קורה לא פעם ש-ERP ישן נופל. זה לא תרחיש נדיר. אפליקציה שנבנית בלי מחשבה על מה קורה כשהחיבור נקטע - תיפול יחד איתו. הגישה הנכונה היא Offline-first עם Deferred Sync: האפליקציה שומרת פעולות בתור ומסנכרנת כשהחיבור חוזר.

מתי כן כדאי להחליף את המערכת?

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

• כל בקשת פיצ'ר חדשה דורשת עוד workaround על גבי workaround
• היצרן הפסיק לתמוך בגרסה הקיימת
• הנתונים במערכת כל כך מבולגנים שה-Integration עצמו הפך לנטל

אבל גם כשהסימנים ברורים, ההחלטה היא לא טכנית. פרויקטי החלפת ERP חורגים בממוצע מהתקציב ב-40%–60% ונמשכים שנה עד שלוש. לפני שמחליטים - שווה לוודא שהבעיה היא באמת המערכת, ולא בדרך שבה עובדים איתה.

אם אתם מתמודדים עם פער כזה ורוצים להבין מה אפשר לעשות בלי לפרק הכל מחדש — דברו איתנו!