Steve Trucking, Arsitektur Pilihan Saya
Juga tersedia dalam 28 bahasa
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 6 dari 6 dalam bab Data Master dan Identitas, bab 6 kursus Data Architect, dan akhir Bagian 1. Sebelumnya: Ketika Otoritas Dibagi · Berikutnya: Bagian 2 dimulai dengan Merancang untuk Skala (coming soon)
Pertanyaan yang dijawab checkpoint ini: Bisakah Anda menyatukan Bagian 1 pada skenario yang nyata?
Coba tantangannya lebih dulu. Ini adalah pembahasan saya atas tantangan Checkpoint 1. Jika Anda belum menggambar desain Anda sendiri, lakukan itu sebelum membaca lebih lanjut. Nilainya ada pada membandingkan penalaran Anda dengan penalaran saya, bukan pada membaca jawabannya.
Inilah “Arsitektur Pilihan Saya” (What I Would Architect): sebuah solusi yang layak, bukan satu-satunya jawaban, dengan trade-off yang disebutkan dan posisi saya yang jelas. Kita belum membahas volume data besar, desain kueri, pola integrasi, migrasi, atau transaksi, dan itu disengaja: arsitektur berkembang seiring Anda belajar lebih banyak. Tetapi Bagian 1 sudah memberi kita cukup bekal untuk menetapkan kerangkanya.
Mulailah dari Angkanya
Section titled “Mulailah dari Angkanya ”Dari ringkasannya: sekitar 3.300 pengiriman per hari kerja, satu juta per tahun, bertumbuh 30% per tahun. Sekitar 1,6 item baris per pengiriman (1,6 juta per tahun); sekitar delapan perubahan status per pengiriman (8 juta per tahun); empat sampai lima juta foto per tahun; sekitar 200.000 pembacaan GPS per hari; sekitar 180.000 kasus per tahun; tiga Mitra Ritel yang mengirim manifes dengan tiga cara berbeda; sembilan pusat distribusi; 330 truk dengan kru dua orang. Dan Steve Trucking sudah menjalankan satu org Salesforce dengan Service Cloud, Field Service, dan portal mitra. Hitung nolnya sebelum menggambar satu kotak pun. Angka-angka itulah yang akan memutuskan beberapa hal di bawah ini.
Inti Pengiriman: Lihat ke Kapal Induk
Section titled “Inti Pengiriman: Lihat ke Kapal Induk ”Pengiriman adalah jantungnya, dan Field Service sudah menangani dispatch. Jadi saya memulai dari model standar Field Service, seperti yang dilakukan potongan model di bab 3:
| Konsep bisnis | Objek Salesforce | Alasan |
|---|---|---|
| Mitra Ritel | Akun (tipe rekaman Retail Partner) | Bisnis yang dikontrak Steve Trucking; membawa kontrak, kasus, dan akses portal |
| Staf mitra (manajer DC, staf toko) | Kontak | Pengguna portal harus berupa Kontak |
| Satu pengiriman: satu Penerima, satu alamat, satu pesanan mitra, satu hari | Perintah Kerja (Work Order) | Unit kerja Field Service; penjadwalan, aplikasi seluler, dan laporan layanan bergantung padanya |
| Setiap barang atau layanan: kulkasnya, pemasangannya, pengangkutan barang lamanya | Item Baris Perintah Kerja (Work Order Line Item) | Membagi pekerjaan, menggerakkan daftar periksa dan penagihan |
| Jenis titik pemberhentian: hanya pengiriman, dengan pemasangan, dengan pengangkutan barang lama | Tipe Pekerjaan (Work Type) | Menetapkan durasi, keterampilan, dan daftar periksa pemasangan |
| Kunjungan terjadwal dan jendela waktunya | Janji Layanan (Service Appointment) | Yang dijadwalkan Field Service dan ditampilkan di aplikasi kru |
| Kru dan truk; area dispatch DC | Service Resource, Service Crew, Service Territory | Field Service menjadwalkan satu kru sebagai satu sumber daya |
| Pertanyaan Penerima, klaim mitra | Kasus | Konsol layanan, entitlement, email-to-case |
| Daftar milik mitra untuk hari Selasa di DC Phoenix | Manifest__c (kustom) | Tidak ada objek standar yang merepresentasikan unit penerimaan, rekonsiliasi, dan pengulangan |
Semua yang lain tetap standar. Menahan diri dari objek kustom tambahan itu disengaja: pertanyaan di bab 1 adalah kapan seorang arsitek harus menolak satu objek lagi, dan di sini jawabannya adalah “hampir selalu.” Baris pesanan mitra, misalnya, bukan objek baru. Itu adalah Perintah Kerja, yang diidentifikasi oleh referensi milik mitra.
Diagram ini tumbuh dari diagram final bab 3 (Rancang Model Fisik Salesforce): objek yang sama di tempat yang sama, ditambah kru, area dispatch, kasus, dan apa yang oleh Checkpoint 1 disimpan di luar core.
Kunci yang Mencocokkan Pesanan Mitra dengan Sebuah Pengiriman
Section titled “Kunci yang Mencocokkan Pesanan Mitra dengan Sebuah Pengiriman ”Setiap baris manifes menjadi satu Perintah Kerja, yang ditautkan ke Manifes-nya. Kuncinya adalah pertanyaan yang paling ingin saya jawab: bagaimana kita tahu bahwa baris dari mitra ini adalah pengiriman itu? Jawaban saya: sebuah External ID pada Perintah Kerja yang dibangun dari Mitra Ritel dan referensi pesanan serta pengiriman milik mitra itu sendiri (kira-kira seperti KEYSTONE-PHX-8843119-1), ditandai unik. Satu bidang per sumber, satu-ke-satu. Itu pengenal milik mitra, bukan milik kita: “beberapa pengenal untuk satu hal” dari bab 2, dan “mitra memiliki referensi pesanannya” dari modul 1.
Mengapa ini penting: manifes tiba satu sampai dua hari sebelumnya dan direvisi di hari yang sama. Dengan kunci itu, setiap manifes yang dikirim ulang atau direvisi akan melakukan upsert alih-alih membuat duplikat. Revisinya memperbarui Perintah Kerja, sebuah bidang mencatatnya, dan perubahan pada pengiriman yang sudah masuk rute memberi peringatan kepada koordinator: perubahan mitra diterapkan, tetapi ditandai sampai dispatch mengonfirmasinya. Inilah juga yang berubah dari gambaran di bab 4. Saat ini setiap manifes mendarat di RouteDesk, dan para koordinator mengetik ulang rute ke Salesforce dan mengetik balik titik pemberhentian yang sudah selesai. Dalam desain ini manifes masuk langsung ke Salesforce, di-upsert dengan kunci mitra; RouteDesk dipensiunkan, dan pengetikan ulang berakhir. Bab Integrasi merancang ketiga format masuk. Keputusan datanya adalah kuncinya.
Penerima: Akun Pribadi, Kontak, atau Bukan Keduanya?
Section titled “Penerima: Akun Pribadi, Kontak, atau Bukan Keduanya? ”Ini keputusan data paling menarik di Bagian 1, jadi inilah opsi-opsinya, lalu pilihan saya.
Opsi A: akun pribadi. Setiap Penerima menjadi akun pribadi, yang ditautkan ke setiap pengiriman. Kelebihannya: standar, berjalan alami dengan Service Cloud, perpesanan, dan konsol, mengenali Penerima yang berulang. Kekurangannya: sekitar satu juta Penerima baru per tahun, masing-masing akun pribadi dengan kebutuhan penyimpanan kira-kira dua kali akun bisnis (Estimated Record Size by Object Type (opens in a new tab)), sehingga dalam dua tahun menjadi salah satu objek terbesar di org. Dan Penerima bukanlah pelanggan Steve Trucking. Mereka adalah pelanggan masing-masing Mitra Ritel, dan Steve Trucking tidak boleh pernah mencampur pelanggan satu mitra dengan mitra lain (S2).
Opsi B: Kontak di bawah akun Mitra Ritel. Kekurangannya: satu juta Kontak di bawah tiga atau empat akun adalah skew induk-anak dalam skala raksasa, jauh melampaui panduan Salesforce sekitar 10.000 anak per induk (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). Ini opsi untuk ditunjukkan, lalu ditolak.
Opsi C: Penerima tinggal di pengiriman. Nama, telepon, email, alamat, dan catatan pengiriman Penerima menjadi bidang di Perintah Kerja (bidang alamat sudah standar di sana), diambil dari manifes. Kelebihannya: tidak ada objek besar baru; datanya hidup persis selama pengiriman membutuhkannya; penghapusan terjadi per pengiriman, sesuai jadwal mitra; dan isolasi mitra didapat dengan sendirinya, karena setiap pengiriman milik satu mitra. Kekurangannya: Penerima yang berulang tidak dikenali sebagai orang yang sama.
Itulah keseimbangan yang perlu dicapai. Apakah suatu saat akan ada kebutuhan untuk mengenali beberapa pengiriman sebagai orang yang sama, di tempat yang sama? Untuk memberi orang itu akses login? Itulah garis antara Penerima yang butuh rekaman sendiri dan detail Penerima yang sekadar data tentang pengiriman. Dan ada jalan tengah. Bawa ID pelanggan milik Mitra Ritel sendiri sebagai bidang pada pengiriman, sebuah Retail Partner Customer ID (ID Pelanggan Mitra Ritel). Bidang itu tidak membuat rekaman Penerima, tetapi menghubungkan pengiriman-pengiriman yang dikirim seorang mitra untuk pelanggan yang sama, yang menjadi awal dari pengalaman pelanggan yang lebih terpadu, dan ia membawa Anda langsung kembali ke sistem Mitra Ritel, tempat pelanggan itu sebenarnya berada. Itu pengenal milik mereka, jadi ia hanya bermakna bersama mitranya: pelanggan 4417 milik satu mitra sama sekali tidak ada hubungannya dengan pelanggan 4417 milik mitra lain.
Menurut pendapat profesional saya, Opsi C adalah pilihan yang tepat. Bagian tidak dikenali itu bisa diterima, bahkan diinginkan: Steve Trucking tidak punya hubungan dengan orang-orang ini di luar pengiriman. Ini modul 1 lagi: Penerima adalah pelanggan mitra, dan mitra adalah otoritas atas siapa mereka. Dan ini bab 5: data pribadi yang mendarat di satu tempat, terikat pada satu pengiriman, jauh lebih mudah dilindungi, disimpan, dan dihapus. Dan pilihan ini lolos uji bentuk normal dari bab 2: detail Penerima satu-satu dengan pengiriman, jadi tempatnya memang di pengiriman. Objek anak Penerima yang terpisah hanya menghemat beberapa nilai yang berulang dengan harga satu objek lagi, satu hubungan lagi, dan beban tambahannya, dan satu-satunya cara agar penghematannya lebih besar adalah memperlakukan orang yang sama sebagai satu orang lintas Mitra Ritel, yang tidak akan kita lakukan. Jadi pengirimanlah yang membawa Penerima, dengan Retail Partner Customer ID sebagai jalan kembali ke sistem milik mitra itu sendiri.
Apakah Saya Akan Menyatukan Penerima Lintas Mitra?
Section titled “Apakah Saya Akan Menyatukan Penerima Lintas Mitra? ”John Smith, 123 Main Street, muncul di manifes Redrock dan Brightwave. Kemungkinan besar orang yang sama. Haruskah Steve Trucking menyatukannya? Tidak, dengan sengaja tidak. Menyatukan Penerima lintas Mitra Ritel akan melanggar S2: sebuah mitra tidak boleh pernah melihat Penerima milik mitra lain, dan identitas terpadu justru merupakan jembatan yang membocorkannya. Ini posisi bab ini yang diterapkan: lakukan pencocokan lebih sedikit di tempat pencampuran itu mahal, dan di sini pencampuran sangat mahal.
Jika kelak sebuah Mitra Ritel ingin Penerima yang berulang dikenali di dalam pengirimannya sendiri, itu pekerjaan untuk alat resolusi identitas, seperti milik Data 360, yang dibatasi pada mitra itu: peta bergaya registri, bukan akun pribadi, dan tidak pernah lintas mitra. Peta tentang siapa adalah siapa tidak memberi kepemilikan, dan tidak memberi akses.
Apa yang Tetap di Org, dan Apa yang Tidak
Section titled “Apa yang Tetap di Org, dan Apa yang Tidak ”Bab 3 bertanya di mana data seharusnya tinggal. Jumlah nolnya menjawab di sini:
- Status saat ini tinggal di Janji Layanan dan Perintah Kerja. Riwayat perubahan status, sekitar 8 juta per tahun dan terus bertambah, tidak perlu tinggal di org inti. Setiap perubahan diterbitkan sebagai event dan disimpan di data warehouse, yaitu Snowflake. Org menyimpan keadaan saat ini; riwayatnya tetap tersedia untuk layanan, operasional, dan analitik, hanya saja tidak di database operasional.
- Foto (empat sampai lima juta per tahun, sebagian memperlihatkan orang atau bagian dalam rumah) tinggal di luar core di penyimpanan yang dibangun untuk volume itu, diunggah langsung dari aplikasi kru. Org hanya menyimpan apa yang dibutuhkannya: rekaman indeks kecil per foto, atau sekadar jumlah dan penanda “foto pemasangan yang wajib sudah lengkap”. Saya lebih memilih opsi yang lebih ringan: jaga org tetap ramping, dan biarkan penyimpanan foto memiliki indeks dan retensinya sendiri.
- Pembacaan GPS (200.000 per hari) tetap di FleetLink dan dikirim ke Snowflake; org hanya butuh posisi terakhir untuk halaman pelacakan dan peta dispatcher.
- Riwayat delapan tahun RouteDesk (sekitar 5 juta pengiriman) dipindahkan ke data warehouse atau sebuah arsip, tetap bisa dijangkau untuk klaim. Apa, jika ada, yang masuk ke org adalah keputusan migrasi untuk Bagian 2.
Checkpoint 1: arsitektur pilihan saya. Tempat-tempat yang sama dengan lanskap di bab 4 (Lanskap Steve Trucking), tanpa pengetikan ulang dan tanpa spreadsheet.
Siapa Melihat Apa, dan Siapa Butuh Lisensi
Section titled “Siapa Melihat Apa, dan Siapa Butuh Lisensi ”- Mitra Ritel hanya melihat pengirimannya sendiri (S2). Setiap Perintah Kerja membawa Mitra Ritel-nya; pengguna portal melihat pengiriman mitranya, dan manajer DC hanya melihat milik DC-nya.
- Pengguna mitra butuh lisensi portal yang mendukung aturan berbagi dan peran: Customer Community Plus atau Partner Community. Ingat kursi stadion dari bab 3: kursi termurah tidak mendapat kemampuan berbagi yang dibutuhkan desain ini. Kedua lisensi itu butuh peran untuk pengguna eksternal, dan Salesforce memperingatkan bahwa makin banyak peran membuat org makin lambat (Experience Cloud User Licenses (opens in a new tab)). Satu peran per mitra dan per DC tidak masalah; satu peran untuk setiap toko tidak.
Pengetahuan untuk ujian. Ketahui lisensi eksternal mana yang membawa berbagi standar: Customer Community Plus dan Partner Community (dengan peran untuk pengguna eksternal), bukan Customer Community, yang memakai set berbagi.
- Penerima tidak butuh lisensi. Halaman pelacakan menampilkan satu pengiriman melalui tautan dengan token yang kedaluwarsa (S3), bukan login.
- Waspadai skew. Ratusan ribu Perintah Kerja per tahun yang menunjuk ke tiga atau empat akun mitra adalah skew data akun. Salah satu opsinya adalah akun anak per DC di bawah setiap mitra, yang menyebarkan anak-anaknya ke sembilan atau lebih induk; mengarsipkan pengiriman yang sudah selesai setelah masa klaim menjaga jumlah anak aktif per induk tetap rendah. Bagian 2 membahas hal itu.
Yang Tidak Akan Saya Lakukan
Section titled “Yang Tidak Akan Saya Lakukan ”Saya tidak akan membuat akun pribadi untuk setiap Penerima hanya karena Penerima adalah seorang individu. Saya tidak akan menggantungkan satu juta Kontak di tiga akun. Saya tidak akan membangun objek Pengiriman kustom di samping Perintah Kerja milik Field Service. Saya tidak akan menyatukan Penerima lintas mitra. Saya tidak akan menaruh jutaan foto atau pembacaan GPS di penyimpanan core. Dan saya tidak akan menyebut Penerima yang sudah disatukan sebagai golden record kecuali kita benar-benar telah mengambil keputusan pengelolaan master.
Apa yang Masih Terbuka
Section titled “Apa yang Masih Terbuka ”Bagian 1 menetapkan kerangkanya; Bagian 2 mengujinya. Ukuran LDV di tahun ketiga (Perintah Kerja, Janji Layanan, dan item baris semuanya masuk wilayah volume besar dalam dua sampai tiga tahun), desain kueri untuk tampilan daftar yang dibatasi per mitra, tiga integrasi masuk dan tiga umpan status, migrasi RouteDesk, transaksi di hari pengiriman, dan desain keamanan di balik portal. Steve Trucking juga akan berubah. Simpan desain ini; Anda akan meninjaunya kembali.
Yang Diputuskan Arsitek di Sini
Section titled “Yang Diputuskan Arsitek di Sini ”- Objek standar mana yang memikul intinya (di sini, milik Field Service), dan objek kustom mana yang benar-benar dibenarkan (di sini, satu).
- Kunci yang mencocokkan setiap baris pesanan mitra dengan sebuah pengiriman, dan mengapa kunci itu milik mitra.
- Apa sebenarnya Penerima itu, berdasarkan hubungan yang benar-benar dimiliki Steve Trucking dengan mereka.
- Apakah identitas perlu disatukan, dan di mana pencampuran terlalu mahal untuk dipertaruhkan.
- Apa yang tetap di org, apa yang tinggal di luar core, dan lisensi mana yang menjadi tumpuan desain.
Jelajahi
Section titled “Jelajahi ”- Ringkasan dan tantangan Steve Trucking (D1, D3, DC1), bahasa Inggris.
- Bantuan Salesforce, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) dan Experience Cloud User Licenses (opens in a new tab), dicek 2026-10-14 (bahasa Inggris).
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab), seperti yang dikutip di bab 3 (bahasa Inggris).