Steve Trucking, tôi sẽ thiết kế thế nào
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 6 trong 6 của chương Dữ liệu chủ và danh tính, chương 6 của khóa học Data Architect, và là phần kết của Phần 1. Trước: Khi thẩm quyền được chia sẻ · Tiếp theo: Phần 2 bắt đầu với Thiết kế cho quy mô lớn (coming soon)
Câu hỏi điểm kiểm tra này trả lời: Bạn có ghép được Phần 1 lại trên một tình huống thực tế không?
Hãy làm thử thách trước. Đây là phần hướng dẫn giải của tôi cho thử thách của Điểm kiểm tra 1. Nếu bạn chưa tự vẽ thiết kế của mình, hãy làm điều đó trước khi đọc tiếp. Giá trị nằm ở việc so sánh lập luận của bạn với của tôi, không phải ở việc đọc đáp án.
Đây là “tôi sẽ thiết kế thế nào”: một giải pháp khả thi, không phải đáp án duy nhất, với các đánh đổi được nêu tên và lập trường của tôi được nói rõ. Chúng ta chưa học về khối lượng dữ liệu lớn, thiết kế truy vấn, khuôn mẫu tích hợp, chuyển đổi dữ liệu hay giao dịch, và đó là cố ý: kiến trúc phát triển khi bạn học thêm. Nhưng Phần 1 cho chúng ta đủ để dựng bộ xương.
Bắt đầu với các con số
Phần tiêu đề “Bắt đầu với các con số ”Từ bản mô tả: khoảng 3.300 lần giao hàng mỗi ngày làm việc, một triệu mỗi năm, tăng 30% mỗi năm. Khoảng 1,6 mục dòng mỗi lần giao (1,6 triệu mỗi năm); khoảng tám lần thay đổi trạng thái mỗi lần giao (8 triệu mỗi năm); bốn đến năm triệu ảnh mỗi năm; khoảng 200.000 lần đọc GPS mỗi ngày; khoảng 180.000 trường hợp mỗi năm; ba Đối tác bán lẻ gửi bảng kê hàng theo ba cách khác nhau; chín trung tâm phân phối; 330 xe tải với tổ hai người. Và Steve Trucking đã chạy một org Salesforce với Service Cloud, Field Service và một cổng thông tin đối tác. Hãy đếm các chữ số 0 trước khi vẽ bất kỳ chiếc hộp nào. Chúng sẽ quyết định nhiều điều bên dưới.
Lõi giao hàng: hãy nhìn về phi thuyền mẹ
Phần tiêu đề “Lõi giao hàng: hãy nhìn về phi thuyền mẹ ”Các lần giao hàng là trái tim của nó, và Field Service đã làm việc điều phối. Vì vậy tôi bắt đầu với mô hình chuẩn của Field Service, như lát cắt ở chương 3 đã làm:
| Khái niệm nghiệp vụ | Đối tượng Salesforce | Vì sao |
|---|---|---|
| Đối tác bán lẻ | Tài khoản (loại bản ghi Retail Partner) | Một doanh nghiệp mà Steve Trucking ký hợp đồng; mang hợp đồng, trường hợp và quyền truy cập cổng thông tin |
| Nhân viên đối tác (quản lý DC, nhân viên cửa hàng) | Liên hệ | Người dùng cổng thông tin phải là Liên hệ |
| Một lần giao hàng: một Người nhận, một địa chỉ, một đơn hàng của đối tác, một ngày | Work Order (Lệnh công việc) | Đơn vị công việc của Field Service; lịch hẹn, ứng dụng di động và báo cáo dịch vụ treo trên nó |
| Mỗi mặt hàng hay dịch vụ: tủ lạnh, lắp đặt, chở đồ cũ đi | Work Order Line Item (Mục dòng lệnh công việc) | Chia nhỏ công việc, điều khiển danh sách kiểm tra và lập hóa đơn |
| Loại điểm dừng: chỉ giao hàng, kèm lắp đặt, kèm chở đồ cũ đi | Work Type (Loại công việc) | Đặt thời lượng, kỹ năng và danh sách kiểm tra lắp đặt |
| Chuyến ghé thăm theo lịch và khung giờ của nó | Service Appointment (Cuộc hẹn dịch vụ) | Thứ Field Service xếp lịch và ứng dụng của tổ hiển thị |
| Tổ giao hàng và xe tải; khu vực điều phối của DC | Service Resource, Service Crew, Service Territory | Field Service xếp lịch một tổ như một nguồn lực |
| Thắc mắc của Người nhận, khiếu nại của đối tác | Trường hợp | Bảng điều khiển dịch vụ, entitlement, email-to-case |
| Danh sách của đối tác cho thứ Ba tại DC Phoenix | Manifest__c (tùy chỉnh) | Không có gì chuẩn biểu diễn đơn vị tiếp nhận, đối chiếu và phát lại |
Mọi thứ khác vẫn là chuẩn. Việc cưỡng lại thêm đối tượng tùy chỉnh là có chủ ý: câu hỏi của chương 1 là khi nào một kiến trúc sư nên cưỡng lại thêm một đối tượng nữa, và ở đây câu trả lời là “gần như luôn luôn”. Ví dụ, dòng đơn hàng của đối tác không phải là một đối tượng mới. Nó là Lệnh công việc, được định danh bằng mã tham chiếu của đối tác.
Nó phát triển từ sơ đồ tổng kết của chương 3 (Thiết kế mô hình vật lý Salesforce): cùng các đối tượng ở cùng các vị trí, thêm tổ giao hàng, khu vực điều phối, trường hợp và những gì Điểm kiểm tra 1 giữ ngoài lõi.
Khóa khớp đơn hàng của đối tác với một lần giao hàng
Phần tiêu đề “Khóa khớp đơn hàng của đối tác với một lần giao hàng ”Mỗi dòng của bảng kê hàng trở thành một Lệnh công việc, liên kết với Bảng kê hàng của nó. Khóa là câu hỏi tôi muốn được trả lời nhất: làm sao chúng ta biết dòng này từ đối tác là lần giao hàng kia? Câu trả lời của tôi: một ID bên ngoài trên Lệnh công việc được ghép từ Đối tác bán lẻ và mã tham chiếu đơn hàng và giao hàng của chính đối tác (đại loại như KEYSTONE-PHX-8843119-1), được đánh dấu duy nhất. Một trường cho mỗi nguồn, một-một. Đó là mã định danh của đối tác, không phải của chúng ta: “nhiều mã định danh cho một thứ” của chương 2, và “đối tác sở hữu mã tham chiếu đơn hàng của mình” của mô-đun 1.
Vì sao nó quan trọng: bảng kê hàng đến trước một đến hai ngày và được sửa đổi trong ngày. Với khóa đó, mọi bảng kê hàng được gửi lại hay sửa đổi đều upsert thay vì tạo bản trùng. Bản sửa đổi cập nhật Lệnh công việc, một trường ghi lại điều đó, và một thay đổi đối với lần giao hàng đã được xếp tuyến sẽ cảnh báo điều phối viên: thay đổi của đối tác được áp dụng, nhưng được đánh dấu cho đến khi bộ phận điều phối xác nhận. Đây cũng là điều thay đổi so với bức tranh của chương 4. Hiện nay mọi bảng kê hàng đều đổ vào RouteDesk, và điều phối viên nhập lại tuyến vào Salesforce rồi nhập ngược các điểm dừng đã hoàn thành. Trong thiết kế này, bảng kê hàng đi thẳng vào Salesforce, được upsert theo khóa của đối tác; RouteDesk ngừng hoạt động, và việc nhập lại chấm dứt. Chương Tích hợp thiết kế ba định dạng đầu vào. Quyết định về dữ liệu chính là khóa.
Người nhận: tài khoản cá nhân, Liên hệ, hay không phải cả hai?
Phần tiêu đề “Người nhận: tài khoản cá nhân, Liên hệ, hay không phải cả hai? ”Đây là quyết định dữ liệu thú vị nhất của Phần 1, nên đây là các phương án, rồi đến lựa chọn của tôi.
Phương án A: tài khoản cá nhân. Mỗi Người nhận trở thành một tài khoản cá nhân, liên kết với mọi lần giao hàng. Ủng hộ: chuẩn, hoạt động tự nhiên với Service Cloud, nhắn tin và bảng điều khiển, nhận ra Người nhận quay lại. Phản đối: khoảng một triệu Người nhận mới mỗi năm, mỗi người là một tài khoản cá nhân chiếm khoảng gấp đôi dung lượng của tài khoản doanh nghiệp (Estimated Record Size by Object Type (opens in a new tab), tiếng Anh), nên trong vòng hai năm nó sẽ là một trong những đối tượng lớn nhất trong org. Và Người nhận không phải là khách hàng của Steve Trucking. Họ là khách hàng của từng Đối tác bán lẻ, và Steve Trucking không bao giờ được trộn khách hàng của đối tác này với của đối tác khác (S2).
Phương án B: Liên hệ dưới tài khoản của Đối tác bán lẻ. Phản đối: một triệu Liên hệ dưới ba hay bốn tài khoản là lệch dữ liệu cha-con ở quy mô khổng lồ, vượt xa hướng dẫn khoảng 10.000 bản ghi con mỗi bản ghi cha của Salesforce (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), tiếng Anh). Đây là phương án để trình bày, và bác bỏ.
Phương án C: Người nhận nằm trên lần giao hàng. Tên, điện thoại, email, địa chỉ và ghi chú giao hàng của Người nhận là các trường trên Lệnh công việc (các trường địa chỉ đã có sẵn ở đó), được ghi nhận từ bảng kê hàng. Ủng hộ: không có đối tượng lớn mới; dữ liệu sống đúng bằng thời gian lần giao hàng cần nó; việc xóa diễn ra theo từng lần giao, theo lịch của đối tác; và sự cô lập giữa các đối tác có sẵn miễn phí, vì mỗi lần giao hàng thuộc về một đối tác. Phản đối: một Người nhận quay lại không được nhận ra là cùng một người.
Đó là thế cân bằng cần tìm. Liệu có bao giờ cần nhận ra nhiều lần giao hàng là cùng một người, ở cùng một nơi không? Cần cho người đó một tài khoản đăng nhập không? Đó là ranh giới giữa một Người nhận cần một bản ghi riêng và thông tin Người nhận chỉ đơn giản là dữ liệu về lần giao hàng. Và có một con đường ở giữa. Mang chính ID khách hàng của Đối tác bán lẻ thành một trường trên lần giao hàng, một ID khách hàng của Đối tác bán lẻ (Retail Partner Customer ID). Nó không tạo ra bản ghi Người nhận, nhưng nó nối các lần giao hàng mà một đối tác gửi cho cùng một khách hàng, đó là bước khởi đầu cho một trải nghiệm khách hàng thống nhất hơn, và nó dẫn thẳng về hệ thống của Đối tác bán lẻ, nơi khách hàng đó thực sự thuộc về. Đó là mã định danh của họ, nên nó chỉ có nghĩa khi đi cùng đối tác: khách hàng 4417 của một đối tác chẳng liên quan gì đến khách hàng 4417 của đối tác khác.
Theo ý kiến chuyên môn của tôi, Phương án C là lựa chọn đúng. Phần không được nhận ra là chấp nhận được, thậm chí đáng mong muốn: Steve Trucking không có quan hệ gì với những người này ngoài lần giao hàng. Lại là mô-đun 1: Người nhận là khách hàng của đối tác, và đối tác là bên có thẩm quyền về việc họ là ai. Và đó là chương 5: dữ liệu cá nhân rơi vào một chỗ, gắn với một lần giao hàng, dễ bảo vệ, lưu giữ và xóa hơn rất nhiều. Và nó đứng vững trước các dạng chuẩn của chương 2: thông tin của Người nhận là quan hệ một-một với lần giao hàng, nên chúng thuộc về lần giao hàng. Một bản ghi con Người nhận riêng sẽ tiết kiệm được vài giá trị lặp lại, đổi lại thêm một đối tượng, thêm một quan hệ và chi phí đi kèm, và cách duy nhất để nó tiết kiệm nhiều hơn là xem cùng một người là một trên nhiều Đối tác bán lẻ, điều chúng ta sẽ không làm. Vì vậy lần giao hàng mang Người nhận, với ID khách hàng của Đối tác bán lẻ là đường dẫn ngược về hệ thống của chính đối tác.
Tôi có hợp nhất Người nhận giữa các đối tác không?
Phần tiêu đề “Tôi có hợp nhất Người nhận giữa các đối tác không? ”John Smith, 123 Main Street, xuất hiện trong bảng kê hàng của Redrock và của Brightwave. Có lẽ là cùng một người. Steve Trucking có nên hợp nhất họ không? Không, cố ý không. Hợp nhất Người nhận giữa các Đối tác bán lẻ sẽ vi phạm S2: một đối tác không bao giờ được thấy Người nhận của đối tác khác, và một danh tính hợp nhất chính là cây cầu làm rò rỉ. Đó là lập trường của chương này được áp dụng: khớp ít ở nơi việc trộn lẫn tốn kém, và ở đây việc trộn lẫn rất tốn kém.
Nếu sau này một Đối tác bán lẻ muốn nhận ra Người nhận quay lại trong phạm vi các lần giao hàng của riêng mình, đó là việc của một công cụ phân giải danh tính, như của Data 360, giới hạn trong đối tác đó: một bản đồ kiểu registry, không phải tài khoản cá nhân, và không bao giờ vượt qua các đối tác. Một bản đồ ai là ai không trao quyền sở hữu, và cũng không trao quyền truy cập.
Cái gì ở lại trong org, và cái gì không
Phần tiêu đề “Cái gì ở lại trong org, và cái gì không ”Chương 3 hỏi dữ liệu nên nằm ở đâu. Các chữ số 0 trả lời điều đó ở đây:
- Trạng thái hiện tại nằm trên Cuộc hẹn dịch vụ và Lệnh công việc. Lịch sử các lần thay đổi trạng thái, khoảng 8 triệu mỗi năm và đang tăng, không cần nằm trong org lõi. Mỗi thay đổi được phát đi như một sự kiện và được giữ trong kho dữ liệu, Snowflake. Org giữ trạng thái hiện tại; lịch sử vẫn ở đó cho dịch vụ, vận hành và phân tích, chỉ là không nằm trong cơ sở dữ liệu vận hành.
- Ảnh (bốn đến năm triệu mỗi năm, một số cho thấy con người hay bên trong một ngôi nhà) nằm ngoài lõi trong bộ lưu trữ được xây cho khối lượng đó, được tải lên thẳng từ ứng dụng của tổ giao hàng. Org chỉ giữ những gì nó cần: một bản ghi chỉ mục nhỏ cho mỗi ảnh, hoặc chỉ một số đếm và một cờ “đã đủ ảnh lắp đặt bắt buộc”. Tôi thích phương án nhẹ hơn: giữ org gọn nhẹ, và để kho ảnh sở hữu chỉ mục và việc lưu giữ của nó.
- Lần đọc GPS (200.000 mỗi ngày) ở lại trong FleetLink và đi vào Snowflake; org chỉ cần vị trí mới nhất cho trang theo dõi và bản đồ của điều phối viên.
- Tám năm lịch sử của RouteDesk (khoảng 5 triệu lần giao hàng) đi vào kho dữ liệu hoặc một kho lưu trữ, có thể truy cập cho việc khiếu nại. Cái gì, nếu có, đi vào org là một quyết định chuyển đổi dữ liệu cho Phần 2.
Điểm kiểm tra 1: những gì tôi sẽ thiết kế. Cùng các vị trí như bản đồ hệ thống của chương 4 (Bản đồ hệ thống của Steve Trucking), không còn việc nhập lại và bảng tính.
Ai thấy gì, và ai cần giấy phép
Phần tiêu đề “Ai thấy gì, và ai cần giấy phép ”- Đối tác bán lẻ chỉ thấy các lần giao hàng của chính mình (S2). Mỗi Lệnh công việc mang Đối tác bán lẻ của nó; người dùng cổng thông tin thấy các lần giao hàng của đối tác mình, và quản lý DC chỉ thấy của DC mình.
- Người dùng đối tác cần một giấy phép cổng thông tin hỗ trợ quy tắc chia sẻ và vai trò: Customer Community Plus hoặc Partner Community. Những chỗ ngồi trong sân vận động của chương 3: chỗ rẻ nhất không có kiểu chia sẻ mà thiết kế này cần. Cả hai giấy phép đều cần vai trò cho người dùng bên ngoài, và Salesforce cảnh báo rằng càng nhiều vai trò thì org càng chậm (Experience Cloud User Licenses (opens in a new tab), tiếng Anh). Một vai trò cho mỗi đối tác và mỗi DC là ổn; một vai trò cho mỗi cửa hàng thì không.
Kiến thức hay ra thi. Hãy biết những giấy phép bên ngoài nào có chia sẻ chuẩn: Customer Community Plus và Partner Community (với vai trò cho người dùng bên ngoài), không phải Customer Community, vốn dùng sharing set.
- Người nhận không cần giấy phép. Trang theo dõi hiển thị một lần giao hàng qua một đường dẫn với token có hạn dùng (S3), không phải đăng nhập.
- Hãy để ý lệch dữ liệu. Hàng trăm nghìn Lệnh công việc mỗi năm trỏ đến ba hay bốn tài khoản đối tác là lệch dữ liệu tài khoản. Một phương án là một tài khoản con cho mỗi DC dưới từng đối tác, giúp phân tán các bản ghi con ra chín hướng trở lên; lưu trữ các lần giao hàng đã hoàn tất sau thời hạn khiếu nại giữ cho số bản ghi con đang hoạt động trên mỗi bản ghi cha ở mức thấp. Phần 2 sẽ giải quyết điều đó.
Những gì tôi sẽ không làm
Phần tiêu đề “Những gì tôi sẽ không làm ”Tôi sẽ không tạo một tài khoản cá nhân cho mỗi Người nhận chỉ vì Người nhận là một cá nhân. Tôi sẽ không treo một triệu Liên hệ dưới ba tài khoản. Tôi sẽ không xây một đối tượng Delivery tùy chỉnh bên cạnh Lệnh công việc của Field Service. Tôi sẽ không hợp nhất Người nhận giữa các đối tác. Tôi sẽ không đặt hàng triệu ảnh hay lần đọc GPS vào bộ lưu trữ lõi. Và tôi sẽ không gọi một Người nhận đã hợp nhất là bản ghi vàng trừ khi chúng ta thực sự đã đưa ra một quyết định quản lý dữ liệu chủ.
Những gì vẫn còn để ngỏ
Phần tiêu đề “Những gì vẫn còn để ngỏ ”Phần 1 dựng bộ xương; Phần 2 thử thách nó. Thước đo LDV ở năm thứ ba (Lệnh công việc, Cuộc hẹn dịch vụ và mục dòng đều thuộc vùng khối lượng lớn trong vòng hai đến ba năm), thiết kế truy vấn cho list view theo phạm vi đối tác, ba tích hợp đầu vào và ba nguồn cấp trạng thái, việc chuyển đổi dữ liệu từ RouteDesk, các giao dịch trong ngày, và thiết kế bảo mật đằng sau cổng thông tin. Steve Trucking cũng sẽ thay đổi. Hãy giữ thiết kế này; bạn sẽ quay lại với nó.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Những đối tượng chuẩn nào mang phần lõi (ở đây là của Field Service), và những đối tượng tùy chỉnh nào thực sự được biện minh (ở đây là một).
- Khóa khớp mỗi dòng đơn hàng của đối tác với một lần giao hàng, và vì sao nó thuộc về đối tác.
- Người nhận là gì, dựa trên quan hệ mà Steve Trucking thực sự có với họ.
- Có hợp nhất danh tính không, và ở đâu việc trộn lẫn quá tốn kém để mạo hiểm.
- Cái gì ở lại trong org, cái gì nằm ngoài lõi, và thiết kế phụ thuộc vào những giấy phép nào.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Bản mô tả và các thử thách của 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) và Experience Cloud User Licenses (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (tiếng Anh), như đã dẫn trong chương 3.