Steve Trucking, co ja bym zaprojektował

🌐 Dostępne także w 28 językach

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

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 6 z 6 w rozdziale Dane podstawowe i tożsamość, rozdziale 6 kursu Data Architect, i koniec części 1. Wstecz: Gdy autorytet jest dzielony · Dalej: część 2 zaczyna się od Projektowanie pod skalę (coming soon)

Pytanie, na które odpowiada ten punkt kontrolny: czy potrafisz złożyć część 1 w całość na prawdziwym scenariuszu?

Najpierw spróbuj zadania. To moje omówienie zadania z Punktu kontrolnego 1. Jeśli nie masz jeszcze narysowanego własnego projektu, zrób to, zanim zaczniesz czytać dalej. Wartość leży w porównaniu twojego rozumowania z moim, a nie w przeczytaniu odpowiedzi.

To jest „Co ja bym zaprojektował” (What I Would Architect): jedno z możliwych sensownych rozwiązań, a nie jedyna odpowiedź, z nazwanymi kompromisami i zajętymi przeze mnie stanowiskami. Nie omówiliśmy jeszcze dużych wolumenów danych, projektowania zapytań, wzorców integracji, migracji ani transakcji, i to celowo: architektura rozwija się w miarę nauki. Ale część 1 daje nam dość, żeby ustawić szkielet.

Zacznij od liczb

Z opisu: około 3300 dostaw na dzień roboczy, milion rocznie, wzrost o 30% rocznie. Około 1,6 pozycji na dostawę (1,6 mln rocznie); około ośmiu zmian statusu na dostawę (8 mln rocznie); cztery do pięciu milionów zdjęć rocznie; około 200 000 odczytów GPS dziennie; około 180 000 zgłoszeń rocznie; trzech partnerów detalicznych wysyłających manifesty na trzy różne sposoby; dziewięć centrów dystrybucyjnych; 330 ciężarówek z dwuosobowymi ekipami. A Steve Trucking już ma jeden org Salesforce z Service Cloud, Field Service i portalem dla partnerów. Policz zera, zanim narysujesz choćby jeden prostokąt. Zdecydują o kilku sprawach poniżej.

Rdzeń dostaw: patrz na statek-matkę

Dostawy są sercem tego wszystkiego, a Field Service już obsługuje dyspozycję. Zaczynam więc od standardowego modelu Field Service, tak jak zrobił to wycinek z rozdziału 3:

Pojęcie biznesowe	Obiekt Salesforce	Dlaczego
Partner detaliczny	Account (typ rekordu Retail Partner)	Firma, z którą Steve Trucking ma umowę; niesie umowy, zgłoszenia i dostęp do portalu
Personel partnera (kierownicy CD, pracownicy sklepów)	Contact	Użytkownicy portalu muszą być kontaktami
Jedna dostawa: jeden odbiorca, jeden adres, jedno zamówienie partnera, jeden dzień	Work Order	Jednostka pracy w Field Service; wiszą na niej planowanie, aplikacja mobilna i raporty serwisowe
Każda rzecz albo usługa: lodówka, instalacja, wywóz	Work Order Line Item	Dzieli pracę, napędza listy kontrolne i fakturowanie
Rodzaj przystanku: tylko dostawa, z instalacją, z wywozem	Work Type	Ustala czas trwania, umiejętności i listę kontrolną instalacji
Zaplanowana wizyta i jej okno czasowe	Service Appointment	To, co planuje Field Service i co pokazuje aplikacja ekipy
Ekipy i ciężarówki; obszary dyspozycji CD	Service Resource, Service Crew, Service Territory	Field Service planuje ekipę jako jeden zasób
Zapytania odbiorców, reklamacje partnerów	Case	Konsola serwisowa, uprawnienia do obsługi (entitlements), email-to-case
Lista partnera na wtorek w CD w Phoenix	Manifest__c (niestandardowy)	Nic standardowego nie odwzorowuje jednostki odbioru, uzgadniania i ponownego przetwarzania

Wszystko inne zostaje standardowe. Opieranie się kolejnym obiektom niestandardowym jest celowe: pytanie z rozdziału 1 brzmiało, kiedy architekt powinien opierać się kolejnemu, a tu odpowiedź brzmi „prawie zawsze”. Na przykład pozycja zamówienia partnera to nie nowy obiekt. To Work Order, identyfikowany numerem referencyjnym partnera.

Click to enlarge

Wyrasta z finału rozdziału 3 (Zaprojektuj fizyczny model w Salesforce): te same obiekty w tych samych miejscach, z dodaną ekipą, obszarem dyspozycji, zgłoszeniem i tym, co Punkt kontrolny 1 trzyma poza core.

Klucz, który dopasowuje zamówienie partnera do dostawy

Każda pozycja manifestu staje się jednym Work Order, powiązanym ze swoim manifestem. Kluczem jest pytanie, na które najbardziej chcę znać odpowiedź: skąd wiemy, że ta pozycja od partnera to właśnie ta dostawa? Moja odpowiedź: External ID na Work Order, zbudowany z partnera detalicznego i jego własnego numeru zamówienia i dostawy (coś w rodzaju KEYSTONE-PHX-8843119-1), oznaczony jako unikalny. Jedno pole na źródło, jeden do jednego. To identyfikator partnera, nie nasz: „kilka identyfikatorów jednej rzeczy” z rozdziału 2 i „partner jest właścicielem swojego numeru zamówienia” z modułu 1.

Dlaczego to ważne: manifesty przychodzą dzień lub dwa wcześniej i są poprawiane w dniu dostawy. Dzięki temu kluczowi każdy ponownie wysłany albo poprawiony manifest wykonuje upsert, zamiast tworzyć duplikaty. Poprawka aktualizuje Work Order, pole ją rejestruje, a zmiana w dostawie, która jest już na trasie, alarmuje koordynatora: zmiana partnera zostaje zastosowana, ale oznaczona, dopóki dyspozycja jej nie potwierdzi. To też jest to, co zmienia się względem obrazu z rozdziału 4. Dziś każdy manifest ląduje w RouteDesk, a koordynatorzy przepisują trasy do Salesforce, a ukończone przystanki z powrotem. W tym projekcie manifesty przychodzą prosto do Salesforce, przez upsert po kluczu partnera; RouteDesk zostaje wycofany, a przepisywanie się kończy. Rozdział o integracji projektuje trzy formaty wejściowe. Decyzją dotyczącą danych jest klucz.

Odbiorca: konto osoby, kontakt czy żadne z nich?

To najciekawsza decyzja dotycząca danych w części 1, więc oto opcje, a potem mój wybór.

Opcja A: konta osób. Każdy odbiorca staje się kontem osoby powiązanym z każdą dostawą. Za: standardowe, naturalnie współpracuje z Service Cloud, komunikatorami i konsolą, rozpoznaje powracających odbiorców. Przeciw: około miliona nowych odbiorców rocznie, każdy jako konto osoby zajmujące mniej więcej dwa razy więcej miejsca niż konto firmowe (Estimated Record Size by Object Type (opens in a new tab), po angielsku), więc w ciągu dwóch lat jeden z największych obiektów w orgu. A odbiorcy to nie klienci Steve Trucking. To klienci poszczególnych partnerów detalicznych, a Steve Trucking nigdy nie może mieszać klienta jednego partnera z klientem drugiego (S2).

Opcja B: kontakty pod kontem partnera detalicznego. Przeciw: milion kontaktów pod trzema czy czterema kontami to nierównomierny rozkład rodzic-dziecko na ogromną skalę, daleko poza zaleceniem Salesforce, by na jednym rodzicu było około 10 000 rekordów podrzędnych (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), po angielsku). Tę opcję warto pokazać i odrzucić.

Opcja C: odbiorca mieszka na dostawie. Imię i nazwisko, telefon, e-mail, adres i uwagi do dostawy odbiorcy to pola na Work Order (pola adresu są tam już standardowe), pobierane z manifestu. Za: żadnego nowego dużego obiektu; dane żyją dokładnie tak długo, jak potrzebuje ich dostawa; usuwanie odbywa się dla każdej dostawy, w terminach partnera; a izolacja partnerów przychodzi za darmo, bo każda dostawa należy do jednego partnera. Przeciw: powracający odbiorca nie jest rozpoznawany jako ta sama osoba.

To jest równowaga, którą trzeba znaleźć. Czy kiedykolwiek będzie potrzeba rozpoznania kilku dostaw jako tej samej osoby, w tym samym miejscu? Dania tej osobie loginu? To granica między odbiorcą, który potrzebuje własnego rekordu, a danymi odbiorcy, które są po prostu danymi o dostawie. I jest droga środka. Przenoś własny identyfikator klienta partnera detalicznego jako pole na dostawie, Retail Partner Customer ID (identyfikator klienta partnera detalicznego). Nie tworzy on rekordu odbiorcy, ale wiąże ze sobą dostawy, które partner wysyła dla tego samego klienta, co jest początkiem bardziej ujednoliconego doświadczenia klienta, i prowadzi prosto z powrotem do systemu partnera detalicznego, gdzie ten klient naprawdę mieszka. To identyfikator partnera, więc coś znaczy tylko razem z partnerem: klient 4417 jednego partnera nie ma nic wspólnego z klientem 4417 innego.

Moim zawodowym zdaniem właściwym wyborem jest opcja C. Brak rozpoznawania jest do przyjęcia, a nawet pożądany: Steve Trucking nie ma z tymi ludźmi żadnej relacji poza dostawą. To znowu moduł 1: odbiorca to klient partnera, a partner jest autorytetem co do tego, kim ten klient jest. I to rozdział 5: dane osobowe, które trafiają w jedno miejsce i są przypięte do jednej dostawy, dużo łatwiej chronić, przechowywać i usuwać. Opcja ta wytrzymuje też próbę postaci normalnych z rozdziału 2: dane odbiorcy są w relacji jeden do jednego z dostawą, więc należą do niej. Osobny rekord podrzędny odbiorcy oszczędziłby kilka powtarzających się wartości kosztem kolejnego obiektu, kolejnej relacji i ich narzutu, a oszczędziłby więcej tylko wtedy, gdybyśmy traktowali tę samą osobę jako jedną u różnych partnerów detalicznych, czego nie zrobimy. Dlatego dostawa niesie odbiorcę, a Retail Partner Customer ID jest drogą z powrotem do własnego systemu partnera.

Click to enlarge

Czy ujednoliciłbym odbiorców między partnerami?

John Smith, Main Street 123, pojawia się w manifeście Redrock i w manifeście Brightwave. Pewnie ta sama osoba. Czy Steve Trucking powinien ich ujednolicić? Nie, celowo nie. Ujednolicenie odbiorców między partnerami detalicznymi naruszyłoby S2: partner nigdy nie może widzieć odbiorców innego partnera, a ujednolicona tożsamość jest dokładnie tym mostem, przez który dane wyciekają. To zastosowanie stanowiska z tego rozdziału: dopasowuj mniej tam, gdzie mieszanie jest kosztowne, a tu jest bardzo kosztowne.

Jeśli partner detaliczny zechce później rozpoznawania powracających odbiorców we własnych dostawach, to zadanie dla narzędzia do rozpoznawania tożsamości, na przykład tego z Data 360, ograniczonego do tego partnera: mapa w stylu rejestru, a nie konto osoby, i nigdy między partnerami. Mapa tego, kto jest kim, nie daje własności ani dostępu.

Co zostaje w orgu, a co nie

Rozdział 3 pytał, gdzie powinny mieszkać dane. Tu odpowiadają zera:

• Bieżący status mieszka na Service Appointment i Work Order. Historia zmian statusu, około 8 milionów rocznie i rośnie, nie musi mieszkać w orgu core. Każda zmiana jest publikowana jako zdarzenie i przechowywana w hurtowni, w Snowflake. Org trzyma stan bieżący; historia nadal jest dostępna dla serwisu, operacji i analityki, tylko nie w operacyjnej bazie danych.
• Zdjęcia (cztery do pięciu milionów rocznie, niektóre pokazujące ludzi albo wnętrze domu) mieszkają poza core, w magazynie zbudowanym na taki wolumen, przesyłane prosto z aplikacji ekipy. Org trzyma tylko to, czego potrzebuje: mały rekord indeksu na zdjęcie albo tylko licznik i flagę „wymagane zdjęcia z instalacji kompletne”. Wolę lżejszą opcję: utrzymać org szczupłym i pozwolić, żeby magazyn zdjęć był właścicielem swojego indeksu i retencji.
• Odczyty GPS (200 000 dziennie) zostają w FleetLink i trafiają do Snowflake; org potrzebuje tylko ostatniej pozycji dla strony śledzenia i mapy dyspozytora.
• Osiem lat historii z RouteDesk (około 5 milionów dostaw) trafia do hurtowni albo archiwum, dostępnego na potrzeby reklamacji. Co, jeśli cokolwiek, trafia do orgu, to decyzja migracyjna dla części 2.

Click to enlarge

Punkt kontrolny 1: co ja bym zaprojektował. Te same miejsca co na krajobrazie z rozdziału 4 (Krajobraz Steve Trucking), bez przepisywania i bez arkusza.

Kto co widzi i kto potrzebuje licencji

• Partnerzy detaliczni widzą tylko własne dostawy (S2). Każdy Work Order niesie swojego partnera detalicznego; użytkownicy portalu widzą dostawy swojego partnera, a kierownicy CD tylko dostawy swojego CD.
• Użytkownicy partnerów potrzebują licencji portalowej, która obsługuje reguły udostępniania i role: Customer Community Plus albo Partner Community. Miejsca na stadionie z rozdziału 3: najtańsze miejsca nie dają udostępniania, którego potrzebuje ten projekt. Obie licencje wymagają ról dla użytkowników zewnętrznych, a Salesforce ostrzega, że więcej ról spowalnia org (Experience Cloud User Licenses (opens in a new tab), po angielsku). Rola na partnera i na CD jest w porządku; rola dla każdego sklepu już nie.

Wiedza egzaminacyjna. Wiedz, które licencje zewnętrzne dają standardowe udostępnianie: Customer Community Plus i Partner Community (z rolami dla użytkowników zewnętrznych), a nie Customer Community, która korzysta z zestawów udostępniania.

• Odbiorcy nie potrzebują licencji. Strona śledzenia pokazuje jedną dostawę przez link z wygasającym tokenem (S3), a nie przez logowanie.
• Uważaj na nierównomierny rozkład. Setki tysięcy Work Order rocznie wskazujących na trzy czy cztery konta partnerów to nierównomierny rozkład danych na kontach (account data skew). Jedna z opcji to konto podrzędne dla każdego CD pod każdym partnerem, co rozkłada rekordy podrzędne na dziewięć lub więcej części; archiwizacja zakończonych dostaw po upływie okna reklamacji utrzymuje niską liczbę aktywnych rekordów podrzędnych na rodzica. Zajmuje się tym część 2.

Czego bym nie zrobił

Nie tworzyłbym konta osoby dla każdego odbiorcy tylko dlatego, że odbiorca jest osobą fizyczną. Nie wieszałbym miliona kontaktów pod trzema kontami. Nie budowałbym niestandardowego obiektu Delivery obok Work Order z Field Service. Nie ujednolicałbym odbiorców między partnerami. Nie umieszczałbym milionów zdjęć ani odczytów GPS w przestrzeni core. I nie nazwałbym ujednoliconego odbiorcy złotym rekordem, dopóki nie podjęlibyśmy naprawdę decyzji o zarządzaniu danymi podstawowymi.

Co jest wciąż otwarte

Część 1 ustawiła szkielet; część 2 go testuje. Linijka LDV w trzecim roku (Work Order, Service Appointment i pozycje to w ciągu dwóch, trzech lat terytorium dużych wolumenów), projektowanie zapytań dla widoków list ograniczonych do partnera, trzy integracje wejściowe i trzy strumienie statusów, migracja z RouteDesk, transakcje w dniu dostawy i projekt bezpieczeństwa stojący za portalem. Steve Trucking też się zmieni. Zachowaj ten projekt; wrócisz do niego.

Co tu decyduje architekt

• Które obiekty standardowe niosą rdzeń (tu: Field Service), a które obiekty niestandardowe są naprawdę uzasadnione (tu: jeden).
• Klucz, który dopasowuje każdą pozycję zamówienia partnera do dostawy, i dlaczego należy on do partnera.
• Czym jest odbiorca, na podstawie relacji, jaką Steve Trucking naprawdę z nim ma.
• Czy ujednolicać tożsamości i gdzie mieszanie jest zbyt kosztowne, żeby ryzykować.
• Co zostaje w orgu, co mieszka poza core i od jakich licencji zależy projekt.

Do zgłębienia

• Opis Steve Trucking i zadania (D1, D3, DC1) (po angielsku).
• Pomoc Salesforce, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) i Experience Cloud User Licenses (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (po angielsku), jak cytowano w rozdziale 3.