Thư mục SFTP xuất hiện một file CSV không có nghĩa file đã được gửi xong. Bên nhận có thể mở đúng tên nhưng mới đọc được nửa dữ liệu. Nhận file SFTP cần một tín hiệu bàn giao được hai bên thống nhất, sau đó mới tới kiểm cấu trúc và import.
Đừng dùng sự xuất hiện của tên file làm biên nhận hoàn tất
Nếu bên gửi ghi trực tiếp vào tên cuối, chương trình theo dõi thư mục có thể thấy file trước khi kết nối truyền kết thúc. Kích thước chưa đổi trong vài giây cũng không chứng minh hoàn tất: mạng có thể tạm ngừng hoặc phía gửi đang đợi. Cần phân biệt “đã nhìn thấy file”, “bên gửi bàn giao” và “bên nhận chấp nhận”.
WinSCP trình bày các cách dùng tên tạm hoặc thư mục tạm rồi đổi tên/chuyển sau truyền. Chức năng cụ thể phụ thuộc giao thức và máy chủ; không suy rằng mọi thao tác move giữa mọi nơi đều atomic. Hai bên phải thử hành vi trên đường truyền và hệ thống file thực tế được dùng.
Viết hợp đồng nhỏ cho bên gửi và bên nhận
Một phương án là bên gửi dùng hậu tố .filepart, bên nhận bỏ qua hậu tố đó, và chỉ xét tên cuối sau bước đổi tên thành công. Tên cuối nên có định danh lần truyền, không chỉ ngày giờ dễ trùng. Không để hai bên gửi ghi vào cùng một tên chung rồi coi file cuối cùng là dữ liệu đúng.
Hợp đồng cần nói rõ thư mục, mẫu tên, quyền tạo/đổi tên, cách báo lỗi và chính sách khi tên cuối đã tồn tại. Nếu dùng file “done”, phải liên kết done với đúng transfer ID và danh sách file; một marker chung trong thư mục nhiều người gửi có thể mở nhầm bộ dữ liệu. Không dùng mật khẩu hay khóa SFTP trong tên, marker hoặc báo cáo xử lý.
Bàn giao file khác chấp nhận dữ liệu
Sau tên cuối, bên nhận vẫn cần kiểm loại file, kích thước cho phép, cấu trúc và định danh nguồn. Nếu có hash do bên gửi cung cấp qua kênh đáng tin, đối chiếu để phát hiện sai khác byte. Hash không chứng minh nội dung nghiệp vụ đúng, người gửi có quyền hoặc file an toàn để thực thi.
| Mốc | Bằng chứng cần giữ | Chưa được kết luận |
|---|---|---|
| Truyền xong | Transfer ID, tên cuối, kết quả bàn giao | Đã import |
| Kiểm đầu vào | Hash/kích thước/schema theo hợp đồng | Dữ liệu nghiệp vụ đúng |
| Chấp nhận | Quyết định import và receipt | Mọi hệ thống sau đó đã đồng bộ |
Giữ file gốc theo quyền và thời hạn đã thống nhất. File không đạt cần lý do dễ xử lý, chẳng hạn thiếu cột bắt buộc, không phải một thông báo “SFTP lỗi” khi thực ra truyền đã thành công. Khu vực file lỗi phải được phân quyền; không di chuyển sang thư mục công khai để người khác dễ tải.
Ví dụ giả định: cùng dữ liệu được gửi lại
Đối tác gửi transfer R-17, sau đó mất kết nối trước khi nhận xác nhận của bên nhận. Lần sau họ gửi lại R-17 với cùng nội dung. Sổ bàn giao cần cho biết đã có receipt chấp nhận hay chưa; nếu đã import, trả lại tham chiếu kết quả cũ theo quy tắc đã duyệt, không tự import lần hai.
Nếu R-17 được gửi lại nhưng byte khác, đó không còn là một bản gửi lại đơn giản. Giữ cả dấu vết và chuyển nhánh sửa phiên bản hoặc chờ người phụ trách. Không ghi đè file trước chỉ vì tên giống; chính sách sửa dữ liệu phải xác định ai được thay, phạm vi và ảnh hưởng của bộ đã xử lý.
Kiểm các gián đoạn có thể nhìn thấy
Bộ kiểm tra nên có truyền bị ngắt, bên nhận khởi động lại giữa lúc quan sát thư mục, đổi tên bị từ chối, tên cuối đã tồn tại và marker đến trước dữ liệu. Thử cả hai người gửi đồng thời. Đầu ra cần chứng minh không đọc tên tạm, không chấp nhận nhầm bộ và có thể nối receipt với đúng lần truyền.
Không yêu cầu bên vận hành tự mở file nghi ngờ để “xem có đủ dòng không” trên máy cá nhân. Quy trình tiếp nhận nên dùng công cụ và quyền phù hợp, có owner xử lý ngoại lệ. Bài này đưa kế hoạch và hợp đồng mẫu, chưa khẳng định một nền tảng SFTP hoặc luồng Onter đã qua kiểm thử.
Đặt kiểm dữ liệu sau đúng bước bàn giao
Sau khi hoàn tất tiếp nhận, kiểm CSV trước import giải quyết kiểu dữ liệu và cột; nó không thay tín hiệu truyền xong. Nếu upload đi qua nhiều phần, toàn vẹn multipart là cơ chế khác cần hợp đồng riêng. Để khảo sát tích hợp phần mềm với Onter, chuẩn bị mẫu tên đã ẩn dữ liệu, quy tắc sửa bộ và các receipt đang có; không gửi thông tin đăng nhập SFTP qua form tư vấn.
