הפסיקו להעתיק נתונים: מדוע טבלאות וירטואליות של Dynamics 365 עדיפות על סנכרון מסורתי

By Mirko Peters · 2026-08-27

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

Automatically translated with AI from the original post. Read the English original

Cover: Dynamics 365 Virtual Entities - Simply Explained

אם תרצו לשמוע פירוט קולי מעמיק של הנושא יחד עם דוגמאות מהשטח, כדאי לכם להאזין לפרק הפודקאסט המתאים: Dynamics 365 Virtual Entities - Simply Explained.

המלכודות של שכפול נתונים ושל משימות סנכרון מיושנות

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

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

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

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

הבנת טבלאות וירטואליות של Dynamics 365

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

אם עבדתם עם מערך היישומים העסקיים של Microsoft תקופה מסוימת, ייתכן שעדיין תיתקלו במונח הישן "Virtual Entities" בתיעוד מדור קודם, בפורומים טכניים או בשיחות עם מפתחים ותיקים. המונח המעודכן והנוכחי של Microsoft הוא Virtual Tables. ללא קשר לשם שבו משתמשים, הרעיון המרכזי נשאר זהה: Dynamics 365 ו-Dataverse יכולים להציג מידע חיצוני כאילו המשתמשים עובדים עם טבלה מקורית של Dataverse, בעוד הרשומות עצמן נשארות מאוחסנות בבטחה מחוץ ל-Dataverse.

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

איך Virtual Tables מספקים חלון חי אל נתונים חיצוניים

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

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

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

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

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

מהו ספק נתונים?

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

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

כמובן, לא כל יישום עסקי מדור קודם או מותאם אישית תומך ב-OData. כשהארכיטקטורה דורשת שיטת אינטגרציה אחרת, הארגונים יכולים ליישם Custom Data Providers. מפתח מיומן יכול לכתוב ספק מותאם אישית שמגשר בין Dataverse לבין API REST קנייני, מסד נתונים מסוג SQL או שירות אינטרנט ארגוני פנימי. ללא קשר לטכנולוגיה הבסיסית, הספק המותאם אישית מבצע את אותן פעולות יסוד: מקבל את בקשת Dataverse, מתקשר עם המערכת החיצונית, מתרגם את התשובה ומחזיר את הרשומות בצורה חלקה.

מהו Data Source?

אם ה-Data Provider יודע לדבר את השפה, ה-Data Source מכיל את הכתובת והפרטים המדויקים הנדרשים להגעה ליעד. ה-Data Source מחזיק את כל מידע החיבור לשירות החיצוני, כולל כתובת נקודת הקצה, פרמטרי אימות, מפתחות API והגדרות הגבלת קצב (throttling) הקשורות לחיבור. דמיינו את הספק כמומחה השפה ואת המקור כספר הכתובות.

מיפוי עמודות חיצוניות ומזהי רשומות ייחודיים

לאחר שהחיבור נוצר, יש למפות את העמודות החיצוניות לסכמה של ה-Virtual Table. לדוגמה, יישום המחסן עשוי לכנות שדה "Available Quantity", בעוד שמשתמשי Dynamics 365 מעדיפים לראות "Stock on Hand". מיפוי השדות אומר ל-Dataverse ששני השמות השונים האלה מייצגים בדיוק את אותו מידע. כך הארגונים יכולים להציג מונחים ידידותיים למשתמש בתוך Dynamics 365, מבלי לאלץ את המערכת החיצונית לעבור שינויי שמות יקרים בסכמה.

בנוסף, Dataverse דורש מזהה ייחודי אמין לכל רשומה, כדי להבחין בין רשומה אחת לאחרת. לרשומות של Virtual Table חייבים להיות מפתחות ייחודיים אמינים שה-Dataverse יכול לזהות. ללא מזהה חזק, Dataverse לא יוכל לקבוע בביטחון איזה מוצר, חשבונית או לקוח בדיוק המשתמש בחר. לכן זיהוי הרשומה הוא תנאי מוקדם טכני קריטי בבחינה האם מקור נתונים חיצוני מסוים יכול לעבוד ביעילות באמצעות Virtual Tables.

מתי להשתמש ב-Virtual Tables בארכיטקטורה שלכם

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

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

לסיכום, מעבר מסנכרון נתונים מסורתי לאימוץ Virtual Tables יכול לייעל משמעותית את הארכיטקטורה של Microsoft 365 שלכם. אתם שומרים על מקור אמת יחיד ללא פגיעה, מונעים חלונות של נתונים מיושנים ומעניקים למשתמשים את סביבת העבודה המאוחדת שאותה ביקשו. להעמקה בנושא, הקשיבו לפרק המלא ב-Dynamics 365 Virtual Entities - Simply Explained.