Delphi יישומי ארגון: מדוע מערכות רבות פועלות ביציבות – וכיצד להפוך אותן לעמידות לעתיד

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

בעיני הנהלת ה-IT והמנהלים הטכניים השאלה אינה כל כך „Delphi: כן או לא?“, אלא: איך אני שומר את המערכת בכשירות תפעולית, מאובטחת וניתנת לשינוי מבלי לחסום את הארגון בבניית מחליף טוטלי בסגנון Big-Bang? מאמר זה ממקם תצורות טיפוסיות של Delphi ומציג מסלולי מודרניזציה מעשיים — עם דגש על תפעול, נתונים, ממשקים, תחזוקתיות, אבטחה ומיגרציה. ללא פרטים פנימיים של Frameworks, אך עם החלטות קונקרטיות החשובות ביום-יום.

Warum Delphi in Unternehmen „klebt“ – und warum das nicht automatisch schlecht ist

רבות מהיישומים מבוססי Delphi נבנו בתקופות שבהן תוכנת דסקטופ (VCL, כלומר הממשק הקלאסי של Windows) הייתה הדרך המהירה ביותר לדיגיטציה של תהליכים. מתוכם נוצרו מערכות עם צפיפות גבוהה של לוגיקה מקצועית, תלותות חזקות במסדי נתונים והרבה „מקרים מיוחדים“ קטנים שמצטברים ומחזיקים את התפעול. זה מסביר את עמידותן: הלוגיקה העסקית מאומתת — לא דרך Unit-Tests, אלא דרך שנות הפעלה בפרודקשן.

הסיכון אינו לרוב ב-Delphi כשפה, אלא בתחומים הסמוכים: גישות נתונים ישנות (למשל BDE, ה-Borland Database Engine), תלותיות 32‑ביט, הצפנה מיושנת, ממשקים לא ברורים, חסר Observability (Monitoring/Logging), מודלי הרשאות לא מדויקים או חוסר אסטרטגיות עדכון. כשמתעדכנים התחומים ההיקפיים הללו, יישום Delphi יכול להישאר מרכיב אמין מאוד בפתרונות הדיגיטליים של הארגון.

Typische Ausgangslagen: So sehen Delphi Unternehmensanwendungen in der Realität aus

מי שאמור לקבל או לייצב סביבות Delphi ימצא לעתים קרובות תצורות מעורבות. לתכנון ותקצוב יעזור להגדיר בבירור את המצב ההתחלתי:

• לקוח דסקטופ מונוליתי עם גישה ישירה למסד נתונים (לעתים קרובות התפתחות היסטורית, בחלק מהמקרים עם לוגיקת „Fat Client“).
• Client-Server עם שירותים: Windows- und Linux-Services או Linux-Daemon שמבצע עבודות רקע (ייבוא, ייצוא, הרצות הדפסה, דוא“ל, תזמונים).
• היברידי: הדסקטופ נשאר רכיב מוביל, בתוספת REST-API עבור פורטלים או חיבורים של צד שלישי (REST = ממשק מבוסס HTTP, שמשתמש לרוב ב-JSON להעברת נתונים).
• מקורות נתונים מרובים: SQL Server/PostgreSQL בנוסף „עומסי-עבר“ (Firebird, קבצי Paradox, DBF, Access).
• Terminalserver/RDS או Virtual Desktop Infrastruktur (VDI) להפעלה מרכזית, חלקית עם חיבורי פריפריה (סריקה, משקלים, הדפסת תוויות).

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

מודרניזציה בלי Big Bang: לוגיקת קבלת החלטות ל‑IT ולמחליטים

ההחלטה החשובה היא: מה יש לייצב בטווח הקצר, ומה ניתן למודרניזציה צעד־אחרי־צעד? בנייה מחדש מלאה נושאת סיכונים גבוהים: עבודה מקבילה על קונספטים פונקציונליים, תחזוקה כפולה, חלונות מיגרציה, ולעתים פונקציות שוליות שמוערכות פחות (הדפסות מיוחדות, ריצות תיקון, תהליכי חירום). באותו זמן אסור להתעלם ממחסומים אמיתיים (למשל BDE, תלויות שלא ניתנות לפאטש, אבטחה שאינה ניתנת לביקורת).

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

• ייצוב: תהליך בנייה, שחרורים שניתנים לשחזור, לוגינג מסודר, בדיקות גיבוי/שחזור, שיפורים מהירים באבטחה.
• הפרדה: שכבות ברורות (למשל ארכיטקטורת Layer-3: UI, לוגיקה עסקית, גישה לנתונים), הגדרת ממשקים, עדכון גישת הנתונים.
• הרחבה: ממשקי API של REST, פורטלים, קליינטים חדשים, מסדי נתונים חדשים, רב‑פלטפורמה, תמיכה בריבוי שוכרים – איפה שזה הגיוני מקצועית וכלכלית.

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

Delphi מודרניזציה: היכן הסיכונים הגדולים באמת טמונים

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

1) גישה לנתונים ומערכת הדרייברים (BDE, ODBC, קליינטים מיושנים)

ההחלפת BDE היא קלאסיקה: כל עוד הBorland Database Engine בפעולה בסביבת הייצור, מתעוררים קונפליקטים עם גרסאות עדכניות של Windows, דרייברים, הרשאות וקווי בסיס אבטחה. בנוסף, התפעול נעשה שביר כי רכיבים אינם מטופלים עוד. כאן החלפת BDE עם חיבור נייטיבי היא לעתים קרובות צעד מודרניזציה פרגמטי: שכבת גישת נתונים מודרנית בתוך Delphi שמחברת בצורה נקייה מסדי נתונים שונים וטובלת בנושאי דרייברים/Pooling.

חשוב ל‑IT: החלפת BDE היא לא רק „להחליף דרייבר“. עבודות המשך טיפוסיות כוללות התאמות דיאלקט SQL, גבולות טרנזקציות (טרנזקציה = שינויים במסד הנתונים השייכים זה לזה, שמתקבלים כולה או לא מתקבלים כלל), טיפול בשגיאות, מערכות תווים/Unicode וניתוח ביצועים.

2) תלותות 32‑ביט והמעבר ל‑64‑ביט

המעבר ל‑64‑ביט נדיר שנכשל בגלל Delphi עצמו, אלא נתקע ברכיבים חיצוניים: עטיפות דרייבר מדפסת, ספריות COM/ActiveX ישנות, ערכות SDK לחומרה מיוחדת או קליינטים למסדי נתונים מיושנים. לתכנון נדרש באופן מחייב מיפוי תלותים: אילו DLLs נטענים? אילו רכיבים אינם תומכים ב‑64‑ביט? האם יש תחליף או שניתן להוציא את הפונקציה לתהליך נפרד (למשל כ‑Service)?

גישה נקייה היא להחיל 64‑Bit תחילה שם שבו זה מביא יתרונות תפעוליים (דרישות זיכרון, כמויות נתונים גדולות, דרישות פלטפורמה מודרניות) – ולבודד זמנית 32‑Bit לפונקציות שוליות, במקום לחסום את כל הלקוח.

3) מיגרציית Unicode ועקביות נתונים

Unicode פירושו: טקסטים אינם נשמרים עוד ב-codepages מקומיות, אלא בגופן תווים אחיד (בדרך כלל UTF‑16/UTF‑8 בהתאם לרמה). ביישומי Delphi שהתפתחו במשך הזמן הדבר משפיע על שדות נתונים ישנים, פורמטי יצוא, תבניות הדפסה וממשקים. בעיות מתגלות לעתים קרובות רק בשגרה: תווי מיוחדים בשמות, כתובות בינלאומיות, טקסטים של מאמרים, תוכן דוא“ל.

עבור ארגונים קריטי לבדוק מהקצה לקצה: קולציה של מסד הנתונים, ייבוא/ייצוא (CSV, XML, JSON), פורמטי EDI, יצירת PDF, SMTP/IMAP, וגם התצוגה ב-UI. מיגרציית Unicode ברת ביצוע, אך היא דורשת בדיקות עם נתונים אמיתיים וקריטריוני קבלה ברורים.

4) ממשקים ואינטגרציות (REST, ERP, DMS, Identity)

רבים ממערכות Delphi הם „איים“, כיוון שגישה ישירה למסד הנתונים הייתה היסטורית הדרך המהירה ביותר. כיום נדרשות אינטגרציות נקיות: ERP, DMS, CRM, פורטלים, חיבור למכונות. נהוג להוציא את לוגיקת האינטגרציה ל-REST-Services או לשירותי רקע. Delphi REST-API וREST-שרת אינם מטרה בפני עצמם, אלא רכיב תפעולי: נקודות קצה ממוספרות בגרסאות, אימות ברור, רישום מבוקר ולשחרורי נתונים מוגבלים.

בנוסף נושא ה-Identity הופך לרלוונטי: SAML 2.0 (Single Sign-on בין זהות הארגון ליישום) או OAuth2/OpenID Connect, בהתאם לסביבה. ההחלטה משפיעה לא רק על היישום, אלא גם על התפעול, יכולת ביקורת ותהליכי הסרת גישה.

5) Betrieb: Updates, Monitoring, Recovery

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

ארכיטקטורה שעוזרת בשגרה: Layer-3, גבולות ברורים, פחות תופעות לוואי

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

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

• בדיקות ממוקדות של כללי העסק, ללא צורך בהפעלת ה-UI,
• החלפה של גישת הנתונים שלב אחר שלב (למשל מBDE לFireDAC),
• הפעלת מקביל של מספר ממשקים (דסקטופ ופורטל),
• שחרורים יציבים יותר, מפני שהתופעות הלוואי מצטמצמות.

עבור מקבלי החלטות זה טיעון עלות: לא כי הארכיטקטורה „יפה“, אלא כי היא הופכת את תחזוקה לניתנת לתכנון.

מודרניזציה של מסדי נתונים: FireDAC, PostgreSQL, SQL Server – ומה זה אומר לתפעול

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

FireDAC כשכבת סטנדרטיזציה

BDE-Ablosung mit nativer Anbindung יכול לשמש כסטנדרטיזציה טכנית, כי ניהול חיבורים, קשירת פרמטרים, טרנזקציות ובחירת דרייבר הופכים לעקביים יותר. לתפעול חשוב: Connection Pooling (שימוש חוזר בחיבורים), Timeouts, וסיווג ברור של שגיאות (למשל „Deadlock“, „Timeout“, „Unique Constraint“).

PostgreSQL בייצור עם Delphi: הזדמנויות ומוקשים

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

• סוגי נתונים: תאריך/זמן, Boolean, UUID, JSONB – להשתמש בהם בצורה נקייה במודל הנתונים, במקום לשמור הכל כטקסט.
• בידוד טרנזקציות: עקביות מול מקביליות; רלוונטי בלוגיקת רישום ובעיבוד באצוות.
• אסטרטגיית אינדקסים: ביצועים נובעים לעתים נדירות מ“יותר CPU“, אלא מאינדקסים מתאימים ו‑Queries נקיים.

עבור מנהלי מערכת חשוב שהיישום לא יזדקק להרשאות „Superuser“, אלא יפעל עם תפקידים מינימליים. זהו נקודת מפתח לביקורות ולאימותי אבטחה.

מודרניזציה של חיבור ל‑SQL Server

במקרים רבים SQL Server כבר קיים בסביבה. אז פחות מדובר במיגרציה ויותר בשימוש נקי: שאילתות פרמטריות (מול SQL-Injection), בידוד הולם, שימוש ב‑Stored Procedures היכן שנדרשת ממשל תפעולי, והפרדה ברורה בין כניסת אפליקציה לבין חשבונות מנהל. בפרקטיקה כדאי גם לבחון Collations (מיון/השוואת תווים), שכן הם רלוונטיים לנושאי Unicode ולהשוואות (למשל רישיות/אותיות קטנות).

הוספת REST-API: לאפשר אינטגרציות מבלי „לפתוח“ את מסד הנתונים

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

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

• אימות: מבוסס טוקן, ועדיף משולב עם מערכת זהויות מרכזית (למשל דרך SAML 2.0/OIDC ב‑Gateway מקדמי, בהתאם לארכיטקטורה).
• הרשאות: בדיקת זכויות על אובייקטים עסקיים, לא רק „המשתמש רשאי להשתמש ב‑Endpoint“.
• גרסאות: גרסאות של נקודות קצה או של Payload, כדי שהפורטל וה‑backend יישארו ניתנים לפריסה באופן עצמאי.
• הגבלת קצב ו‑Logging: הגנה מפני שימוש לרעה ואבחון אמין בעת תקלות.

ברשתות ארגוניות רבות שירותים כאלה פועלים מאחורי Reverse Proxy (למשל nginx). אז יש לוודא טיפול נכון ב‑Forwarded (כתובת IP האמיתית של הלקוח, זיהוי HTTPS, בסיסי URL נכונים), אחרת היומנים, ההפניות וכללי האבטחה יהיו בלתי מדויקים. זה לא פרט, אלא רלוונטי לניתוח תקריות ולעמידה ב‑Compliance.

Windows-Service וLinux-Services: להפעיל תהליכי רקע כראוי

Delphi משמש בארגונים לא רק עבור לקוחות שולחן עבודה, אלא גם עבור שירותים: ייבוא נתונים, מתזמן, שליחת דואר, יצירת PDF, עובדי ממשק. לתפעול חשוב ששירות לא „פועל איכשהו“, אלא שניתן להפעילו ולהפסיקו באופן מבוקר וניתן להשגיח עליו.

רשימת בדיקה לרכיבי Delphi המיועדים להפעלה כשירות

• הגדרה חיצונית: אין נתיבים/מארחים „קבועים“ בקובץ הבינארי; קונפיגורציה כקובץ/משתני סביבה, עם תיעוד ברור.
• סגירה מסודרת: לסיים משימות רצות בצורה נקייה או לבטל אותן בצורה מסודרת, כדי שלא יווצרו רשומות חלקיות.
• אידמפוטנטיות: הרצת משימה שוב ושוב לא תייצר רישומים כפולים (אידמפוטנטיות = קריאה זהה, תוצאה זהה).
• רישום לוגים עם קורלציה: לכל בקשה/טרנזקציה מזהה, כך שניתן לאחד לוגים על פני רכיבים מרובים.
• ניטור: נקודות קצה לבדיקת מצב (health endpoints) או לפחות מטריקות שניתן לבדוק (למשל „הרצה אחרונה“, „שיעור שגיאות“, „תור“).

במקרים של Linux-שירותים (למשל כדמון תחת systemd) נוספים אריזה, מודל הרשאות ומבנה מערכת הקבצים. קריטי שהזהות של השירות תהיה בעלת הרשאות מינימליות ושהסודות (סיסמאות, טוקנים) לא יהיו בטקסט גלוי בפריסה. בהתאם לסביבה ייתכן שיש צורך ב-Secret-Store או לפחות בנתיב קונפיגורציה מאובטח.

אבטחה וציות: מה ביישומי Delphi בדרך כלל צריך להשלים

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

• הצפנת תעבורה: TLS לשירותים ולתקשורת API, אין מסלולי HTTP לא מוצפנים ברשת פנימית מתוך הרגל.
• ניהול סיסמאות וסודות: אין סיסמאות בקבצי INI ללא הגנה; אם אפשר — זהות מרכזית וטוקנים.
• Audit-Logging: מי ביצע איזו פעולה קריטית (נתוני יסוד, אישורים, ייצוא), עם חותמת זמן וזהות.
• מודל הרשאות: למודל תפקידים והרשאות באופן מקצועי; להפריד פונקציות מנהל; לבדוק הפרדה בין לקוחות/שוכנים (Mandantentrennung).
• קריפטוגרפיה מעשית ונקייה: לא להשתמש בשיטות ביתיות; שיטות מבוססות כמו AES (סימטרי) ואלגוריתמי hash עדכניים, בתוספת הגנה על שלמות.

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

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

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

1) מיפוי טכני של המצב הקיים שמציג את התפעול והסיכונים

• רשימת רכיבים (Delphi-גרסאות, ספריות צד שלישי, דרייברים, שירותים, מתקינים)
• בסיסי נתונים וזרימות נתונים (יבוא/ייצוא, משימות אצווה, דוחות)
• ממשקים (קובץ, TCP/IP, REST, SOAP, דואר אלקטרוני, ERP/DMS/CRM)

2) Zielbild definieren, aber nicht überfrachten

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

3) Umsetzung in schnürbaren Paketen

חבילות מודרניזציה צריכות להיות מוגדרות מבחינה פונקציונלית וטכנית וניתנות להפרדה: „BDE raus und Datenzugriff standardisieren“, „REST-API für Portal-Use-Cases“, „64‑Bit-Client plus Kompatibilitätskapsel“, „Service-Betrieb härten“. כל חבילה זקוקה לקריטריוני קבלה: יציבות הניתנת למדידה, ביצועים מוגדרים ותהליכי תפעול מתועדים.

C# und Delphi zusammenbringen: Wenn Portale und Services neben dem Desktop entstehen

ברבות מהחברות Delphi מושרש במערכת הליבה, בעוד שפורטלים או שירותי אינטגרציה חדשים נוטים להיווצר בC#/.NET. זה אינו סתירה כל עוד הארכיטקטורה מבצעת הפרדה ברורה: Delphi יכול להמשיך להפעיל באופן יציב את המערכת הדסקטופ הקרובה לתהליך, בעוד שC# Portale או C# Services יענו על דרישות ווב מודרניות. המכריע הוא שפה משותפת בין המערכות: חוזי נתונים ברורים, זהויות עקביות, גרסאות ממשק שניתן לעקוב אחריהן וניטור אחיד חוצה-מערכות.

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

Was Sie intern vorbereiten sollten: Dokumentation, Betriebshandbuch, Knowledge-Transfer

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

• מדריך תפעול: שירותים, פורטים, קונפיגורציה, Cron/Scheduler, תקלות טיפוסיות, שלבי התאוששות.
• הערות שחרור: מה משתנה, אילו מיגרציות DB מתבצעות, כיצד ניתן לבצע Rollback?
• קטלוג ממשקים: נקודות קצה/פורמטים, העברת קבצים, אנשי קשר, גרסאות.
• מבט כולל על מודל הנתונים: טבלאות/ישויות מרכזיות, מפתחות, לוגיקת רב-לקוחות, ארכיבציה.

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

Fazit: Delphi Unternehmensanwendungen sind nicht das Problem – fehlende Modernisierungspfade schon

יישומי ארגונים Delphi יכולים להוות במשך שנים ליבת פעולה אמינה וכלכלית לפתרונות תוכנה פרוסס-קרובים. הנקודה הקריטית נדירה שנגזרת מהשפה עצמה; לרוב הבעיה היא צבירת רכיבי Legacy, ממשקים לא ברורים, העדר הקשחת תפעול ומנגנוני אבטחה שאינם מתוחזקים. מי שמתכנן ייצוב, ניתוק והרחבה כמפת דרכים מבוקרת, נמנע מה-Big Bang המסוכן — ובכל זאת מקבל אינטגרציות REST, יכולת 64‑סיביות, גישות נתונים נקיות ותפעול התואם לדרישות של היום.

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

לדון בפרויקט או ביוזמת מודרניזציה עם Net-Base.