Webhook là lệnh gọi lại HTTPS do đối tác tạo, chỉ định cách nhân viên hỗ trợ của bạn phản hồi thông báo và sự kiện. Sau khi định cấu hình webhook, bạn có thể bắt đầu nhận tin nhắn và sự kiện.
Webhook của đối tác và webhook của nhân viên hỗ trợ
Bạn có thể định cấu hình webhook ở cấp đối tác hoặc cấp nhân viên hỗ trợ.
- Webhook của đối tác áp dụng cho mọi nhân viên hỗ trợ mà bạn duy trì. Nếu nhân viên hỗ trợ của bạn có hành vi tương tự hoặc nếu bạn chỉ có một nhân viên hỗ trợ, hãy sử dụng webhook của đối tác.
- Webhook của nhân viên hỗ trợ áp dụng cho từng nhân viên hỗ trợ. Nếu điều hành nhiều nhân viên hỗ trợ có hành vi riêng biệt, bạn có thể đặt một webhook khác nhau cho từng nhân viên hỗ trợ.
Nếu bạn đã định cấu hình cả webhook của đối tác và webhook của nhân viên hỗ trợ, thì webhook của nhân viên hỗ trợ sẽ được ưu tiên so với webhook cụ thể, còn webhook của đối tác sẽ áp dụng cho mọi nhân viên hỗ trợ không có webhook riêng.
Định cấu hình webhook cho nhân viên hỗ trợ
Bạn nhận được tin nhắn được gửi đến nhân viên hỗ trợ của mình tại webhook của đối tác. Nếu bạn muốn tin nhắn cho một nhân viên hỗ trợ cụ thể đến một webhook khác, hãy đặt webhook cho nhân viên hỗ trợ.
- Mở Business Communications Developer Console và đăng nhập bằng Tài khoản Google của đối tác RBM.
- Nhấp vào nhân viên hỗ trợ của bạn.
- Nhấp vào Integrations (Tích hợp).
- Đối với Webhook, hãy nhấp vào Định cấu hình.
- Đối với URL điểm cuối webhook, hãy nhập URL webhook bắt đầu bằng "https://".
- Ghi lại giá trị
clientToken
. Bạn cần mã này để xác minh rằng thư bạn nhận được là của Google. Hãy định cấu hình webhook của bạn để chấp nhận yêu cầu
POST
bằng thông sốclientToken
được chỉ định và gửi một phản hồi200 OK
với giá trị văn bản thuần tuý của thông sốsecret
làm nội dung phản hồi.Ví dụ: nếu webhook của bạn nhận được yêu cầu
POST
có nội dung phần thân sau đây{ "clientToken":"SJENCPGJESMGUFPY", "secret":"1234567890" }
thì webhook của bạn sẽ xác nhận giá trị
clientToken
và nếuclientToken
chính xác, hãy trả về phản hồi200 OK
với1234567890
làm nội dung phản hồi:// clientToken from Configure const myClientToken = "SJENCPGJESMGUFPY"; // Example endpoint app.post("/rbm-webhook", (req, res) => { const msg = req.body; if (msg.clientToken === myClientToken) { res.status(200).send(msg.secret); return; } res.send(400); });
Trong Developer Console, hãy nhấp vào Xác minh. Khi RBM xác minh webhook của bạn, hộp thoại sẽ đóng lại.
Xác minh tin nhắn đến
Vì webhook có thể nhận tin nhắn từ bất kỳ người gửi nào, nên bạn nên xác minh rằng Google đã gửi tin nhắn đến trước khi xử lý nội dung tin nhắn.
Để xác minh rằng Google đã gửi một thông báo mà bạn nhận được, hãy làm theo các bước sau:
- Trích xuất tiêu đề
X-Goog-Signature
của thư. Đây là bản sao được băm, mã hoá base64 của tải trọng nội dung thư. - Giải mã tải trọng RBM bằng Base-64 trong phần tử
message.body
của yêu cầu. - Sử dụng mã thông báo máy khách của webhook (mà bạn chỉ định khi thiết lập webhook) làm khoá, tạo một HMAC SHA512 cho các byte của tải trọng thông báo được giải mã base-64 và mã hoá base64.
- So sánh hàm băm
X-Goog-Signature
với hàm băm mà bạn đã tạo.- Nếu các hàm băm khớp nhau, tức là bạn đã xác nhận rằng Google đã gửi tin nhắn.
Nếu các hàm băm không khớp, hãy kiểm tra quy trình băm trên một thông báo đã biết là tốt.
Nếu quy trình băm của bạn đang hoạt động đúng cách và bạn nhận được một thông báo mà bạn cho rằng đã được gửi cho bạn một cách gian lận, hãy liên hệ với chúng tôi.
Node.js
if ((requestBody.hasOwnProperty('message')) && (requestBody.message.hasOwnProperty('data'))) { // Validate the received hash to ensure the message came from Google RBM let userEventString = Buffer.from(requestBody.message.data, 'base64'); let hmac = crypto.createHmac('sha512', CLIENT_TOKEN); let data = hmac.update(userEventString); let genHash = data.digest('base64'); let headerHash = req.header('X-Goog-Signature'); if (headerHash === genHash) { let userEvent = JSON.parse(userEventString); console.log('userEventString: ' + userEventString); handleMessage(userEvent); } else { console.log('hash mismatch - ignoring message'); } } res.sendStatus(200);
Xử lý thông báo
Việc trả về bất kỳ giá trị nào khác ngoài 200 OK
từ một webhook sẽ được coi là lỗi phân phối.
Nhà phát triển phải lưu ý rằng việc gửi thông báo với tần suất cao sẽ tạo ra thông báo webhook với tần suất cao và phải thiết kế mã để đảm bảo họ có thể sử dụng thông báo với tần suất dự kiến. Điều quan trọng là nhà phát triển phải xem xét các tình huống có thể gây ra phản hồi lỗi, bao gồm cả phản hồi 500
từ vùng chứa web, hết thời gian chờ hoặc lỗi ngược dòng. Sau đây là một số điều cần cân nhắc:
- Đảm bảo bạn định cấu hình các biện pháp bảo vệ chống DDoS để xử lý tỷ lệ thông báo webhook dự kiến.
- Đảm bảo các tài nguyên như nhóm kết nối cơ sở dữ liệu không bị hết và tạo ra thời gian chờ hoặc phản hồi
500
.
Hành vi khi không phân phối được
RBM sử dụng cơ chế thời gian đợi và thử lại khi nhận được phản hồi khác với 200 OK
từ lệnh gọi webhook. RBM sẽ tăng thời gian chờ giữa các lần thử lại lên tối đa 600 giây. Hệ thống sẽ tiếp tục thử lại trong 7 ngày, sau đó sẽ loại bỏ thông báo.
Ý nghĩa của webhook ở cấp nhân viên hỗ trợ
RBM xếp hàng đợi thông báo cho một đối tác trên một hàng đợi. Khi đối tác đang sử dụng webhook cấp tác nhân, điều quan trọng là phải lưu ý rằng lỗi của một webhook sẽ ảnh hưởng đến việc phân phối đến các webhook khác. Webhook thuộc về các tác nhân khác sẽ được gọi trong thời gian đợi của một thông báo không thành công. Tuy nhiên, khi các thư không thành công được đưa vào hàng đợi để thử lại, tỷ lệ phân phối tổng thể sẽ giảm và các tác nhân khác sẽ bị ảnh hưởng.
Điều quan trọng là nhà phát triển phải hiểu rõ mô hình và mã này sao cho phù hợp, nhất có thể, chấp nhận thông báo và đưa chúng vào hàng đợi xử lý nhằm giảm thiểu khả năng trả về lỗi.
Các bước tiếp theo
Sau khi bạn định cấu hình webhook, nhân viên hỗ trợ có thể nhận tin nhắn từ thiết bị thử nghiệm. Gửi tin nhắn để xác thực chế độ thiết lập.