Một tích hợp Salesforce gần như không bao giờ hỏng vì giao thức. Xác thực là bài toán đã giải, ghi một bản ghi cũng vậy. Thứ kết liễu dự án là hạn mức yêu cầu mỗi ngày và hình dạng mô hình dữ liệu, cả hai thường lộ ra khoảng ba tuần sau khi lên sản xuất, khi tác vụ đêm bắt đầu trả lỗi và không ai giải thích nổi vì sao kiểm thử vẫn qua.

Khuôn mẫu lặp lại đủ đều để đoán trước. Lập trình viên viết trên tổ chức Developer Edition, mọi thứ đều qua, khách hàng nghiệm thu. Rồi đoạn mã gặp một tổ chức sản xuất đã sẵn có connector marketing, tác vụ trích xuất kho dữ liệu và một Apex trigger từ năm 2019, còn ngân sách tưởng rộng rãi hóa ra là nồi chung người khác đã tiêu.

Bài viết này đưa các bất ngờ lên trước: nên dùng API nào, hạn mức tính ra sao, chuyện gì xảy ra khi lệnh ghi của bạn kích hoạt đoạn mã bạn không viết, xác thực đã đổi thế nào, và những quyết định mô hình dữ liệu rất đắt để đảo ngược.

Điều gì quyết định một tích hợp Salesforce thành hay bại? Hạn mức và mô hình dữ liệu, không phải giao thức. Hạn mức yêu cầu API mỗi ngày thuộc về cả tổ chức và suy ra từ ấn bản cùng số giấy phép, nên một tích hợp ngoan ngoãn vẫn có thể bị một tích hợp tồi cùng tổ chức bỏ đói. Hãy thiết kế theo lô từ dòng mã đầu tiên, thống nhất ID ngoại và upsert trước khi ghi, và giả định mọi bản ghi gửi đi đều kích hoạt Apex của người khác.

Những điều một tích hợp Salesforce phải làm đúng

Có bốn điều, và chúng không nặng như nhau.

Thứ nhất là hạn mức. Mọi lệnh gọi đồng bộ mà mã của bạn thực hiện đều bị trừ vào một hạn mức duy nhất theo ngày của cả tổ chức, dùng chung với mọi bên tiêu thụ khác trong tổ chức đó.

Thứ hai là nền tảng bên dưới. Salesforce không phải một cơ sở dữ liệu có giao diện HTTP. Nó là một nền tảng ứng dụng, và lệnh ghi của bạn sẽ chạy các trigger, flow, quy tắc kiểm tra hợp lệ, quy tắc trùng lặp và trường tổng hợp do những quản trị viên chưa từng nghe về dự án của bạn cấu hình.

Thứ ba là mô hình dữ liệu. Lead, Contact, Account và Opportunity không thay thế được cho nhau, việc chuyển đổi giữa chúng là một chiều và có tác dụng phụ, chọn sai nghĩa là di trú dữ liệu chứ không phải sửa mã.

Thứ tư là danh tính: hệ thống của bạn và Salesforce thống nhất với nhau thế nào về việc bản ghi nào là bản ghi nào. Sai chỗ này, bản trùng sẽ sinh ra với tốc độ của máy. Mọi thứ còn lại ở đây đều bắt nguồn từ một trong bốn điều trên.

Bề mặt API, và cái bạn thực sự cần

Salesforce công bố một họ API rất lớn. Danh sách có thẩm quyền là chỉ mục API của Salesforce, và các tên dưới đây lấy từ đó chứ không lấy từ trí nhớ.

REST API và SOAP API

REST API là lựa chọn mặc định cho mọi việc có hình dạng bản ghi: tạo, đọc, cập nhật, xóa, truy vấn, describe. Nó đúng cho một biểu mẫu web ghi một Lead, cho một cổng thông tin đọc các case đang mở của khách hàng, và cho mọi đường tương tác lưu lượng thấp.

SOAP API làm cùng công việc đó qua WSDL và vẫn sống, vì rất nhiều middleware doanh nghiệp nói ngôn ngữ này một cách tự nhiên, và vì nó cho bạn một hợp đồng định kiểu chặt để sinh ra client. Điều người ta hay nhầm là cho rằng SOAP đã cũ còn REST mới. Cả hai đều đang hiện hành, và create() cùng update() của SOAP nhận tối đa 200 bản ghi mỗi lần, điều này quan trọng hơn định dạng truyền tải.

Bulk API 2.0

Bulk API 2.0 là đường bất đồng bộ theo tác vụ dành cho khối lượng lớn. Bạn tải lên một tệp CSV, Salesforce chia nhỏ và xử lý ở nền, còn bạn hỏi kết quả theo chu kỳ. Giới hạn của Bulk API do Salesforce công bố cho phép tối đa 15.000 lô trong 24 giờ trượt và tối đa 150 triệu bản ghi được nạp trong cùng khoảng đó, với trần tệp tác vụ là 150 MB.

Điều người ta hay nhầm là coi Bulk như một bước tinh chỉnh để dành lại sau. Nó là một mô hình lập trình khác: kết quả trở về bất đồng bộ, theo từng bản ghi, và mã của bạn phải tiêu thụ chúng theo cách đó ngay từ đầu.

Composite và sObject Collections

Hai thứ này là phần giá trị nhất và ít được dùng nhất của REST API. Một yêu cầu composite mang tối đa 25 yêu cầu con trong một lệnh gọi, trong đó tối đa 5 có thể là truy vấn hoặc thao tác sObject Collections, và các yêu cầu con phía sau có thể tham chiếu ID do yêu cầu con phía trước trả về. sObject Collections xử lý tối đa 200 bản ghi của cùng một đối tượng trong một yêu cầu. Cả hai chỉ tính là một lệnh gọi vào hạn mức hằng ngày, và đó chính là điểm mấu chốt.

Điều người ta hay nhầm là không biết chúng tồn tại. Tạo một Account, rồi một Contact, rồi một Opportunity bằng ba lệnh gọi tuần tự tốn gấp ba lần hạn mức của một yêu cầu composite, và gấp ba lần độ trễ.

Streaming, Change Data Capture và Pub/Sub

Streaming API là kênh đăng ký dựa trên CometD cho PushTopic, sự kiện chung, platform event và change event. Change Data Capture phát thông báo gần thời gian thực khi bản ghi được tạo, cập nhật, xóa hoặc khôi phục, để một kho bên ngoài theo kịp Salesforce mà không cần hỏi vòng. Platform Events là các định nghĩa sự kiện của riêng bạn.

Pub/Sub API là giao diện gRPC và HTTP/2 mới hơn, gom việc phát, đăng ký, lấy lược đồ và tìm chủ đề vào một API duy nhất, với nội dung theo Avro thay vì JSON. Nếu xây mới theo hướng sự kiện, hãy bắt đầu ở đó.

Điều người ta hay nhầm là coi sự kiện như một luồng được bảo đảm. Chúng không thay thế việc đối soát, vì lý do nằm ở phần sau.

Giới hạn yêu cầu API mới là ràng buộc thật

Đây là phần quyết định kiến trúc của bạn, và cũng là phần thường bị đọc sau khi thiết kế đã xong.

Hạn mức hằng ngày được tính thế nào

Tài liệu về giới hạn yêu cầu API của Salesforce đặt hạn mức theo ấn bản và số giấy phép, không theo người dùng và không theo ứng dụng. Ấn bản Enterprise và Professional có quyền truy cập API nhận 100.000 lệnh gọi cộng thêm 1.000 cho mỗi giấy phép Salesforce hoặc Salesforce Platform. Ấn bản Unlimited và Performance nhận 100.000 cộng thêm 5.000 cho mỗi giấy phép. Developer Edition nhận cố định 15.000, còn một sandbox Full nhận 5.000.000.

Hai điều theo sau. Một tổ chức Enterprise 60 người dùng có khoảng 160.000 lệnh gọi mỗi ngày, không phải một nguồn cung vô hạn. Và vì hạn mức suy ra từ giấy phép, cách duy nhất để nâng nó là mua thêm giấy phép người dùng hoặc mua thêm lệnh gọi API, cả hai đều qua ứng dụng Your Account của Salesforce.

Cái gì được tính, và chuyện gì xảy ra khi hết

Hạn mức được đo trên tổng mọi lệnh gọi tới tổ chức trong 24 giờ, gộp chung REST API, SOAP API, Bulk API, Bulk API 2.0 và phần lớn lệnh gọi Connect REST API. Lệnh gọi từ một số connected app của Salesforce, chẳng hạn ứng dụng di động, được loại trừ.

Chính phép gộp đó mới bẫy người. Tích hợp của bạn không có ngân sách riêng. Nó dùng chung một ngân sách với connector báo cáo, nền tảng marketing và mọi tích hợp khác trong tổ chức, và chỉ một bên tiêu thụ viết tồi hỏi vòng ba mươi giây một lần cũng đủ vét sạch nó, bỏ đói đoạn mã đang cư xử hoàn hảo.

Khi tổ chức vượt hạn mức, các yêu cầu hỏng với mã 403 và REQUEST_LIMIT_EXCEEDED. Salesforce cho các tổ chức sản xuất trả phí vượt một chút trước khi siết cứng, nhưng tổ chức dùng thử và Developer Edition không có ân hạn đó. Hãy thiết kế như thể không có ân hạn nào.

Đo trước khi chốt thiết kế

Hãy lấy hạn mức của tổ chức và mức tiêu thụ mỗi ngày hiện tại từ quản trị viên trước khi viết mã; REST API có sẵn một tài nguyên giới hạn tổ chức cho việc đó. Nếu các bên tiêu thụ hiện có đã dùng 70%, một tích hợp đồng bộ theo từng bản ghi là không khả thi, và tinh chỉnh cũng không cứu được.

Gộp lô là quyết định thiết kế, không phải tối ưu hóa

Một khi bạn chấp nhận hạn mức là hữu hạn và dùng chung, thiết kế tự nó lộ ra.

Đừng lặp một lệnh gọi đơn bản ghi. Một tác vụ tạo 5.000 Contact từng cái một tiêu 5.000 lệnh gọi. Cũng 5.000 đó qua sObject Collections với 200 bản ghi mỗi yêu cầu chỉ tiêu 25. Hệ số 200 lần ấy là ranh giới giữa một tích hợp lọt vào hạn mức của tổ chức cỡ vừa và một tích hợp không lọt.

Dùng Composite khi công việc là một đồ thị chứ không phải một danh sách. Tạo bản ghi cha cùng các bản ghi con trong một yêu cầu sẽ bỏ được cả các vòng đi về lẫn trạng thái trung gian mà mã của bạn phải giữ trong lúc chờ một ID.

Dùng Bulk API 2.0 cho mọi thứ giống nạp hoặc xuất hơn là giao dịch. Nó sai cho các đường tương tác, vì bản chất thiết kế là bất đồng bộ và không trả cho người dùng câu trả lời tức thì.

Hãy đệm dữ liệu tham chiếu. Giá trị danh sách chọn, ID kiểu bản ghi và kết quả describe hiếm khi đổi mà vẫn bị lấy lại mỗi lần chạy chẳng vì lý do gì. Riêng thay đổi đó thường cắt đi một phần tư lượng lệnh gọi của một tích hợp viết ngây thơ.

Giới hạn governor: lệnh ghi của bạn chạy mã của người khác

Salesforce chạy Apex do khách hàng viết bên trong các trần nghiêm ngặt tính theo giao dịch. Các giới hạn governor của Apex đáng kể với một tích hợp là 100 truy vấn SOQL cho mỗi giao dịch đồng bộ, 50.000 bản ghi do SOQL lấy về, 150 câu lệnh DML, 10.000 bản ghi do DML xử lý, 10 giây CPU đồng bộ và 6 MB heap.

Bạn không viết đoạn Apex đó. Bạn vẫn chạm các giới hạn ấy, vì lệnh ghi đi vào của bạn mở một giao dịch chạy bất kỳ trigger nào tồn tại trên đối tượng.

Gộp lô, mà không cần Apex

Ý tưởng này đáng hiểu ngay cả khi bạn không bao giờ mở một tệp Apex.

Salesforce trao cho trigger một tập hợp bản ghi, không phải một bản ghi. Một trigger viết đúng xử lý cả tập hợp bằng một truy vấn và một lệnh cập nhật. Một trigger viết như thể luôn nhận đúng một bản ghi sẽ chạy một truy vấn và một lệnh cập nhật cho mỗi bản ghi.

Trigger thứ hai chạy hoàn hảo suốt nhiều năm, vì người dùng lưu từng bản ghi một qua giao diện. Rồi tích hợp của bạn gửi 200 bản ghi trong một yêu cầu, trigger chạy truy vấn của nó 200 lần, vượt trần 100 truy vấn, và cả lô hỏng.

Bulk API 2.0 xử lý dữ liệu nạp theo khối 200 bản ghi, mỗi khối là một giao dịch riêng, nên đây không phải chuyện lý thuyết. Đó là hình dạng chuẩn của lần nạp hàng loạt đầu tiên vào một tổ chức đã có lịch sử.

Nên làm gì với chuyện đó

Hãy rà soát trigger và flow trên mọi đối tượng bạn sẽ ghi vào, trước khi bạn chốt ngày bàn giao. Nếu một trigger chưa gộp lô, ai đó phải sửa nó, và người đó cần kỹ năng Apex cùng một cửa sổ triển khai. Hãy tính nó thành một dòng ngân sách.

Nơi việc sửa nằm ngoài phạm vi, hãy giảm kích thước lô. Hai trăm bản ghi mỗi yêu cầu là mức tối đa chứ không phải yêu cầu bắt buộc, và hạ xuống 50 đôi khi mua đủ khoảng thở để phát hành trong lúc chờ xếp lịch sửa trigger. Nó tốn hạn mức, nên hãy coi là biện pháp tạm.

Xác thực còn dùng được sang năm

Khu vực này đã thay đổi đáng kể và nhiều hướng dẫn đang lưu hành giờ đã sai.

Luồng tên người dùng và mật khẩu của OAuth 2.0 là thứ cần tránh. Nó phơi thông tin đăng nhập ngay trong yêu cầu, Salesforce chặn nó theo mặc định ở các tổ chức mới hơn, và việc khai tử nó cho connected app đã được lên lịch. Mọi tích hợp còn dùng nó đều cần một kế hoạch chuyển đổi có kèm ngày.

Với công việc máy chủ tới máy chủ không có con người tham gia, hai câu trả lời hiện hành là luồng JWT bearer, ký một assertion bằng chứng chỉ, và luồng client credentials, đổi consumer key cùng secret lấy một token. Hướng dẫn của Salesforce về gọi REST API bằng integration user và client credentials nói rõ luồng này không cấp refresh token, nên client sẽ xin một access token mới khi token cũ hết hạn.

Connected app và external client app

Cái hộp chứa tất cả những thứ này trước đây là connected app. Bây giờ là external client app. Salesforce nói thẳng rằng việc tạo connected app bị hạn chế kể từ Spring ‘26 và khuyến nghị dùng external client app, mô tả chúng là thế hệ mới được thiết kế để tăng an toàn và giải quyết các vấn đề đóng gói.

Nếu tài liệu tích hợp của bạn viết “hãy tạo một connected app”, nó đang mô tả một con đường mà các tổ chức mới có thể không còn cung cấp. Hãy kiểm tra tổ chức đích thuộc trường hợp nào trước khi định phạm vi công việc.

Chạy bằng integration user riêng, và tính trước việc xoay vòng

Hãy cho tích hợp một người dùng riêng, với hồ sơ quyền tối thiểu và chỉ dùng API. Đừng chạy nó dưới danh nghĩa một nhân viên có tên. Khi nhân viên đó nghỉ việc và tài khoản bị vô hiệu hóa, tích hợp dừng, vào đúng thời điểm tệ nhất và kèm một lỗi chẳng chỉ tới đâu hữu ích.

Chứng chỉ hết hạn và secret bị xoay vòng. Cả hai đều im lặng cho tới đúng ngày đó, và cả hai đều làm tích hợp ngừng hoàn toàn chứ không phải một phần. Hãy đặt ngày hết hạn vào một lịch có người chịu trách nhiệm, cất thông tin đăng nhập trong một trình quản lý secret, và thử xoay vòng trong sandbox trước khi cần đến nó trong tình huống thật.

Những cái bẫy của mô hình dữ liệu

Đây là những cái bẫy tốn ba tuần, vì đảo ngược chúng nghĩa là chuyển dữ liệu chứ không phải sửa mã.

Lead, Contact, Account và Person Account

Lead là một khách hàng tiềm năng chưa thẩm định, chưa gắn với bản ghi công ty nào. Contact là một con người gắn vào một Account. Account là một tổ chức. Việc chuyển đổi biến một Lead thành một Account và một Contact, có thể kèm một Opportunity, và lệnh gọi convertLead của SOAP nói rõ chỉ những trường đang trống ở đích mới bị ghi đè, nên các trường Lead bạn điền công phu có thể không rơi vào chỗ bạn tưởng.

Person Account làm chuyện này rắc rối hơn. Các tổ chức bán cho người tiêu dùng bật nó lên để một cá nhân được biểu diễn như một Account và Contact hợp nhất, và một tích hợp viết theo mô hình Account doanh nghiệp sẽ không chạy nếu không sửa trên một tổ chức dùng nó. Điều này bị phát hiện muộn với một sự đều đặn đáng nản.

Hãy cùng bộ phận kinh doanh quyết định bằng văn bản rằng một bản ghi đi vào sẽ trở thành đối tượng nào. Đó không phải một quyết định kỹ thuật.

ID ngoại và upsert

Đây là cơ chế idempotent tỉnh táo duy nhất Salesforce cho bạn, và nó nên là điều không thương lượng. Hãy tạo trên đối tượng một trường tùy chỉnh đánh dấu là ID ngoại và lưu khóa chính của hệ thống bạn vào đó. Sau đó bạn có thể dùng thao tác upsert, một lệnh PATCH tới /sobjects/{Object}/{ExternalIdField}/{Value}, tạo bản ghi khi không có gì khớp và cập nhật khi khớp đúng một. Không khớp trả về 201, khớp một trả về 200, và khớp nhiều thì hỏng với 300 thay vì đoán mò.

Hệ quả đáng nói thẳng. Có upsert, thử lại một yêu cầu hỏng là an toàn. Không có nó, mọi lần thử lại đều là một bản trùng tiềm tàng, và một cú chớp mạng giữa tác vụ ban đêm biến thành công việc dọn dẹp tính bằng ngày.

Những quy tắc kích hoạt khi bạn ghi

Quy tắc trùng lặp có thể chặn hoặc cảnh báo trên các bản ghi tích hợp của bạn tạo ra. Quy tắc kiểm tra hợp lệ từ chối các bản ghi không thỏa điều kiện do một quản trị viên cấu hình. Trường bắt buộc có thể được thêm nhiều tháng sau khi bạn phát hành, và từ lúc đó một tích hợp đang chạy tốt bắt đầu hỏng trên mọi bản ghi.

Không cái nào là lỗi; đó là tổ chức hoạt động đúng như đã cấu hình. Sai lầm là coi một lệnh ghi bị từ chối như lỗi truyền tải rồi thử lại mãi mãi, trong khi phản ứng đúng là đưa nó tới một con người kèm lý do ở mức trường. Hướng dẫn của chúng tôi về chi phí và kiểu hỏng của tích hợp API bên thứ ba bàn cùng nhóm vấn đề ở nơi khác.

Xử lý lỗi, tính idempotent và phát lại

Một tích hợp không có cơ chế phát lại sẽ thành việc sửa dữ liệu bằng tay. Đó không phải dự đoán, đó là điều sẽ xảy ra.

Thành công một phần là trạng thái bình thường. sObject Collections đặt allOrNone mặc định là false, nên một yêu cầu 200 bản ghi có thể trả về 187 thành công và 13 thất bại kèm lý do riêng, và Bulk API 2.0 cũng trả kết quả theo từng bản ghi. Mã chỉ xem mã trạng thái HTTP bên ngoài sẽ báo thành công trong khi lặng lẽ đánh rơi bản ghi.

Hãy phân loại lỗi trước khi thử lại. Tình trạng nhất thời như khóa dòng, hết giờ và cạn hạn mức xứng đáng được lùi theo hàm mũ. Lỗi tất định như vi phạm quy tắc hợp lệ hay thiếu trường bắt buộc sẽ hỏng y hệt mãi mãi, và thử lại chỉ đốt hạn mức vốn đã không dư.

Mọi bản ghi không cứu được đều vào kho dead letter kèm nội dung và lỗi, để một con người xem và gửi lại. Vì lệnh ghi khóa theo ID ngoại, gửi lại là an toàn. Hãy ghi nhật ký ánh xạ giữa mã định danh của bạn và ID Salesforce ở cả hai phía; sáu tháng sau, đó là thứ duy nhất giải thích nổi vì sao bản ghi của một khách hàng bị sai.

Và hãy đối soát. Platform event và change event được giữ trong event bus 72 giờ, còn hạn mức platform event của Salesforce chặn mức phát mỗi ngày ở 25.000 sự kiện với Enterprise và 50.000 với Unlimited và Performance. Một tác vụ định kỳ so số bản ghi và ngày sửa đổi sẽ bắt được thứ luồng đánh rơi.

Middleware hay nối thẳng

Nối điểm tới điểm đúng nhiều hơn mức các hãng nền tảng chịu thừa nhận. Một nguồn, một đích, một chiều, khối lượng vừa phải, một hợp đồng ổn định: hãy dựng thẳng và bỏ qua giấy phép.

Middleware xứng với chi phí của nó khi hình trạng thôi là một đường thẳng. Nhiều hệ thống trao đổi dữ liệu, những phép biến đổi mà người dùng nghiệp vụ cần đổi mà không phải triển khai lại, việc điều phối qua các hệ thống hỏng độc lập với nhau, một nhu cầu thật sự về giám sát và thử lại tập trung.

Điều thành thật cần nói là middleware dịch chuyển chi phí chứ không xóa nó. Bạn vẫn trả cho việc ánh xạ, xử lý lỗi và tri thức vận hành, rồi cộng thêm một giấy phép, một đường ống thứ hai và một bộ kỹ năng thứ hai phải tuyển. Hạn mức API không đổi, vì middleware gọi đúng những API mà mã của bạn đã gọi.

Hãy chọn nó vì hình trạng của bạn cần nó, chứ không phải vì trông như nó giảm được mã. Hướng dẫn quyết định tự xây hay mua của chúng tôi phân tích cùng một đánh đổi cho các hệ thống nền, còn hướng dẫn tích hợp CRM và ERP bao quát trường hợp nhiều hệ thống. Nếu bạn muốn việc này được đánh giá thay vì tranh cãi, đó là nơi các hợp đồng phát triển phần mềm của chúng tôi bắt đầu.

Sandbox, triển khai và phiên bản API

Hãy dựng trong sandbox. Không bao giờ dựng thẳng trên sản xuất, và cũng không dựng trên một tổ chức Developer Edition không chia sẻ cấu hình sản xuất, vì chính cấu hình mới là thứ làm bạn vỡ.

Hãy hiểu việc làm mới có tác dụng gì. Nó thay sandbox bằng một bản sao mới từ sản xuất, nên mọi dữ liệu kiểm thử chỉ tồn tại ở đó sẽ mất. Bất cứ thứ gì phải sống sót qua một lần làm mới đều phải được viết thành kịch bản và chạy lại được. Các đội thường học điều này bằng cách mất một tuần dữ liệu kiểm thử.

Hãy ghim rõ phiên bản API trong mọi đường yêu cầu và nắm chính sách khai tử. Chính sách kết thúc vòng đời API của Salesforce cam kết hỗ trợ mỗi phiên bản tối thiểu ba năm và báo cho khách hàng ít nhất một năm trước khi ngừng hỗ trợ. Các phiên bản 21.0 tới 30.0 đã bị khai tử trong Summer ‘25, và yêu cầu gửi tới một phiên bản đã khai tử sẽ nhận 410 Gone.

Đó là một điểm dừng cứng chứ không phải suy giảm dần, và vì thế việc ghim phiên bản thuộc về kế hoạch bảo trì của bạn. Cùng kỷ luật đó áp cho bất kỳ API nào bạn tự công bố, như bài viết về quản lý phiên bản API của chúng tôi đã bàn.

Bảo vệ dữ liệu tại Anh và dữ liệu CRM

Một CRM gần như toàn bộ là dữ liệu cá nhân: tên, nơi làm việc, số điện thoại, địa chỉ email, ghi chú về các cuộc trò chuyện. Chuyển nó giữa các hệ thống là hành vi xử lý theo UK GDPR.

Câu hỏi đầu tiên là ai là bên kiểm soát. Hướng dẫn của ICO về bên kiểm soát và bên xử lý định nghĩa bên kiểm soát là bên quyết định mục đích và phương tiện xử lý, còn bên xử lý là bên xử lý thay mặt bên kiểm soát. Khi một agency xây và vận hành tích hợp cho bạn, agency đó thường là bên xử lý, và một hợp đồng bằng văn bản đáp ứng các yêu cầu của Điều 28 là bắt buộc chứ không phải tùy chọn.

Câu hỏi thứ hai là chuyển giao quốc tế. Tổ chức Salesforce và bất kỳ middleware nào cũng có thể nằm ngoài Anh, và hướng dẫn về chuyển giao quốc tế của ICO nêu các cơ chế sẵn có và khi nào cần đánh giá rủi ro chuyển giao. Hãy xác định dữ liệu rơi xuống đâu trước khi ký.

Ba hệ quả theo sau. Đừng sao chép những trường bạn không cần, vì tối thiểu hóa vừa là yêu cầu pháp lý vừa là bớt việc ánh xạ. Đừng đưa dữ liệu cá nhân của sản xuất vào sandbox nếu chưa cân nhắc kỹ. Và hãy bảo đảm việc xóa lan truyền, vì một liên hệ đã bị xóa trong Salesforce mà còn nguyên trong kho dữ liệu của bạn là một vấn đề tuân thủ đang sống, và điều đó cũng đúng khi tác nhân AI chạm tới những bản ghi ấy.

Một tích hợp Salesforce tốn bao nhiêu

Salesforce công bố giá ấn bản và giấy phép của họ trên các trang giá, và chúng tôi không trích con số nào ở đây, vì thứ chi phối thiết kế tích hợp là hạn mức API mà các giấy phép đó sinh ra, chứ không phải giá niêm yết.

Các con số dưới đây là ước tính dịch vụ chuyên môn tại Anh của chính Mecanik, không phải giá của hãng, và giả định một tổ chức đã tồn tại cùng một quản trị viên có thể trả lời câu hỏi.

Một tích hợp một chiều đơn giản, một biểu mẫu web tạo một Lead có ID ngoại kèm xử lý lỗi hợp lý, thường rơi vào GBP 3.000 đến GBP 7.000. Một đồng bộ hai chiều cho một hoặc hai đối tượng, kèm giải quyết xung đột và một tác vụ đối soát, thường là GBP 15.000 đến GBP 40.000. Một tích hợp hướng sự kiện trên Pub/Sub, có phát lại, xử lý dead letter và giám sát, nói chung nằm giữa GBP 30.000 và GBP 80.000.

Sản phẩm bàn giao nên có gì

Một tài liệu ánh xạ ở mức trường được thống nhất với bộ phận kinh doanh chứ không phải suy đoán. Một ID ngoại trên mọi đối tượng được đồng bộ. Xử lý lỗi với kho dead letter và quy trình gửi lại có ghi thành văn. Một tác vụ đối soát. Giám sát mức tiêu thụ API so với hạn mức của tổ chức, cảnh báo từ rất sớm trước trần. Sổ tay vận hành cho việc xoay vòng token, chứng chỉ hết hạn và phát lại. Cấu hình sandbox viết thành kịch bản để sống sót qua một lần làm mới. Một tích hợp thiếu những thứ đó là bản mẫu, dù hóa đơn viết gì đi nữa.

Chi phí thường xuyên

Hãy dự trù GBP 400 đến GBP 1.500 mỗi tháng cho giám sát, ba đợt phát hành Salesforce mỗi năm, xoay vòng thông tin đăng nhập và những thay đổi trường mà một quản trị viên sẽ làm mà không báo bạn. Các tổ chức chi cho khoản này là các tổ chức có tích hợp tiếp tục chạy.

Bắt tay vào xây

Các kiểu hỏng ở đây nhất quán đến mức nhàm: hạn mức bị phát hiện muộn, một trigger không ai rà soát, một Lead đáng lẽ phải là Contact, không có cách phát lại một lô hỏng. Cả bốn đều rẻ để phòng lúc thiết kế và đắt để sửa khi bản ghi thật đã tồn tại.

Mecanik xây và bảo trì các tích hợp Salesforce như một phần công việc phát triển phần mềm của chúng tôi, bắt đầu bằng việc rà soát hạn mức, trigger và mô hình dữ liệu của tổ chức trước khi viết dòng mã nào. Với một phần việc tích hợp có phạm vi xác định thay vì một hợp đồng đầy đủ, bạn có thể thuê lập trình viên web trực tiếp.

Câu hỏi thường gặp

Một tích hợp Salesforce được bao nhiêu lệnh gọi API mỗi ngày? Điều đó phụ thuộc vào ấn bản và số giấy phép, và hạn mức là của cả tổ chức chứ không phải của từng tích hợp. Ấn bản Enterprise và Professional có quyền truy cập API nhận 100.000 lệnh gọi cộng 1.000 cho mỗi giấy phép Salesforce hoặc Salesforce Platform, Unlimited và Performance nhận 100.000 cộng 5.000 cho mỗi giấy phép, còn Developer Edition nhận cố định 15.000 trong 24 giờ trượt.

Nên dùng REST API hay Bulk API cho Salesforce? Dùng REST API cho việc tương tác, khối lượng thấp, có hình dạng bản ghi, và Bulk API 2.0 cho việc nạp và xuất khi khối lượng lớn và câu trả lời bất đồng bộ là chấp nhận được. Với mọi thứ ở giữa, sObject Collections với 200 bản ghi mỗi yêu cầu và Composite với 25 yêu cầu con mỗi yêu cầu đều chỉ tính là một lệnh gọi vào hạn mức và gỡ được phần lớn áp lực.

Tích hợp Salesforce máy chủ tới máy chủ nên dùng luồng OAuth nào? Luồng JWT bearer hoặc luồng client credentials, chạy dưới một integration user riêng chỉ dùng API. Luồng tên người dùng và mật khẩu bị chặn mặc định ở các tổ chức mới hơn và đã được lên lịch khai tử, nên không nên dùng cho việc mới. Cũng lưu ý rằng việc tạo connected app bị hạn chế kể từ Spring ‘26 và Salesforce nay khuyến nghị external client app.

Vì sao tích hợp Salesforce của tôi chỉ hỏng với các lô lớn? Gần như luôn là một Apex trigger chưa được gộp lô. Salesforce trao cho trigger một tập hợp bản ghi, và một trigger viết như thể mỗi lần chỉ nhận một bản ghi sẽ chạy truy vấn của nó một lần cho mỗi bản ghi, vượt giới hạn 100 truy vấn SOQL khi lô của bạn đến. Nó chạy tốt với người dùng giao diện lưu từng bản ghi một, và đó là lý do nó sống sót mà không bị phát hiện.

Tôi có cần middleware để tích hợp với Salesforce không? Không cần cho một tích hợp một nguồn, một đích, một chiều với khối lượng vừa phải, ở đó dựng thẳng vừa rẻ hơn vừa đơn giản hơn. Middleware xứng với chi phí khi nhiều hệ thống trao đổi dữ liệu, khi người dùng nghiệp vụ cần đổi ánh xạ mà không phải triển khai, hoặc khi bạn cần điều phối và thử lại tập trung. Nó dịch chuyển chi phí chứ không xóa, và nó không làm tăng hạn mức API của bạn.