Trước khi duyệt kết nối giữa các hệ thống đơn hàng, kho hoặc kế toán, hãy hỏi điều gì xảy ra khi cùng một bản cập nhật đến hai lần. Có thể cần gửi lại dữ liệu dù hóa đơn, yêu cầu giao hàng hoặc tin nhắn cho khách đã tồn tại.
Mất phản hồi khiến kết quả chưa rõ
Hãy hình dung một hệ thống gửi bản cập nhật và hệ thống nhận đã xử lý xong. Phản hồi xác nhận thành công bị thất lạc trên đường quay lại. Hệ thống gửi chờ đến hết thời hạn rồi thử lại.
Hết thời hạn giải thích vì sao dữ liệu được gửi lại. Điều đó không cho biết lần đầu đã hoàn tất hay chưa. Tắt việc thử lại có thể khiến công việc dang dở; lặp lại mọi thao tác kinh doanh có thể tạo thêm việc.
Malcolm Featonby mô tả sự không chắc chắn này trong bài viết của Amazon Builders’ Library về cách làm cho việc thử lại an toàn. Stripe và Shopify cũng ghi lại việc webhook được gửi lặp lại. Webhook là bản cập nhật tự động được gửi từ hệ thống này sang hệ thống khác. Bạn nên trao đổi về tình huống này trước khi đưa kết nối vào sử dụng.
Thao tác nào chỉ nên diễn ra một lần?
Hãy lấy ví dụ một cửa hàng cần tạo một yêu cầu xử lý đơn khi nhận cập nhật đơn đã thanh toán. Ba tình huống sau cần cách xử lý khác nhau:
Cùng một bản cập nhật đến lần nữa
Yêu cầu xử lý đơn có thể đã tồn tại. Lần gửi tiếp theo không nên tạo thêm yêu cầu cho cùng thao tác dự kiến, trong giới hạn đã thống nhất.
Bản cập nhật khác liên quan đến đơn hàng đó
Thay đổi địa chỉ hoặc hủy đơn có thể cần xử lý khác. Cùng số đơn hàng không có nghĩa mọi bản cập nhật đều bị trùng.
Khách đặt đơn hàng thứ hai
Đơn hàng mới vẫn phải được xử lý, ngay cả khi khách hàng, mặt hàng và tổng tiền giống hệt. Thông tin tương tự không chứng minh đây là đơn gửi lặp.
Hãy hỏi nhà cung cấp cách xác định thao tác dự kiến và cách giữ nguyên định danh đó khi gửi lại. Bạn không cần chọn cơ chế kỹ thuật, nhưng cần hiểu vì sao cơ chế nhận ra dữ liệu lặp mà vẫn cho phép công việc mới thực sự.
Chi tiết tùy từng nhà cung cấp. Tài liệu Stripe nói về sự kiện lặp và các sự kiện riêng biệt liên quan đến cùng một đối tượng. Shopify phân biệt một lần gửi với thao tác kinh doanh phía sau. Định danh hữu ích cho mục đích này chưa chắc phù hợp với mọi thao tác kinh doanh.
Bạn có thể xem ví dụ liên quan trong tài liệu webhook của Stripe và hướng dẫn xác minh lần gửi của Shopify. Nhà cung cấp cần kiểm tra cách hoạt động hiện tại của các hệ thống bạn định kết nối.
Tìm hiểu điều gì xảy ra khi chỉ một phần công việc hoàn tất
Giả sử yêu cầu xử lý đơn đã được tạo, nhưng kết nối dừng trước khi ghi nhận hoàn tất. Ở lần thử tiếp theo, hệ thống tìm yêu cầu hiện có bằng cách nào? Điều gì xảy ra nếu hai bản sao đến cùng lúc? Chỉ riêng danh sách bản cập nhật đã nhận không trả lời được các câu hỏi này.
Hãy yêu cầu xem riêng ba điều: bằng chứng bản cập nhật đã đến, trạng thái xử lý của kết nối và bằng chứng về thao tác đã thực hiện trong hệ thống nhận. Chỉ có xác nhận đã nhận dữ liệu thì chưa đủ để chứng minh yêu cầu giao hàng hoặc hóa đơn đã tồn tại.
Nếu kết quả vẫn chưa rõ, hãy thống nhất ai sẽ điều tra và cần kiểm tra những gì trước khi cho phép thử lại. Đặt ra giới hạn rõ ràng cho nhân viên: thao tác nào họ có thể tiếp tục, trường hợp nào cần nhà cung cấp hỗ trợ, và khi nào cần dừng để tránh tạo thêm thao tác kinh doanh. Một số vấn đề cần đối chiếu hồ sơ giữa các hệ thống và cần người quyết định bước tiếp theo.
“Thử lại” chỉ hữu ích khi bạn biết lần thử tiếp theo được phép làm gì và ai sẽ tiếp nhận khi kết quả chưa rõ.
Yêu cầu minh họa an toàn
“Thử lại” chỉ hữu ích khi bạn biết lần thử tiếp theo được phép làm gì và ai sẽ tiếp nhận khi kết quả chưa rõ.
Hãy dùng môi trường thử nghiệm được hỗ trợ, với dữ liệu giả và các thao tác kinh doanh bên ngoài đã bị vô hiệu hóa. Phần minh họa cần bao gồm cùng một bản cập nhật được gửi hai lần, một đơn hàng thứ hai thực sự và lỗi xảy ra sau khi một bước đã hoàn tất. Hãy kiểm tra hồ sơ kết quả cùng nhật ký gửi dữ liệu. Tuyệt đối không gửi lại khoản thanh toán hoặc đơn hàng thật chỉ để xem điều gì xảy ra.
Hãy yêu cầu bản mô tả ngắn bằng văn bản về điều kiện kích hoạt, thao tác dự kiến, cách nhận diện dữ liệu lặp và nơi nhân viên xem được kết quả. Cần nêu rõ kết nối lưu dấu vết công việc trước đó trong bao lâu, cách xử lý dữ liệu đến muộn, và ai phụ trách thao tác chưa rõ kết quả hoặc mới hoàn tất một phần.
Nếu các hệ thống không hỗ trợ minh họa an toàn cho một lỗi cụ thể, hãy ghi nhận khoảng trống đó và thống nhất với nhà cung cấp một phạm vi rà soát hẹp hơn. Một thử nghiệm thành công chỉ xác nhận hành vi trong các điều kiện đó. Nó không đảm bảo mọi dịch vụ được kết nối chỉ thực hiện thao tác đúng một lần, cũng không chứng minh toàn bộ chuỗi sẽ hoàn tất như một giao dịch không thể chia nhỏ.
Câu hỏi trước khi duyệt kết nối
Hết thời hạn có nghĩa lần thử đầu tiên thất bại không?
Không. Công việc có thể đã hoàn tất nhưng phản hồi bị thất lạc. Hãy kiểm tra kết quả xử lý và hệ thống nhận trước khi quyết định lần thử tiếp theo sẽ làm gì.
Hai đơn hàng trông giống nhau có thể đều hợp lệ không?
Có. Khách hàng có thể chủ ý đặt đơn thứ hai với cùng mặt hàng và tổng tiền. Kết nối cần phân biệt ý định mới với dữ liệu được gửi lặp; chỉ dựa vào thông tin giống nhau thì chưa thể kết luận.
Làm sao kiểm tra an toàn cách xử lý bản gửi lặp?
Hãy yêu cầu môi trường thử nghiệm được hỗ trợ, dùng dữ liệu giả và đã vô hiệu hóa các thao tác kinh doanh bên ngoài. Thử gửi lặp, tạo một thao tác mới thực sự và mô phỏng lỗi sau khi một phần công việc đã hoàn tất. Ghi lại mọi giới hạn của thử nghiệm thay vì thử trên đơn hàng hoặc thanh toán thật.
Ai nên xử lý thao tác mới hoàn thành một phần?
Hãy thống nhất trước một người hoặc nhóm chịu trách nhiệm. Nhân viên cần biết họ có thể tự kiểm tra hoặc tiếp tục việc gì, và khi nào nhà cung cấp phải điều tra trước khi cho phép thao tác tiếp theo.
