Xác định hệ thống nguồn cho từng dữ liệu
Bản đồ nên liệt kê từng thực thể như khách hàng, liên hệ, sản phẩm, đơn hàng, hóa đơn và trạng thái thanh toán. Với mỗi trường, cần ghi hệ thống tạo dữ liệu, hệ thống được phép sửa và các nơi chỉ nhận bản sao. Gợi ý: tránh quy ước chung chung rằng CRM hoặc kế toán là nguồn của mọi thông tin; quyền sở hữu có thể khác nhau ở cấp trường, chẳng hạn CRM quản lý người phụ trách còn phần mềm kế toán quản lý công nợ.
Mỗi thực thể cần có mã định danh ổn định và bảng đối chiếu mã giữa các hệ thống. Không nên dùng tên, email hoặc số điện thoại làm khóa duy nhất nếu các giá trị đó có thể đổi hoặc trùng. Bản đồ cũng nên nêu quy tắc gộp bản ghi, cách xử lý khách hàng bị xóa và dữ liệu nào phải được giữ lại để đối soát.
Vẽ luồng theo sự kiện nghiệp vụ
Thay vì nối mọi hệ thống theo cả hai chiều, hãy mô tả từng luồng có điểm bắt đầu và điểm kết thúc: khách gửi biểu mẫu trên website, CRM tạo cơ hội, đơn hàng được xác nhận, kế toán phát hành hóa đơn hoặc ghi nhận thanh toán. Webhook cho phép hệ thống đăng ký sự kiện và nhận dữ liệu khi sự kiện xảy ra; cách này phù hợp với cập nhật gần thời gian thực hơn việc liên tục gọi API để dò thay đổi. [2]
Ví dụ: website gửi yêu cầu tư vấn sang CRM; khi cơ hội chuyển thành đơn hàng đã xác nhận, dịch vụ tích hợp tạo đề nghị lập hóa đơn trong hệ thống kế toán. Trạng thái thanh toán sau đó chỉ được trả về CRM và website để hiển thị, không cho hai hệ thống này tự sửa số tiền. Đây là gợi ý thiết kế, doanh nghiệp cần điều chỉnh theo quy trình phê duyệt thực tế.
Lập bảng ánh xạ và quy tắc chuyển đổi
Bảng ánh xạ nên đặt trường nguồn cạnh trường đích, kèm kiểu dữ liệu, định dạng, trường bắt buộc, giá trị mặc định và quy tắc chuyển đổi. Cần làm rõ các danh mục dễ lệch như mã sản phẩm, đơn vị tính, thuế, tiền tệ, trạng thái đơn hàng và địa chỉ. Với trường không có tương đương, hãy quyết định lưu ở trường mở rộng, chuyển thành ghi chú hay không đồng bộ.
Gợi ý: bổ sung quy tắc kiểm tra trước khi ghi dữ liệu, bao gồm giá trị rỗng, độ dài, trạng thái không hợp lệ và quan hệ thiếu bản ghi cha. Lỗi chuyển đổi nên được ghi cùng mã bản ghi nguồn và bước xử lý, nhưng nhật ký cần hạn chế dữ liệu nhạy cảm. Cách mô tả này giúp đội vận hành biết lỗi nào có thể sửa dữ liệu rồi chạy lại, lỗi nào cần thay đổi phần mềm.
Thiết kế đồng bộ có thể phục hồi
Bản đồ dữ liệu cần ghi rõ cơ chế kích hoạt của từng luồng: webhook, gọi API theo lịch hay thao tác thủ công. Webhook gửi yêu cầu HTTP đến URL đã đăng ký khi có sự kiện; còn API phù hợp khi chỉ cần lấy thông tin một lần hoặc không thường xuyên. Gợi ý: dù chọn cách nào, hãy thống nhất mã giao dịch, trạng thái xử lý và nguyên tắc chống tạo trùng khi một yêu cầu được gửi lại. [2]
Nên xác định trước nơi lưu hàng đợi, thời gian chờ, cách thử lại và người nhận cảnh báo. Một màn hình đối soát có thể hiển thị bản ghi thành công, thất bại và đang chờ, đồng thời cho phép chạy lại theo quyền hạn. Đây là biện pháp tăng khả năng phục hồi và quan sát, không phải bảo đảm rằng tích hợp sẽ luôn hoạt động liên tục.
Khoanh vùng quyền truy cập và dữ liệu nhạy cảm
OWASP lưu ý API có thể gặp lỗi phân quyền ở cấp đối tượng, thuộc tính hoặc chức năng; dữ liệu nhận từ API bên thứ ba cũng không nên mặc nhiên được tin cậy. Vì vậy, mỗi luồng nên chỉ đọc và ghi đúng trường cần thiết, kiểm tra quyền với từng bản ghi, xác thực dữ liệu đầu vào và tách quyền quản trị khỏi quyền vận hành thông thường. [1]
Gợi ý: tài liệu hóa endpoint, phiên bản API, thông tin xác thực, môi trường triển khai và chủ sở hữu kỹ thuật. Đồng thời quy định cách thay khóa bí mật, che dữ liệu trong nhật ký và ngừng endpoint cũ. Các kiểm soát này giúp giảm bề mặt rủi ro nhưng cần được kiểm tra định kỳ theo kiến trúc, cấu hình và yêu cầu bảo mật cụ thể của doanh nghiệp. [1]