Tích hợp và di chuyển dữ liệu
Cũng có bằng 19 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Hướng dẫn ôn tập cho chương 9 của khóa học Data Architect. Hãy đọc bốn mô-đun trước; trang này giúp bạn kiểm tra những gì đã đọng lại.
Về hướng dẫn ôn tập này. Nó chỉ được xây dựng từ nội dung của chính khóa học này và danh sách mục tiêu trong hướng dẫn thi đã công bố của Salesforce. Nó không bao giờ dựa trên câu hỏi thi thật, và không tự nhận biết trong đề thi có gì. Nếu bạn đã thi, xin đừng gửi cho tôi câu hỏi trong đề: thỏa thuận chứng chỉ cấm chia sẻ chúng, và dù sao học thuộc đáp án cũng là cách sai để trở thành kiến trúc sư.
Hướng dẫn thi nói rằng kỳ thi không kiểm tra việc cấu hình công cụ tích hợp, và chương này là một đĩa nếm thử cho kiến trúc sư dữ liệu, không phải khóa học Integration Architect. Điều kỳ thi quan tâm là tích hợp làm gì với dữ liệu của bạn: khóa, thẩm quyền ghi, khối lượng và tính đầy đủ, và dữ liệu di chuyển giữa các org. Các con số của nền tảng thay đổi, nên hãy kiểm tra số hiện hành trước khi dựa vào chúng.
Cho kỳ thi
Phần tiêu đề “Cho kỳ thi ”Hãy đánh dấu khi bạn đi qua. Mỗi điểm liên kết đến nơi được giảng dạy.
Trước mũi tên (hỗ trợ LDV-1 và SDM-2)
- I zoom out to the landscape, then zoom in on one arrow and ask its data questions: initiator, direction, freshness, volume and shape, key, write authority, and who proves it arrived. (Zoom In on One Arrow) ⟲
- Tôi tách ai khởi tạo khỏi dữ liệu chảy theo hướng nào, và tôi biết chỉ có client thấy được trọn vòng đi về. (Ai bắt đầu không phải là dữ liệu đi theo hướng nào)
- I treat freshness as a requirement, not a default, and match the timing to the mechanism: a synchronous call when the caller waits, platform events for fire and forget, Change Data Capture to keep another system in step, the Bulk API for large scheduled loads. (How Current Does It Need to Be?) ⟲
- I know a database stores; a process calls: polling needs a process, often middleware, and polling for nothing is waste. Change Data Capture has a daily delivery allocation, counted per subscriber. (Asking Every Minute) ⟲
- I know Salesforce’s guidance for pulling changes on a schedule:
getUpdated()andgetDeleted()for intervals over 5 minutes; more often than that, let Salesforce send the change. (Asking Every Minute) ⟲ - I know the three traffic shapes, singles, sets and bulk; that more than 2,000 records is a good candidate for Bulk API 2.0, fewer for bulkified synchronous calls such as Composite; and to send only the fields that changed. (The Number of Zeros Applies to Integrations Too) ⟲
- I know integration volume becomes data volume: ownership, automation, sharing and storage. (Integration Volume Becomes Data Volume) ⟲
Khóa và thẩm quyền ghi (hỗ trợ SDM-2, SDM-4 và MDM-2)
- I carry an external system’s key in an External ID field marked Unique, one-to-one, and upsert on it: no match creates, one match updates, more than one fails. (One Record, One Key) ⟲
- When one customer has several external records, I add records, not fields (a hierarchy, peers or a child object), never a key field per ERP. (When the Customer Is in Two ERPs, chapter 6: One Customer, Two ERPs) ⟲
- I know one key field with the source in the value is still one key per record, and a new partner is a new value, not a new field. (Steve Trucking: One Field, the Source in the Value) ⟲
- Tôi biết khóa ổn định giúp thử lại an toàn (khởi đầu của tính lũy đẳng). (Khóa giúp thử lại an toàn)
- I know a key isn’t authority, and enforce write authority in the org: record types, read-only fields for users, and an integration user with only the access its contract needs. (A Key Isn’t Authority) ⟲
- I know two-way movement still has one owner per field, and how unclear authority causes loops. (Two-Way Movement, One Owner per Field) ⟲
- Tôi biết một ID bản ghi từ một org Salesforce không phải là khóa của doanh nghiệp ở một org khác: hai org là hai hệ thống. (Khóa cũng có vòng đời)
Proof of delivery (supports MIG-1 and MIG-2) ⟲
- I know the client owns the conversation, and whoever knows what should arrive proves that it did; the server keeps its own promises and reports what it received. (Who Proves It Arrived?) ⟲
- I know “no errors” isn’t completeness: reconcile counts and, where it matters, control totals. (“No Errors” Isn’t Completeness) ⟲
- I design for restart and safe retries, and log every call: request ID, endpoint, response code and duration. (Know Where You Are, and Restart Gracefully, Log Every Call, Retries Are Normal; Make Them Safe) ⟲
- I know platform events and Change Data Capture events stay on the bus for 72 hours, subscribers resume by Replay ID, duplicates can happen, and proof needs my own return receipt. (The Return Receipt) ⟲
- I know the soft landing for partial failure, and I send the increment, not the universe. (Partial Failure, and the Soft Landing, Send the Increment, Not the Universe) ⟲
- I know the four shapes: request and reply, fire and forget, batch and events, and where each recovers. (Four Shapes of Integration) ⟲
- I know outbound messaging is supported but gets no further investment, and since Spring ‘26 sends no session ID. (Outbound Messaging: Know It, Don’t Start There) ⟲
Hợp đồng dữ liệu tích hợp (hỗ trợ SDM-4)
- I can write an integration data contract for an arrow, eleven lines: initiator, direction, freshness, volume and shape, key, write authority, pattern, mechanism, proof of delivery, sensitivity and travel, and change. (An Arrow Needs More Than a Label) ⟲
- I go requirement, then pattern, then mechanism. (Requirements, Then Pattern, Then Mechanism) ⟲
- I know when to give another team a custom Apex REST endpoint instead of the standard APIs (one stable interface, my own logging and orchestration) and what it costs (code to maintain; API and Apex limits still apply). (A Contract Between Teams) ⟲
- I count every place the data rests on its way, logs and retry queues included, when it has to stay in a country. (Make Each Line Specific) ⟲
- For multiple orgs, I start with a contract per movement, and sometimes the contract says don’t move it (chapter 14). (Multiple Orgs, and “Don’t Move It”) ⟲
Where the rest lives. This chapter is about moving data. Not moving it (Salesforce Connect, mashups, data brought in on demand, zero copy: exam objective LDV-3) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). Loading and extracting at volume is chapter 10, Migration and Synchronization. ⟲
Ngoài kỳ thi
Phần tiêu đề “Ngoài kỳ thi ”Kỳ thi là sàn, không phải trần. Đây là những thói quen từ chương này mà một kiến trúc sư cần, dù có câu hỏi nào hỏi về chúng hay không.
- Zoom out, then zoom in. Start with the landscape; then take one arrow at a time. ⟲
- Hãy hiểu lưu lượng sắp đến, ngay cả khi người khác thiết kế tích hợp.
- Chọn cơ chế sau khi bạn hiểu sự di chuyển.
- A database stores; a process calls. Someone has to own the process. ⟲
- Di chuyển dữ liệu không miễn phí. Mỗi bản sao là thêm một nơi phải quản trị.
- Add records, not fields. ⟲
- Biết bản ghi. Biết chủ sở hữu. Rồi mới để tích hợp ghi.
- Whoever knows what should arrive proves that it did. ⟲
- Nếu nó có thể thất bại trong im lặng, nó chưa hoàn thành. Một tích hợp đã ngừng chạy là một vấn đề chất lượng dữ liệu.
- Quyền hạn nói “có thể”; kiến trúc nói “nên”.
- Decide the interface between teams in the first weeks: the standard API or a wrapper you own. ⟲
- Hợp đồng sống lâu hơn công nghệ.
- Hãy coi mọi hành động của tác tử là một tích hợp, với khóa, thẩm quyền, tính lũy đẳng và khả năng quan sát.
Thuật ngữ cần biết
Phần tiêu đề “Thuật ngữ cần biết ”| Thuật ngữ | Trong một dòng |
|---|---|
| Bên khởi tạo | Hệ thống bắt đầu cuộc trò chuyện (client) |
| Hướng dữ liệu | Dữ liệu nghiệp vụ di chuyển theo hướng nào, bất kể ai bắt đầu |
| Freshness | How current the data must be |
| Polling | Asking on a schedule whether anything changed |
| Từng bản ghi, theo tập, hàng loạt | Mỗi lần một bản ghi, các nhóm nhỏ, hoặc khối lượng lớn trong một tác vụ |
| External ID | Khóa của một hệ thống khác được lưu trên bản ghi Salesforce, dùng để khớp |
| Upsert | Cập nhật bản ghi khớp nếu nó tồn tại, tạo mới nếu không |
| Tính lũy đẳng | Lặp lại một thao tác mà không gây thêm tác động ngoài ý muốn |
| Dấu mốc / điểm kiểm soát | Ghi nhận một tích hợp đã đi an toàn được đến đâu |
| Đối chiếu | So sánh những gì dự định với những gì đã đến |
| Proof of delivery | Evidence, held by the side that knows what should arrive, that it did |
| Return receipt | An acknowledgment sent back to say a message was received and processed |
| Request and reply | The client sends and waits for the answer |
| Fire and forget | The client sends without waiting for the outcome |
| Sự kiện nền tảng | Một thông điệp được phát trên event bus của Salesforce cho các bên đăng ký |
| Change Data Capture | Các sự kiện Salesforce phát đi khi bản ghi thay đổi |
| Replay ID | Vị trí mà một bên đăng ký dùng để tiếp tục đọc sự kiện |
| Custom Apex REST | Your own REST endpoint in Salesforce, written in Apex, in front of your objects |
| Hợp đồng dữ liệu tích hợp | Một bản ghi ngắn về những gì một tích hợp được phép làm với dữ liệu |
Tự kiểm tra
Phần tiêu đề “Tự kiểm tra ”Những tình huống ngắn theo phong cách của khóa học. Hãy quyết định câu trả lời trước khi mở ra.
1. Salesforce gọi ERP để lấy tình trạng tín dụng của một khách hàng. Dữ liệu chảy theo hướng nào, và ai khởi tạo?
Salesforce khởi tạo; dữ liệu chảy ERP → Salesforce. Bên khởi tạo và hướng là hai câu hỏi riêng, và bên khởi tạo (client) là bên thấy được trọn vòng đi về. Đọc lại Ai bắt đầu không phải là dữ liệu đi theo hướng nào.
2. Đội đề xuất tạo một bản ghi Salesforce cho mỗi bản đọc GPS: 200.000 mỗi ngày. Bạn hỏi gì đầu tiên?
Vì sao lại đưa 73 triệu bản đọc mỗi năm vào mô hình giao dịch? Đó là một quyết định kiến trúc dữ liệu trước khi là một quyết định tích hợp; org có thể chỉ cần vị trí mới nhất. Đọc lại Khối lượng tích hợp trở thành khối lượng dữ liệu.
3. A warehouse team says, "Snowflake will just poll Salesforce every minute." What's missing?
⟲A database stores; a process calls. Something has to run the polling (usually an integration layer), with its own credentials, schedule and failures, and 1,440 calls a day mostly find nothing. Ask how current the data must be, then consider letting Salesforce send the changes (Change Data Capture), and count the events. Reread Asking Every Minute.
4. An external system needs Salesforce's changes about every hour, including deletions. What does Salesforce's own guidance suggest?
⟲For intervals over 5 minutes, the SOAP API’s getUpdated() and getDeleted() return what changed and what was deleted in a window, instead of a full extract. More often than that, let Salesforce send the change. Reread Asking Every Minute.
5. The ERP retries a "create customer" call after a timeout and Salesforce ends up with two accounts. How should it have been designed?
⟲Upsert on the ERP’s customer number in an External ID field marked unique, so a retry matches the existing record instead of inserting a duplicate. Reread Keys Make Retries Safe.
6. The customer exists in two ERPs, and someone proposes `NA_ERP_ID__c` and `EMEA_ERP_ID__c` on the Account. Your view?
⟲That’s a key field per ERP: an anti-pattern. It hides repeating structure in fields and turns every new ERP into a schema change. Add records, not fields: child accounts, peer accounts, or a child object per ERP record, each with one key. Reread When the Customer Is in Two ERPs.
7. The integration log shows zero errors, but finance totals don't match. What happened, and who should have caught it?
⟲Zero errors isn’t completeness: maybe fewer records were sent than intended, or values changed in transit. The side that knows what should have arrived proves it did: it reconciles counts and control totals against what it meant to send. Reread Who Proves It Arrived?.
8. A subscriber to platform events was down for a day. Can it catch up?
⟲Yes, within the 72-hour retention: it resumes from its last Replay ID. It must also handle duplicates, because the same event can arrive twice. Reread The Return Receipt.
9. The requirement says "we need a REST integration for credit holds." What's wrong with that?
⟲REST is a mechanism, not a requirement. The requirement is something like “agents see a credit hold within five minutes of the ERP change.” Start there, choose the pattern, then the mechanism, and write the contract. Reread Requirements, Then Pattern, Then Mechanism.
10. A partner's middleware team will send orders that touch four objects, and your data model changes every release. Standard API or custom Apex REST?
⟲It depends on the team. If they know Salesforce deeply and can change quickly, the standard APIs work. If not, a custom Apex REST endpoint gives them one stable interface, lets Salesforce orchestrate the four writes and log every call, and absorbs your changes inside. The cost is code you maintain, inside Salesforce’s API and Apex limits. Decide in the first weeks. Reread A Contract Between Teams.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Salesforce Certified Platform Data Architect Exam Guide (mở trong thẻ mới), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes (mở trong thẻ mới), Winter ‘27 (last updated September 18, 2026), checked 2026-11-01: the guide behind the exam’s Large Data Volumes section. Its integration rules are in module 1; its mashups are in chapter 14. ⟲
- Phần Tìm hiểu thêm của mỗi mô-đun liệt kê tài liệu Salesforce đứng sau các sự thật của nó, kèm ngày kiểm tra.