Middleware: phần việc n8n, OpenClaw và mọi nền tảng tự động hóa không làm hộ bạn
Một chuỗi bán lẻ khoảng 20 người dùng phần mềm bán hàng và một CRM nội địa. Hai phần mềm đều tốt, đều có API, và đã nối với nhau bằng n8n trong một buổi chiều. Ba tuần sau, kế toán phát hiện doanh thu trên CRM thiếu 14 đơn so với sổ bán hàng, và có 6 khách bị tạo trùng hồ sơ.
Không có node nào lỗi. Không có workflow nào đỏ. Luồng vẫn chạy mỗi ngày.
Đó là hình dạng phổ biến nhất của bài toán tích hợp, và nó không nằm ở chỗ nền tảng tự động hóa mạnh hay yếu. Nó nằm ở lớp giữa mà không nền tảng nào làm hộ bạn.
n8n và OpenClaw giải hai bài toán khác nhau
So sánh trực tiếp hai thứ này là so nhầm trục.
n8n là nền tảng điều phối luồng: bạn định nghĩa trước sự kiện nào kích hoạt, đi qua những bước nào, rẽ nhánh ở đâu. Đổi lại, nó chạy có thể dự đoán được - cùng đầu vào cho cùng đường đi. Nó cũng tự host được, và ở chế độ queue thì tách main process khỏi worker để chịu tải cao hơn (tài liệu queue mode của n8n).
OpenClaw là tác nhân AI tự trị: bạn mô tả ý định bằng ngôn ngữ tự nhiên, nó tự suy luận ra các bước và gọi công cụ. Không có luồng định nghĩa trước, nên nó linh hoạt hơn hẳn với những việc không lặp lại - và cũng khó dự đoán hơn hẳn.
Chọn cái nào là chuyện dễ. Việc lặp lại, có quy tắc rõ, cần đúng từng lần thì dùng n8n. Việc mỗi lần một khác, cần đọc hiểu ngữ cảnh thì dùng tác nhân.
Nhưng cả hai đều dừng lại ở cùng một chỗ.
Bốn thứ lộ ra sau vài tuần chạy thật
Nối được API là phần dễ, và nó cho cảm giác đã xong việc. Bốn thứ dưới đây không xuất hiện trong buổi demo, chỉ xuất hiện sau vài tuần dữ liệu thật:
Cùng một sự kiện gửi tới hai lần. Hầu hết hệ thống gửi webhook đều cam kết at-least-once, không phải exactly-once. Bên gửi không nhận được HTTP 200 trong thời gian chờ thì nó gửi lại - kể cả khi bạn đã xử lý xong. Không có khóa chống trùng thì mỗi lần gửi lại là một bản ghi mới.
Webhook rơi mất một sự kiện. Bên gửi thử lại vài lần rồi bỏ cuộc. Hệ thống đích sập 10 phút đúng lúc đó là dữ liệu trong khoảng ấy mất vĩnh viễn, và không ai biết cho tới lúc đối soát cuối tháng.
Sửa và hủy. Đơn hàng bị hủy, hóa đơn bị điều chỉnh, khách trả lại một phần. Luồng một chiều "tạo mới khi có sự kiện" xử lý đúng lần tạo và sai mọi lần sau đó. Hệ thống đích giữ nguyên trạng thái cũ trong khi hệ thống nguồn đã đổi.
Bão thử lại. Hệ thống đích chậm đi, workflow timeout, cơ chế retry bắn lại - làm nó chậm thêm. Không có backoff và hàng đợi thất bại thì một sự cố nhỏ tự khuếch đại thành sự cố lớn.
Không thứ nào trong bốn thứ này là lỗi của n8n hay OpenClaw. Chúng nằm ngoài phạm vi của một nền tảng điều phối, theo đúng thiết kế.
Khóa chống trùng: chọn sai là hỏng cả hệ thống
Đây là quyết định kỹ thuật quan trọng nhất của một dự án tích hợp, và cũng là chỗ hay chọn sai nhất.
Cám dỗ đầu tiên là dùng updated_at. Nó hỏng vì hai lý do: nhiều API trả về thời gian chính xác tới giây, mà trong một giây có thể có nhiều thay đổi; và đồng hồ giữa hai hệ thống không bao giờ khớp tuyệt đối.
Cám dỗ thứ hai là dùng id của bản ghi nguồn. Nó chống được trùng lúc tạo, nhưng không phân biệt được phiên bản - một đơn hàng bị sửa ba lần vẫn chỉ có một id.
Khóa dùng được cần đủ bốn thành phần:
-- Khóa chống trùng: hệ thống nguồn + loại sự kiện + id bản ghi + phiên bản.
-- Thiếu version thì mọi lần sửa đơn hàng đều bị coi là trùng và bị bỏ qua.
CREATE TABLE sync_ledger (
source text NOT NULL, -- 'pos', 'marketplace', 'accounting'
event_type text NOT NULL, -- 'order.created', 'order.updated'
external_id text NOT NULL, -- id bên hệ thống nguồn
version text NOT NULL, -- revision/etag/hash payload nếu API không có
target_id text, -- id sau khi ghi sang hệ thống đích
processed_at timestamptz NOT NULL DEFAULT now(),
CONSTRAINT sync_ledger_pkey PRIMARY KEY (source, event_type, external_id, version)
);Ghi vào bảng này trước khi gọi hệ thống đích. Nếu insert đụng khóa chính, sự kiện đã xử lý rồi, dừng lại. Nếu API nguồn không có trường revision, hash payload đã chuẩn hóa để thay thế - chuẩn hóa trước khi hash, nếu không thì một khoảng trắng thừa cũng tạo ra phiên bản mới.
Bảng này cũng chính là thứ trả lời được câu hỏi "đơn hàng X đã sang CRM chưa, lúc nào, và thành bản ghi nào" - câu hỏi mà bất kỳ ai vận hành hệ thống tích hợp cũng sẽ hỏi trong tuần đầu tiên.
Webhook một mình không đủ
Webhook nhanh và rẻ, nhưng nó là kênh đẩy nên bạn không bao giờ biết được thứ mình không nhận được.
Cách làm dùng được là hai kênh song song:
- Webhook xử lý phần lớn sự kiện, độ trễ thấp.
- Bộ đối soát chạy định kỳ hỏi hệ thống nguồn "trong khoảng thời gian này có những bản ghi nào", so với
sync_ledger, và xử lý phần thiếu.
Bộ đối soát không phải phương án dự phòng. Nó là thứ duy nhất phát hiện được sự kiện bị rơi. Chạy mỗi 15 phút cho cửa sổ gần, và mỗi đêm cho cửa sổ rộng hơn để bắt những trường hợp hệ thống nguồn sửa dữ liệu quá khứ.
Trong n8n, phần thất bại nên đi vào một hàng đợi riêng thay vì biến mất trong log - n8n có sẵn error workflow để hứng những nhánh này (tài liệu error handling). Điều quan trọng không phải là công cụ, mà là một sự kiện thất bại phải nằm ở đâu đó tra lại được, chứ không chỉ là một dòng đỏ trong lịch sử chạy.
Lớp giữa cần những gì
Gộp lại, lớp giữa của một tích hợp chạy được trong production gồm sáu phần:
| Phần | Nhiệm vụ |
|---|---|
| Nhận sự kiện | Webhook + bộ đối soát định kỳ chạy song song |
| Sổ chống trùng | Khóa (nguồn, loại, id, phiên bản), ghi trước khi gọi đích |
| Bảng ánh xạ trường | Nguồn → chuyển đổi → đích, tách khỏi mã nguồn để sửa được mà không deploy |
| Adapter hệ thống đích | Thử lại có backoff, hàng đợi thất bại, giới hạn tốc độ gọi |
| Nhật ký tra vết | Mỗi sự kiện lưu payload vào, payload ra, kết quả |
| Bảng theo dõi | Số sự kiện chờ, số thất bại, độ trễ, kết quả đối soát gần nhất |
n8n làm rất tốt phần điều phối và phần adapter. Bốn phần còn lại là thứ bạn phải tự dựng, và là phần chiếm phần lớn thời gian của một dự án tích hợp thật.
📖Thu Thập Dữ Liệu Web cho Doanh Nghiệp Việt với n8n và Firecrawl
Node Firecrawl trong n8n có sáu thao tác dễ nhầm nhau: scrape, crawl, map, search, get status và cancel. Bài này đi qua từng cái và khi nào dùng...
hecigo làm gì ở đây
hecigo xây và vận hành lớp giữa đó, và nhận trách nhiệm về nó.
Phần công khai dùng được ngay là hai node n8n cộng đồng, phát hành trên npm và đang được duy trì: n8n-nodes-zalo-platform cho Zalo Bot Platform, và n8n-nodes-firecrawl-v2 cho Firecrawl. Nếu bạn tự dựng lớp giữa cho mình, hai node này tiết kiệm được vài buổi. Cách viết node riêng cũng nằm sẵn trong tài liệu của n8n.
Phần còn lại là công việc dự án: khảo sát hai hệ thống, chứng minh trên dữ liệu thật trước, rồi mới triển khai chính thức và vận hành. Chúng tôi không báo giá trước khi nhìn dữ liệu thật, vì con số đưa ra lúc đó chắc chắn sai - phần lớn chi phí của một tích hợp nằm ở những trường hợp ngoại lệ mà chỉ dữ liệu thật mới lộ ra.
Ranh giới không phải là loại phần mềm. Không quan trọng đó là phần mềm bán hàng, CRM, kế toán, sàn thương mại điện tử, email doanh nghiệp, kho dữ liệu hay một kênh mạng xã hội. Câu hỏi duy nhất là hai hệ thống đó có cần trao đổi dữ liệu với nhau hay không.
Thấy hữu ích? Theo dõi hecigo trên Zalo OA để nhận bài viết kỹ thuật mới sớm nhất - không spam, chỉ nội dung thực tế. Hoặc liên hệ trực tiếp nếu bạn cần hỗ trợ triển khai.
Đọc tiếp: Tối Ưu Tự Động Hóa Zalo Bot với n8n: Hướng Dẫn Chi Tiết từ hecigo
Zalo là ứng dụng nhắn tin phổ biến nhất tại Việt Nam, với hơn 75 triệu người dùng. Nếu doanh nghiệp của bạn hoạt động tại Việt Nam, khách hàng của...