WooCommerce HPOS thay đổi nơi lưu dữ liệu đơn hàng. Vì vậy, một tích hợp từng đọc được đơn từ bảng bài viết có thể vẫn chạy mà lấy nhầm bản dữ liệu. Với cửa hàng đang nối phần mềm giao nhận, CRM hoặc báo cáo nội bộ, câu hỏi cần giải quyết là: đường đọc và đường ghi của từng tích hợp có làm việc với nguồn đơn hàng hiện hành không?
Bài viết hướng dẫn cách chuẩn bị một cuộc kiểm tra có phạm vi cho đội vận hành và phát triển. Các tình huống, mã đơn và nhãn xử lý bên dưới là ví dụ biên tập, không phải dữ liệu cửa hàng hay kết quả triển khai của Onter. Việc thay đổi chế độ lưu trữ cần một kế hoạch riêng; đừng thử bật tắt trên website đang nhận đơn chỉ để kiểm tra một giả thuyết.
WooCommerce HPOS: xác định nguồn đơn hàng đang được sử dụng
Tài liệu HPOS của WooCommerce phân biệt hai vai trò: bảng dữ liệu có thẩm quyền và bảng nhận bản sao. Hoạt động bình thường đọc, ghi ở nguồn có thẩm quyền; đồng bộ chuyển thay đổi sang nguồn còn lại. Khi vẫn có đơn chờ đồng bộ, hệ thống không cho đổi vai trò hai nguồn. Đây là cơ chế sản phẩm, không phải bằng chứng một cửa hàng cụ thể đã đồng bộ xong.
Vì thế, nhìn thấy một dòng trong database chưa trả lời đủ câu hỏi. Người kiểm tra còn cần biết dòng đó thuộc nguồn nào và được cập nhật đến thời điểm nào. Một màn hình báo cáo đọc bảng cũ có thể trông hợp lý vì phần lớn đơn trước đây vẫn còn ở đó. Sai lệch chỉ lộ ra với đơn mới hoặc với trường vừa được sửa.
Hãy yêu cầu đội phụ trách ghi nhận cấu hình hiện hành bằng cơ chế quản trị được hỗ trợ, phiên bản WooCommerce và danh sách tích hợp liên quan. Không cần xuất toàn bộ database hay thông tin khách hàng. Một bản mô tả tối thiểu nên cho biết hệ nào sở hữu đơn, tích hợp nào chỉ đọc và tích hợp nào được phép ghi trường cụ thể.
Cũng cần phân biệt sự cố lưu trữ với lỗi nghiệp vụ. Một đơn hiện trạng thái chờ xử lý chưa chắc là lỗi HPOS. Thanh toán có thể đang chờ xác nhận, webhook có thể chậm hoặc báo cáo đang lọc sai khoảng ngày. Chỉ thay đổi lớp lưu trữ sau khi có bằng chứng đường truy cập đó là nguyên nhân, không dựa vào thời điểm lỗi xuất hiện gần một lần cập nhật plugin.
Một tình huống nhỏ để tìm đường đọc sai
Giả sử cửa hàng có một trường nội bộ tên “nhóm đóng gói”. Nhân viên cập nhật đơn thử nghiệm X từ nhóm thường sang nhóm cần kiểm tra. Sau đó, màn hình đơn hiển thị giá trị mới, còn danh sách giao việc vẫn hiện giá trị cũ. Ví dụ không khẳng định đây là cách một plugin có sẵn hoạt động; nó giúp xác định cần quan sát những gì.
Đội kỹ thuật nên ghi lại cùng ID đơn, cùng trường và thời điểm đọc ở từng đầu. Nếu chọn hai đơn khác nhau vì mã hiển thị giống nhau, mọi so sánh tiếp theo đều mất ý nghĩa. Nếu một đầu còn dùng dữ liệu lấy trước khi sửa, hãy làm rõ thời điểm đó trước khi quy kết lỗi đồng bộ.
| Điểm quan sát | Giá trị thấy | Câu hỏi tiếp theo |
|---|---|---|
| Màn hình đơn hiện hành | Cần kiểm tra | Đúng ID và trường cần so chưa? |
| Danh sách giao việc | Thường | Đọc qua API nào, từ lần lấy nào? |
| Đường đọc mới qua đối tượng đơn | Chưa kiểm chứng | Có trả giá trị vừa lưu không? |
Dòng cuối cố ý để chưa kiểm chứng. Điền sẵn kết quả mong muốn sẽ biến một kế hoạch thử thành bằng chứng giả. Chỉ sau khi thực hiện trên môi trường phù hợp mới có thể xác định đường đọc mới giải quyết được lỗi hay không.
Nếu báo cáo lấy đúng giá trị nhưng danh sách giao việc vẫn sai, phạm vi điều tra chuyển sang bước biến đổi hoặc dữ liệu lưu đệm của danh sách. Nếu cả hai đều sai theo cùng một nguồn, tiếp tục xem hợp đồng trường và cách ghi. Mỗi lần thay giả thuyết cần giữ ghi chú quan sát, để người tiếp theo không lặp lại một vòng sửa thiếu căn cứ.
Cách kiểm tra này khác với đối soát chuyển dữ liệu. Đối soát xem tập dữ liệu sau chuyển đổi có đủ khóa, đúng trường và liên kết hay không. Ở đây, trọng tâm là một tích hợp đang vận hành có đi qua đúng cơ chế truy cập đơn hàng, kể cả khi hai nơi lưu cùng tồn tại.
Rà theo thao tác đọc, ghi và tìm đơn
Hướng dẫn tương thích extension với HPOS cảnh báo truy cập trực tiếp bảng posts/postmeta có thể đọc bản cũ hoặc ghi vào nơi không được sử dụng. Tài liệu chỉ ra cách lấy đối tượng đơn bằng wc_get_order, thao tác metadata qua đối tượng rồi lưu bằng cơ chế WooCommerce. Một khai báo tương thích của plugin cần đi sau việc rà soát mã; bản thân dòng khai báo không chứng minh mọi luồng đã chạy đúng.
Trong một dự án thực tế, danh sách rà soát nên bắt đầu từ công việc của nhân viên: xem đơn mới, cập nhật ghi chú giao nhận, gắn mã hệ thống ngoài, lọc đơn cần xử lý. Từ từng công việc mới lần ra plugin, đoạn tùy chỉnh hoặc tác vụ nền thực hiện nó. Cách này giúp tìm cả phần tích hợp ít xuất hiện trên giao diện nhưng vẫn ghi dữ liệu mỗi ngày.
Với đường đọc, cần xác định trường trả về và kiểu dữ liệu mà bên nhận thực sự dùng. Với đường ghi, cần xác định bên nào sở hữu trường, lúc nào được phép sửa và sau lưu phải đọc lại gì. Không nhân tiện thay trạng thái thanh toán, số tiền hoặc thông tin giao hàng chỉ vì đang sửa một trường vận hành khác.
Phần tìm danh sách đơn cũng cần được kiểm riêng. Tài liệu truy vấn đơn HPOS mô tả các đối số tìm theo metadata, thuộc tính đơn và ngày qua wc_get_orders(). Điều đó không có nghĩa một truy vấn SQL cũ được thay bằng một câu gọi bất kỳ là xong. Bộ lọc, loại ngày, quan hệ AND/OR và tập ID trả về phải đúng với yêu cầu nghiệp vụ đã chốt.
Chẳng hạn, yêu cầu “đơn đã thanh toán hôm nay” khác với “đơn được tạo hôm nay”. Một tích hợp đọc đúng kho dữ liệu vẫn có thể chọn sai tập đơn nếu dùng nhầm điều kiện ngày. Khi nghiệm thu, hãy đưa một đơn tạo hôm trước nhưng thanh toán hôm nay vào tập thử để làm rõ khác biệt, bằng dữ liệu giả lập hoặc dữ liệu đã được cho phép sử dụng.
Đừng sửa hàng loạt mọi chỗ có hàm truy cập bài viết. Website vẫn có bài blog, trang nội dung và nhiều đối tượng hợp lệ khác. Chỉ những đường làm việc với dữ liệu đơn hàng mới thuộc phạm vi kiểm tra HPOS này. Các trường hợp khôi phục nội dung và dữ liệu plugin có hợp đồng lịch sử riêng, không được gộp vào thay đổi kho đơn.
Nghiệm thu mà không tạo thêm tác động lên cửa hàng
Trước khi chạy thử, thống nhất môi trường, quyền thao tác và cách ngăn thông báo thật. Đơn mẫu không nên khiến kho đóng hàng, gửi email cho khách hay gọi cổng thanh toán thật. Nếu môi trường kiểm thử vẫn nối dịch vụ ngoài, đội phụ trách phải xác minh cơ chế cô lập trước; tên miền có chữ “test” không đủ bảo đảm.
Chọn một số trường hợp đại diện cho đúng tính năng đang sửa. Ví dụ gồm đọc đơn vừa tạo, đọc sau khi sửa trường nội bộ, tìm đơn theo bộ lọc đã chốt và xử lý ID không tồn tại. Với lỗi đọc hoặc ghi, mong đợi là thông báo rõ để người phụ trách biết thao tác chưa hoàn tất, thay vì tạo một đơn thay thế hoặc điền giá trị mặc định khiến công việc bị giao sai.
Mỗi kết quả nên gắn phiên bản tích hợp, cấu hình lưu trữ và phạm vi dữ liệu đã thử. Một lần đạt trên môi trường dùng bảng posts không đủ để xác nhận cấu hình HPOS; ngược lại, đạt ở HPOS không tự chứng minh mọi extension khác tương thích. Nếu cần hỗ trợ cả hai chế độ, kế hoạch thử phải thể hiện hai cấu hình được hỗ trợ thay vì suy rộng từ một lần chạy.
Sau thử nghiệm, người vận hành cần nhìn thấy cùng ý nghĩa ở màn hình đơn và nơi nhận tích hợp. Có thể so một tập ID nhỏ, trường được phép sửa và kết quả lọc. Không cần sao chép dữ liệu cá nhân vào báo cáo kỹ thuật; tham chiếu có quyền truy cập cùng trạng thái đối chiếu thường hữu ích hơn một file xuất đầy đủ gửi qua nhiều kênh.
Phương án quay lui cũng phải đúng phạm vi. Hoàn tác mã tích hợp không tự hoàn tác mọi tác động đã gửi sang hệ thống khác. Cần ghi rõ thao tác nào chỉ đọc, thao tác nào đã ghi và thay đổi nào cần người phụ trách xử lý. Không dùng việc đổi ngược kho lưu trữ làm nút chữa chung khi chưa xác nhận điều kiện đồng bộ.
Khi trao đổi phạm vi triển khai, hãy chuẩn bị tên các tích hợp, một luồng bị lệch có thể tái hiện và danh sách trường được phép thay đổi. Onter có thể nhận yêu cầu kiểm tra hoặc phát triển tích hợp theo đầu vào cụ thể tại trang liên hệ. Giá: Liên hệ. Nhận tư vấn & báo giá để làm rõ đường đọc, đường ghi và bằng chứng nghiệm thu cần bàn giao.
