Steve Trucking, Ben Nasıl Tasarlardım

🌐 28 dilde daha mevcut

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

Görsel yapay zekâ ile üretilmiştir

Yapay zekâ ile çevrildi. Henüz topluluk tarafından incelenmedi. İngilizcesini oku

Data Architect kursunun 6. bölümü olan Ana Veri ve Kimlik bölümündeki 6 modülden 6.‘sı ve 1. Kısım’ın sonu. Önceki: Yetki Paylaşıldığında · Sonraki: 2. Kısım Ölçek İçin Tasarlamak (coming soon) ile başlıyor

Bu kontrol noktasının yanıtladığı soru: 1. Kısım’ı gerçek bir senaryo üzerinde bir araya getirebilir misiniz?

Önce alıştırmayı deneyin. Bu, 1. Kontrol Noktası alıştırmasının benim çözümüm. Kendi tasarımınızı henüz çizmediyseniz okumaya devam etmeden önce bunu yapın. Değer, yanıtı okumakta değil, gerekçenizi benimkiyle karşılaştırmaktadır.

Bu, “Ben Nasıl Tasarlardım”: ödünleşimleri adlandırılmış ve pozisyonlarım alınmış, tek yanıt değil, olası uygulanabilir bir çözüm. Büyük veri hacimlerini, sorgu tasarımını, entegrasyon kalıplarını, taşımayı ya da işlemleri henüz ele almadık ve bu bilinçli: mimari siz daha fazlasını öğrendikçe gelişir. Ama 1. Kısım bize iskeleti kurmaya yetecek kadarını veriyor.

Sayılarla Başlayın

Senaryo özetinden: iş günü başına yaklaşık 3.300 teslimat, yılda bir milyon, yılda %30 büyüyor. Teslimat başına yaklaşık 1,6 satır öğesi (yılda 1,6 milyon); teslimat başına yaklaşık sekiz durum değişikliği (yılda 8 milyon); yılda dört beş milyon fotoğraf; günde yaklaşık 200.000 GPS okuması; yılda yaklaşık 180.000 vaka; yük listelerini üç farklı şekilde gönderen üç Perakende Ortağı; dokuz dağıtım merkezi; iki kişilik ekipleriyle 330 kamyon. Ve Steve Trucking zaten Service Cloud, Field Service ve bir ortak portalı olan tek bir Salesforce org’u çalıştırıyor. Tek bir kutu çizmeden önce sıfırları sayın. Aşağıda birkaç şeye onlar karar verecek.

Teslimat Çekirdeği: Ana Gemiye Bakın

Teslimatlar işin kalbidir ve Field Service sevkiyatı zaten yapıyor. Bu yüzden 3. bölümün kesitinin yaptığı gibi Field Service’in standart modeliyle başlıyorum:

İş kavramı	Salesforce nesnesi	Neden
Perakende Ortağı	Hesap (Retail Partner kayıt türü)	Steve Trucking’in sözleşme yaptığı bir işletme; sözleşmeleri, vakaları ve portal erişimini taşır
Ortak çalışanları (DC müdürleri, mağaza çalışanları)	Kişi	Portal kullanıcıları Kişi olmalıdır
Tek bir teslimat: bir Alıcı, bir adres, bir ortak siparişi, bir gün	İş Emri	Field Service’in iş birimi; planlama, mobil uygulama ve servis raporları ona bağlıdır
Her ürün ya da hizmet: buzdolabı, kurulum, eskisinin götürülmesi	İş Emri Satır Öğesi	İşi böler, kontrol listelerini ve faturalamayı yönlendirir
Durak türü: yalnızca teslimat, kurulumlu, eski ürünü götürmeli	İş Türü	Süreyi, becerileri ve kurulum kontrol listesini belirler
Planlanan ziyaret ve zaman aralığı	Servis Randevusu	Field Service’in planladığı ve ekibin uygulamasının gösterdiği
Ekipler ve kamyonlar; DC sevk alanları	Servis Kaynağı, Servis Ekibi, Servis Bölgesi	Field Service bir ekibi tek bir kaynak olarak planlar
Alıcı soruları, ortak talepleri	Vaka	Servis konsolu, yetkilendirmeler, e-postadan vakaya
Ortağın Phoenix DC’deki Salı günü listesi	Manifest__c (özel)	Teslim alma, mutabakat ve yeniden oynatma birimini temsil eden standart bir şey yok

Geri kalan her şey standart kalır. Daha fazla özel nesneye direnmek bilinçlidir: 1. bölümün sorusu bir mimarın bir tane daha özel nesneye ne zaman direnmesi gerektiğiydi ve burada yanıt “neredeyse her zaman”. Örneğin ortağın sipariş satırı yeni bir nesne değildir. Ortağın referansıyla tanımlanan İş Emri’dir.

Click to enlarge

3. bölümün final diyagramından büyür (Salesforce Fiziksel Modelini Tasarlayın): aynı nesneler aynı yerlerde; ekip, sevk bölgesi, vaka ve 1. Kontrol Noktasının çekirdek dışında tuttukları eklenmiş.

Bir Ortağın Siparişini Bir Teslimatla Eşleştiren Anahtar

Her yük listesi satırı, kendi Yük Listesi’ne bağlı tek bir İş Emri olur. Anahtar, en çok yanıtlanmasını istediğim sorudur: ortaktan gelen bu satırın şu teslimat olduğunu nasıl biliyoruz? Yanıtım: Perakende Ortağından ve ortağın kendi sipariş ve teslimat referansından oluşturulan (KEYSTONE-PHX-8843119-1 gibi bir şey), benzersiz olarak işaretlenmiş, İş Emri üzerinde bir Harici Kimlik. Kaynak başına bir alan, bire bir. Bu bizim değil, ortağın tanımlayıcısıdır: 2. bölümün “tek şey için birkaç tanımlayıcı” fikri ve 1. modülün “sipariş referansının sahibi ortaktır” ilkesi.

Neden önemli: yük listeleri bir iki gün önceden gelir ve aynı gün revize edilir. Bu anahtarla yeniden gönderilen ya da revize edilen her yük listesi yinelenen kayıt oluşturmak yerine upsert yapar. Revizyon İş Emri’ni günceller, bir alan bunu kaydeder ve zaten rotaya konmuş bir teslimattaki değişiklik koordinatörü uyarır: ortağın değişikliği uygulanır, ama sevk birimi teyit edene kadar işaretli kalır. 4. bölümün resminden değişen de budur. Bugün her yük listesi RouteDesk’e düşüyor ve koordinatörler rotaları Salesforce’a, tamamlanmış durakları da geri elle yeniden giriyor. Bu tasarımda yük listeleri ortağın anahtarıyla upsert edilerek doğrudan Salesforce’a gelir; RouteDesk emekliye ayrılır ve yeniden girme sona erer. Entegrasyon bölümü üç gelen biçimi tasarlıyor. Veri kararı anahtardır.

Alıcı: Kişi Hesabı mı, Kişi mi, İkisi de Değil mi?

Bu, 1. Kısım’daki en ilginç veri kararı; bu yüzden önce seçenekler, sonra benim seçimim.

A Seçeneği: kişi hesapları. Her Alıcı, her teslimata bağlı bir kişi hesabı olur. Lehine: standart, Service Cloud, mesajlaşma ve konsolla doğal olarak çalışır, tekrar gelen Alıcıları tanır. Aleyhine: yılda yaklaşık bir milyon yeni Alıcı, her biri bir iş hesabının yaklaşık iki katı depolama alanı kaplayan bir kişi hesabı (Estimated Record Size by Object Type (opens in a new tab), İngilizce); yani iki yıl içinde org’daki en büyük nesnelerden biri. Ve Alıcılar Steve Trucking’in müşterileri değil. Her Perakende Ortağının müşterileridir ve Steve Trucking asla bir ortağın müşterisini bir başkasınınkiyle karıştırmamalıdır (S2).

B Seçeneği: Perakende Ortağının hesabı altında Kişiler. Aleyhine: üç dört hesabın altında bir milyon Kişi, Salesforce’un üst kayıt başına yaklaşık 10.000 alt kayıt önerisinin çok ötesinde, devasa ölçekte bir üst-alt çarpıklığıdır (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), İngilizce). Bu, gösterilip reddedilecek seçenek.

C Seçeneği: Alıcı teslimatta yaşar. Alıcının adı, telefonu, e-postası, adresi ve teslimat notları, yük listesinden alınan İş Emri üzerindeki alanlardır (adres alanları orada zaten standart). Lehine: yeni büyük bir nesne yok; veri tam olarak teslimatın ihtiyaç duyduğu kadar yaşar; silme teslimat başına, ortağın takvimine göre olur; ve ortak yalıtımı bedavaya gelir, çünkü her teslimat tek bir ortağa aittir. Aleyhine: tekrar gelen bir Alıcı aynı kişi olarak tanınmaz.

Kurulması gereken denge bu. Birkaç teslimatı aynı yerdeki aynı kişi olarak tanımaya hiç ihtiyaç olacak mı? O kişiye bir oturum açma hakkı vermeye? Kendine ait bir kayda ihtiyaç duyan bir Alıcı ile yalnızca teslimatla ilgili veri olan Alıcı ayrıntıları arasındaki çizgi budur. Ve bir orta yol var. Perakende Ortağının kendi müşteri kimliğini teslimatta bir alan olarak taşıyın: bir Perakende Ortağı Müşteri Kimliği (Retail Partner Customer ID). Bir Alıcı kaydı oluşturmaz, ama bir ortağın aynı müşteri için gönderdiği teslimatları birbirine bağlar; bu daha birleşik bir müşteri deneyiminin başlangıcıdır ve doğrudan o müşterinin gerçekten yaşadığı yere, Perakende Ortağının sistemine geri götürür. Onların tanımlayıcısıdır, bu yüzden yalnızca ortakla birlikte bir anlam taşır: bir ortağın 4417 numaralı müşterisinin bir başkasınınkiyle hiçbir ilgisi yoktur.

Profesyonel görüşüme göre doğru seçim C Seçeneği. Tanınmama kısmı kabul edilebilir, hatta arzu edilir: Steve Trucking’in bu insanlarla teslimatın ötesinde bir ilişkisi yok. Bu yine 1. modül: Alıcı ortağın müşterisidir ve kim olduklarının yetkilisi ortaktır. Ve bu 5. bölüm: tek bir yere düşen, tek bir teslimata bağlı kişisel veriyi korumak, saklamak ve silmek çok daha kolaydır. Ve 2. bölümün normal formlarına da dayanır: Alıcının ayrıntıları teslimatla bire birdir, dolayısıyla ona aittir. Ayrı bir Alıcı alt kaydı, bir nesne daha, bir ilişki daha ve bunların ek yükü pahasına birkaç tekrarlanan değerden tasarruf ederdi; daha fazlasından tasarruf etmesinin tek yolu aynı kişiyi Perakende Ortakları genelinde tek kişi olarak ele almak olurdu ve bunu yapmayacağız. Dolayısıyla Alıcıyı teslimat taşır; ortağın kendi sistemine geri dönüş yolu da Perakende Ortağı Müşteri Kimliğidir.

Click to enlarge

Alıcıları Ortaklar Arasında Birleştirir miydim?

John Smith, 123 Main Street, Redrock’un yük listesinde ve Brightwave’inkinde görünüyor. Muhtemelen aynı kişi. Steve Trucking onları birleştirmeli mi? Hayır, bilerek hayır. Alıcıları Perakende Ortakları arasında birleştirmek S2’yi ihlal ederdi: bir ortak asla başka bir ortağın Alıcılarını görmemelidir ve birleşik bir kimlik tam olarak sızdıran köprüdür. Bu, bu bölümün pozisyonunun uygulanmasıdır: karıştırmanın pahalı olduğu yerde eksik eşleştirin; burada da karıştırma çok pahalı.

Bir Perakende Ortağı daha sonra kendi teslimatları içinde tekrar gelen Alıcıların tanınmasını isterse bu, Data 360’ınki gibi bir kimlik çözümleme aracının, o ortakla sınırlandırılmış olarak, işidir: kişi hesabı değil, kayıt defteri tarzı bir harita ve asla ortaklar arası değil. Kimin kim olduğunun haritası sahiplik vermez, erişim de vermez.

Org’da Ne Kalır, Ne Kalmaz

3. bölüm verinin nerede yaşaması gerektiğini sordu. Burada sıfırlar yanıtlıyor:

• Güncel durum Servis Randevusu’nda ve İş Emri’nde yaşar. Durum değişikliklerinin geçmişi, yılda yaklaşık 8 milyon ve büyüyerek, çekirdek org’da yaşamak zorunda değil. Her değişiklik bir olay olarak yayımlanır ve ambarda, Snowflake’te tutulur. Org güncel durumu tutar; geçmiş servis, operasyon ve analitik için hâlâ oradadır, yalnızca operasyonel veritabanında değil.
• Fotoğraflar (yılda dört beş milyon, bazıları insanları ya da bir evin içini gösteriyor) bu hacim için inşa edilmiş depolamada, çekirdeğin dışında yaşar ve doğrudan ekibin uygulamasından yüklenir. Org yalnızca ihtiyaç duyduğunu tutar: fotoğraf başına küçük bir dizin kaydı ya da yalnızca bir sayı ve “gerekli kurulum fotoğrafları tamam” işareti. Tercihim daha hafif seçenek: org’u yalın tutun, dizinin ve saklamanın sahibi fotoğraf deposu olsun.
• GPS okumaları (günde 200.000) FleetLink’te kalır ve Snowflake’e gider; org’un takip sayfası ve sevk görevlisinin haritası için yalnızca en son konuma ihtiyacı vardır.
• RouteDesk’in sekiz yıllık geçmişi (yaklaşık 5 milyon teslimat) ambara ya da bir arşive gider ve talepler için erişilebilir olur. Org’a ne geleceği, eğer bir şey gelecekse, 2. Kısım’ın taşıma kararıdır.

Click to enlarge

1. Kontrol Noktası: ben nasıl tasarlardım. 4. bölümün haritasıyla aynı yerler (Steve Trucking’in Sistem Haritası); yeniden girme ve elektronik tablo ortadan kalkmış.

Kim Neyi Görür ve Kimin Lisansa İhtiyacı Var

• Perakende Ortakları yalnızca kendi teslimatlarını görür (S2). Her İş Emri kendi Perakende Ortağını taşır; portal kullanıcıları kendi ortaklarının teslimatlarını, DC müdürleri de yalnızca kendi DC’lerininkini görür.
• Ortak kullanıcılarının paylaşım kurallarını ve rolleri destekleyen bir portal lisansına ihtiyacı var: Customer Community Plus ya da Partner Community. 3. bölümün stadyum koltukları: en ucuz koltuklar bu tasarımın ihtiyaç duyduğu paylaşımı almaz. Her iki lisans da harici kullanıcılar için roller gerektirir ve Salesforce daha fazla rolün org’u yavaşlattığı konusunda uyarır (Experience Cloud User Licenses (opens in a new tab), İngilizce). Ortak başına ve DC başına bir rol sorun değil; her mağaza için bir rol sorundur.

Sınav bilgisi. Hangi harici lisansların standart paylaşım taşıdığını bilin: Customer Community Plus ve Partner Community (harici kullanıcılar için rollerle); paylaşım kümeleri (sharing sets) kullanan Customer Community değil.

• Alıcıların lisansa ihtiyacı yok. Takip sayfası tek bir teslimatı oturum açma yerine süresi dolan bir belirteçli bağlantıyla gösterir (S3).
• Çarpıklığa dikkat edin. Yılda üç dört ortak hesabına işaret eden yüz binlerce İş Emri bir hesap veri çarpıklığıdır. Bir seçenek, her ortağın altında DC başına bir alt hesaptır; bu, alt kayıtları dokuz ya da daha fazla yola yayar; tamamlanan teslimatları talep süresinden sonra arşivlemek de üst kayıt başına etkin alt kayıtları düşük tutar. 2. Kısım bunu ele alıyor.

Ne Yapmazdım

Bir Alıcı bir birey diye her Alıcı için bir kişi hesabı oluşturmazdım. Üç hesaba bir milyon Kişi asmazdım. Field Service’in İş Emri’nin yanına özel bir Teslimat nesnesi inşa etmezdim. Alıcıları ortaklar arasında birleştirmezdim. Milyonlarca fotoğrafı ya da GPS okumasını çekirdek depolamaya koymazdım. Ve gerçekten bir ana veri kararı vermediysek birleşik bir Alıcıya altın kayıt demezdim.

Hâlâ Açık Olanlar

1. Kısım iskeleti kurdu; 2. Kısım onu sınıyor. Üçüncü yılda büyük veri hacmi cetveli (İş Emirleri, Servis Randevuları ve satır öğeleri iki üç yıl içinde büyük hacim bölgesine giriyor), ortakla sınırlandırılmış liste görünümleri için sorgu tasarımı, üç gelen entegrasyon ve üç durum akışı, RouteDesk taşıması, o günkü işlemler ve portalın arkasındaki güvenlik tasarımı. Steve Trucking de değişecek. Bu tasarımı saklayın; ona geri döneceksiniz.

Mimarın Burada Karar Verdikleri

• Çekirdeği hangi standart nesnelerin taşıdığı (burada Field Service’inkiler) ve hangi özel nesnelerin gerçekten haklı olduğu (burada bir tane).
• Her ortağın sipariş satırını bir teslimatla eşleştiren anahtar ve neden ortağa ait olduğu.
• Steve Trucking’in onlarla gerçekte sahip olduğu ilişkiye göre Alıcının ne olduğu.
• Kimliklerin birleştirilip birleştirilmeyeceği ve karıştırmanın göze alınamayacak kadar pahalı olduğu yer.
• Org’da neyin kaldığı, neyin çekirdeğin dışında yaşadığı ve tasarımın hangi lisanslara dayandığı.

Daha Fazlası

• Steve Trucking senaryo özeti ve alıştırmalar (D1, D3, DC1; İngilizce).
• 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) ve Experience Cloud User Licenses (opens in a new tab) (İngilizce), kontrol tarihi 2026-10-14.
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (İngilizce), 3. bölümde alıntılandığı gibi.