Steve Trucking, איך אני הייתי מתכנן

🌐 זמין גם ב-28 שפות

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

התמונה נוצרה בבינה מלאכותית

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

יחידה 6 מתוך 6 בפרק נתוני אב וזהות, הפרק השישי בקורס Data Architect, והסוף של חלק 1. הקודם: כשהסמכות משותפת · הבא: חלק 2 מתחיל ב-תכנון לקנה מידה (coming soon)

השאלה שנקודת הביקורת הזו עונה עליה: אתם יכולים לחבר את חלק 1 על תרחיש אמיתי?

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

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

התחילו מהמספרים

מהתדריך: כ-3,300 משלוחים ביום עבודה, מיליון בשנה, עם צמיחה של 30% בשנה. כ-1.6 פריטים למשלוח (1.6 מיליון בשנה); כ-שמונה שינויי סטטוס למשלוח (8 מיליון בשנה); ארבעה עד חמישה מיליון תמונות בשנה; כ-200,000 קריאות GPS ביום; כ-180,000 פניות בשנה; שלושה שותפים קמעונאיים ששולחים מניפסטים בשלוש דרכים שונות; תשעה מרכזי הפצה; 330 משאיות עם צוותים של שני אנשים. ו-Steve Trucking כבר מריצה org אחד של Salesforce עם Service Cloud, Field Service ופורטל שותפים. ספרו את האפסים לפני שמשרטטים קופסה אחת. הם יכריעו כמה דברים בהמשך.

ליבת המשלוחים: הביטו אל ספינת האם

המשלוחים הם הלב של העניין, ו-Field Service כבר עושה שיבוץ (dispatch). אז אני מתחיל מהמודל הסטנדרטי של Field Service, כמו שעשה החתך של פרק 3:

מושג עסקי	אובייקט Salesforce	למה
שותף קמעונאי	Account (חשבון, סוג רשומה Retail Partner)	עסק ש-Steve Trucking חותמת איתו חוזה; נושא חוזים, פניות וגישה לפורטל
צוות השותף (מנהלי מרכזי הפצה, צוות החנויות)	Contact	משתמשי פורטל חייבים להיות אנשי קשר
משלוח אחד: נמען אחד, כתובת אחת, הזמנת שותף אחת, יום אחד	Work Order	יחידת העבודה של Field Service; התזמון, האפליקציה לנייד ודוחות השירות תלויים בה
כל פריט או שירות: המקרר, ההתקנה, הפינוי	Work Order Line Item	מחלק את העבודה, מניע רשימות בדיקה וחיוב
סוג העצירה: משלוח בלבד, עם התקנה, עם פינוי	Work Type	קובע משך, מיומנויות ואת רשימת הבדיקה להתקנה
הביקור המתוזמן והחלון שלו	Service Appointment	מה ש-Field Service מתזמן ומה שהאפליקציה של הצוות מציגה
צוותים ומשאיות; אזורי השיבוץ של מרכזי ההפצה	Service Resource, Service Crew, Service Territory	Field Service מתזמן צוות כמשאב אחד
פניות של נמענים, תביעות של שותפים	Case	קונסולת השירות, זכאויות, email-to-case
הרשימה של השותף ליום שלישי במרכז ההפצה בפיניקס	Manifest__c (מותאם אישית)	שום דבר סטנדרטי לא מייצג את יחידת הקבלה, ההתאמה וההרצה מחדש

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

Click to enlarge

היא צומחת מהדיאגרמה המסכמת של פרק 3 (תכננו את המודל הפיזי ב-Salesforce): אותם אובייקטים באותם מקומות, בתוספת הצוות, אזור השיבוץ, הפנייה ומה שנקודת ביקורת 1 משאירה מחוץ לליבה.

המפתח שמתאים הזמנה של שותף למשלוח

כל שורה במניפסט הופכת ל-Work Order אחד, שמקושר למניפסט שלו. המפתח הוא השאלה שהכי חשוב לי לקבל עליה תשובה: איך אנחנו יודעים שהשורה הזו מהשותף היא המשלוח ההוא? התשובה שלי: External ID על ה-Work Order שבנוי מהשותף הקמעונאי וממספר ההזמנה והמשלוח של השותף עצמו (משהו כמו KEYSTONE-PHX-8843119-1), מסומן כייחודי (unique). שדה אחד לכל מקור, אחד-לאחד. זה המזהה של השותף, לא שלנו: “כמה מזהים לדבר אחד” של פרק 2, ו”השותף הוא הבעלים של מספר ההזמנה שלו” של יחידה 1.

למה זה חשוב: מניפסטים מגיעים יום או יומיים מראש ומתעדכנים ביום עצמו. עם המפתח הזה, כל מניפסט שנשלח שוב או עודכן עושה upsert במקום ליצור כפילויות. העדכון מעדכן את ה-Work Order, שדה מתעד אותו, ושינוי במשלוח שכבר תוכנן במסלול מתריע לרכז: השינוי של השותף מוחל, אבל מסומן עד שהשיבוץ מאשר אותו. זה גם מה שמשתנה מהתמונה של פרק 4. היום כל מניפסט נוחת ב-RouteDesk, והרכזים מקלידים מחדש מסלולים ל-Salesforce ועצירות שהושלמו בחזרה. בתכנון הזה המניפסטים נכנסים ישר ל-Salesforce, ב-upsert לפי המפתח של השותף; RouteDesk יוצא משימוש, וההקלדה מחדש נגמרת. פרק האינטגרציה מתכנן את שלושת הפורמטים הנכנסים. החלטת הנתונים היא המפתח.

הנמען: חשבון אישי, איש קשר, או אף אחד מהם?

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

אפשרות A: חשבונות אישיים. כל נמען הופך לחשבון אישי, שמקושר לכל משלוח. בעד: סטנדרטי, עובד באופן טבעי עם Service Cloud, הודעות והקונסולה, מזהה נמענים חוזרים. נגד: כמיליון נמענים חדשים בשנה, כל אחד חשבון אישי שתופס בערך פי שניים אחסון מחשבון עסקי (Estimated Record Size by Object Type (opens in a new tab)), כך שתוך שנתיים זה אחד האובייקטים הגדולים ב-org. והנמענים הם לא הלקוחות של Steve Trucking. הם הלקוחות של כל שותף קמעונאי, ו-Steve Trucking לעולם לא תערבב לקוח של שותף אחד עם לקוח של אחר (S2).

אפשרות B: אנשי קשר תחת החשבון של השותף הקמעונאי. נגד: מיליון אנשי קשר תחת שלושה או ארבעה חשבונות זה parent-child skew בקנה מידה עצום, הרבה מעבר להנחיה של Salesforce של כ-10,000 רשומות בת לכל הורה (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). זו האפשרות שמציגים, ודוחים.

אפשרות C: הנמען חי על המשלוח. השם, הטלפון, האימייל, הכתובת והערות המשלוח של הנמען הם שדות על ה-Work Order (שדות הכתובת כבר סטנדרטיים שם), שנקלטים מהמניפסט. בעד: אין אובייקט גדול חדש; הנתונים חיים בדיוק כמה זמן שהמשלוח צריך אותם; המחיקה קורית לכל משלוח, לפי לוח הזמנים של השותף; והבידוד בין השותפים מגיע בחינם, כי כל משלוח שייך לשותף אחד. נגד: נמען חוזר לא מזוהה כאותו אדם.

זה האיזון שצריך למצוא. האם אי פעם יהיה צורך לזהות כמה משלוחים כאותו אדם, באותו מקום? לתת לאדם הזה התחברות? זה הקו בין נמען שצריך רשומה משלו לבין פרטי נמען שהם פשוט נתונים על המשלוח. ויש דרך אמצעית. העבירו את מזהה הלקוח של השותף הקמעונאי עצמו כשדה על המשלוח, Retail Partner Customer ID. הוא לא יוצר רשומת נמען, אבל הוא קושר יחד את המשלוחים ששותף שולח לאותו לקוח, וזו ההתחלה של חוויית לקוח מאוחדת יותר, והוא מוביל ישר חזרה למערכת של השותף הקמעונאי, שבה הלקוח הזה באמת חי. זה המזהה שלהם, אז יש לו משמעות רק יחד עם השותף: ללקוח 4417 של שותף אחד אין שום קשר ללקוח 4417 של אחר.

לדעתי המקצועית, אפשרות C היא הבחירה הנכונה. החלק של “לא מזוהה” מקובל, ואפילו רצוי: ל-Steve Trucking אין קשר עם האנשים האלה מעבר למשלוח. זו שוב יחידה 1: הנמען הוא הלקוח של השותף, והשותף הוא הסמכות על מי שהם. וזה פרק 5: מידע אישי שנוחת במקום אחד, קשור למשלוח אחד, הרבה יותר קל להגן עליו, לשמור אותו ולמחוק אותו. וזה עומד גם בצורות הנורמליות של פרק 2: פרטי הנמען הם אחד-לאחד עם המשלוח, אז הם שייכים אליו. אובייקט בת נפרד של נמען היה חוסך כמה ערכים חוזרים במחיר של עוד אובייקט, עוד קשר והתקורה שלו, והדרך היחידה שבה הוא היה חוסך יותר היא להתייחס לאותו אדם כאחד על פני שותפים קמעונאיים, ואת זה לא נעשה. אז המשלוח נושא את הנמען, עם Retail Partner Customer ID כדרך חזרה למערכת של השותף עצמו.

Click to enlarge

האם הייתי מאחד נמענים על פני שותפים?

John Smith, רחוב הראשי 123, מופיע במניפסט של Redrock ובזה של Brightwave. כנראה אותו אדם. האם Steve Trucking צריכה לאחד אותם? לא, בכוונה לא. איחוד נמענים על פני שותפים קמעונאיים היה מפר את S2: שותף לעולם לא יראה את הנמענים של שותף אחר, וזהות מאוחדת היא בדיוק הגשר שדרכו זה דולף. זו העמדה של הפרק הזה בפעולה: התאימו פחות מדי איפה שערבוב עולה ביוקר, וכאן ערבוב עולה ביוקר רב.

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

מה נשאר ב-org, ומה לא

פרק 3 שאל איפה נתונים צריכים לחיות. האפסים עונים על זה כאן:

• הסטטוס הנוכחי חי על ה-Service Appointment וה-Work Order. ההיסטוריה של שינויי הסטטוס, כ-8 מיליון בשנה ובגדילה, לא צריכה לחיות ב-org של הליבה. כל שינוי מתפרסם כאירוע ונשמר במחסן הנתונים, Snowflake. ה-org שומר את המצב הנוכחי; ההיסטוריה עדיין שם בשביל השירות, התפעול והאנליטיקה, רק לא במסד הנתונים התפעולי.
• תמונות (ארבעה עד חמישה מיליון בשנה, חלקן מראות אנשים או את פנים הבית) חיות מחוץ לליבה באחסון שנבנה לנפח הזה, ומועלות ישר מהאפליקציה של הצוות. ה-org שומר רק את מה שהוא צריך: רשומת אינדקס קטנה לכל תמונה, או רק ספירה ודגל “תמונות ההתקנה הנדרשות הושלמו”. ההעדפה שלי היא האפשרות הקלה יותר: לשמור על org רזה, ולתת למאגר התמונות להיות הבעלים של האינדקס ושל השמירה שלו.
• קריאות GPS (200,000 ביום) נשארות ב-FleetLink והולכות ל-Snowflake; ה-org צריך רק את המיקום האחרון בשביל דף המעקב והמפה של המשבץ.
• שמונה שנות ההיסטוריה של RouteDesk (כ-5 מיליון משלוחים) הולכות למחסן הנתונים או לארכיון, נגישות לתביעות. מה, אם בכלל, נכנס ל-org זו החלטת הסבה של חלק 2.

Click to enlarge

נקודת ביקורת 1: איך אני הייתי מתכנן. אותם מקומות כמו במפת המערכות של פרק 4 (מפת המערכות של Steve Trucking), בלי ההקלדה מחדש ובלי הגיליון האלקטרוני.

מי רואה מה, ולמי צריך רישיון

• שותפים קמעונאיים רואים רק את המשלוחים שלהם (S2). כל Work Order נושא את השותף הקמעונאי שלו; משתמשי הפורטל רואים את המשלוחים של השותף שלהם, ומנהלי מרכזי ההפצה רק את אלה של מרכז ההפצה שלהם.
• משתמשי השותפים צריכים רישיון פורטל שתומך בכללי שיתוף ובתפקידים: Customer Community Plus או Partner Community. המושבים באצטדיון של פרק 3: המושבים הכי זולים לא מקבלים את השיתוף שהתכנון הזה צריך. שני הרישיונות צריכים תפקידים (roles) למשתמשים החיצוניים, ו-Salesforce מזהירה שיותר תפקידים מאטים את ה-org (Experience Cloud User Licenses (opens in a new tab)). תפקיד לכל שותף ולכל מרכז הפצה זה בסדר; תפקיד לכל חנות לא.

ידע למבחן. הכירו אילו רישיונות חיצוניים כוללים שיתוף סטנדרטי: Customer Community Plus ו-Partner Community (עם תפקידים למשתמשים החיצוניים), לא Customer Community, שמשתמש ב-sharing sets.

• נמענים לא צריכים רישיון. דף המעקב מציג משלוח אחד דרך קישור עם טוקן שפג תוקף (S3), לא התחברות.
• שימו עין על ה-skew. מאות אלפי Work Orders בשנה שמצביעים על שלושה או ארבעה חשבונות של שותפים זה account data skew. אפשרות אחת היא חשבון בת לכל מרכז הפצה תחת כל שותף, מה שמפזר את רשומות הבת על תשעה או יותר; העברה לארכיון של משלוחים שהושלמו אחרי חלון התביעות שומרת על מספר נמוך של רשומות בת פעילות לכל הורה. חלק 2 מתמודד עם זה.

מה לא הייתי עושה

לא הייתי יוצר חשבון אישי לכל נמען רק כי נמען הוא אדם פרטי. לא הייתי תולה מיליון אנשי קשר על שלושה חשבונות. לא הייתי בונה אובייקט Delivery מותאם אישית לצד ה-Work Order של Field Service. לא הייתי מאחד נמענים על פני שותפים. לא הייתי שם מיליוני תמונות או קריאות GPS באחסון הליבה. ולא הייתי קורא לנמען מאוחד רשומת זהב אלא אם באמת קיבלנו החלטה של ניהול נתוני אב.

מה עוד פתוח

חלק 1 קבע את השלד; חלק 2 בודק אותו. סרגל ה-LDV בשנה השלישית (Work Orders, Service Appointments ופריטים הם כולם בטריטוריה של נפחים גדולים תוך שנתיים-שלוש), תכנון שאילתות לתצוגות רשימה שמוגבלות לשותף, שלוש האינטגרציות הנכנסות ושלושת ערוצי הסטטוס, ההסבה מ-RouteDesk, טרנזקציות ביום עצמו, ותכנון האבטחה שמאחורי הפורטל. גם Steve Trucking תשתנה. שמרו את התכנון הזה; תחזרו אליו.

מה הארכיטקט מחליט כאן

• אילו אובייקטים סטנדרטיים נושאים את הליבה (כאן, אלה של Field Service), ואילו אובייקטים מותאמים אישית באמת מוצדקים (כאן, אחד).
• המפתח שמתאים כל שורת הזמנה של שותף למשלוח, ולמה הוא שייך לשותף.
• מה הוא הנמען, לפי הקשר ש-Steve Trucking באמת מקיימת איתו.
• האם לאחד זהויות, ואיפה ערבוב יקר מכדי להסתכן בו.
• מה נשאר ב-org, מה חי מחוץ לליבה, ובאילו רישיונות התכנון תלוי.

להרחבה

• התדריך והאתגרים של Steve Trucking (D1, D3, DC1).
• Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab) Considerations for Object Relationships (opens in a new tab) ו-Experience Cloud User Licenses (opens in a new tab) (באנגלית, נבדק ב-2026-10-14).
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab), כפי שצוטט בפרק 3.