Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Rất nhiều yêu cầu nghe như phải lập trình thực ra giải được bằng automation có sẵn. Bốn dấu hiệu cho biết yêu cầu đã vượt khỏi tầm và phải viết mã.
Buổi khảo sát ở một doanh nghiệp dịch vụ kỹ thuật. Phía kinh doanh nêu liền ba mong muốn:
Ba dòng đó vào bảng GAP kèm ghi chú cần customize, đội sale nhân với đơn giá ngày công của developer, rồi con số đi thẳng vào báo giá. Hai tuần sau, lúc dựng demo, cả ba được làm xong trong một buổi chiều trên một màn hình cấu hình có sẵn.
Ước lượng lệch kiểu này thì báo giá bị thổi lên, rồi khách mang đi so với đối thủ. Chiều ngược lại còn đắt hơn, bởi khi BA trót hứa rằng hệ thống tự làm được cho một yêu cầu mà thực ra phải viết mã, thì tới vòng UAT không ai gỡ được lời hứa đó ra khỏi biên bản.
Màn hình đó là Automation Rules, bản tiếng Việt gọi là Quy tắc tự động hóa, và trong nghề vẫn quen gọi là Automation Action. Bài này nói nó được kích hoạt bởi cái gì, làm được những hành động nào, và đâu là dấu hiệu cho biết yêu cầu đã vượt tầm của nó. Toàn bộ phần cơ chế trong bài này tôi mô tả trên Odoo 19, và đây là loại nội dung bạn phải dựng lại trên đúng bản mình đang chạy chứ không nên tin theo trí nhớ.
Chuyện này hay bị nói sai, và nói sai thì kéo theo cả quyết định chọn phiên bản.
Automation Action không phải tính năng riêng của bản Enterprise. Module đứng sau nó là base_automation, tên hiển thị Automation Rules, nằm ngay trong Community và phát hành theo giấy phép mở; trên Community bạn chỉ cần cài module đó nếu nó chưa được kéo vào cùng một phân hệ khác.
Tài liệu chính thức của Odoo mô tả công cụ này trong phần Studio nên rất dễ hiểu nhầm, và không ít tài liệu hướng dẫn vẫn xếp nó vào bản Enterprise, nhưng Studio chỉ là một trong hai đường vào. Đường còn lại là bật chế độ nhà phát triển rồi đi Settings, Technical, Automation, Automation Rules, và đường này có ở cả hai bản.
Điều kiện thứ hai chặt hơn hình dung của phần lớn người mới. Trên Odoo 19, quyền trên quy tắc tự động chỉ được cấp cho đúng một nhóm là nhóm quản trị cài đặt, nghĩa là key user không tự tạo được quy tắc dù bạn đã mở chế độ nhà phát triển cho họ. Do đó nếu doanh nghiệp muốn tự vận hành phần này sau go-live thì phải nói trước rằng người được giao sẽ cầm một quyền rất rộng.
Ranh giới giữa cấu hình và customize đã có bài riêng nói đủ; ở đây chỉ cần nhớ Automation Action nằm trọn bên phía cấu hình cho tới khi chạm vào hai thứ nói ở phần sau.
Một quy tắc gồm ba tầng nối tiếp nhau: sự kiện khởi chạy, bộ điều kiện lọc, rồi danh sách hành động. Sự kiện kích hoạt được chia thành năm nhóm, và danh sách thực tế hiện ra đổi theo model bạn chọn.
Cần lưu ý rằng các lựa chọn giai đoạn, trạng thái, thẻ và mức ưu tiên đều bắt buộc chỉ đích danh một giá trị, còn người phụ trách được gán thì không, nên quy tắc sẽ chạy với bất kỳ ai được gán.
Tầng điều kiện có hai ô. Ô Apply on mô tả bản ghi phải thỏa gì sau khi sự kiện xảy ra, còn ô Before Update Domain mô tả bản ghi đang ở trạng thái nào ngay trước đó, và ô này chỉ hiện đầy đủ khi bật chế độ nhà phát triển.
Ô thứ hai đáng nhớ hơn, bởi nó giải một bài toán mà không có nó thì phải viết mã: gửi thư xác nhận khi đơn chuyển sang trạng thái đơn hàng, nhưng chỉ với đơn trước đó còn ở trạng thái nháp, để khách đã nhận thư báo giá thì không nhận thêm thư nữa. Tuy nhiên điều kiện trước không được kiểm khi bản ghi vừa được tạo.
Danh sách này ngắn hơn nhiều người tưởng, và chính độ ngắn của nó vạch ra ranh giới.
Trên bản Enterprise danh sách dài thêm vài lựa chọn như cập nhật trường bằng AI hay gửi tin WhatsApp, cả hai đều phụ thuộc ứng dụng không có trong Community.
Còn lại đúng hai hành động là thực thi mã và gửi thông báo webhook, và đó chính là ranh giới giữa việc của BA với việc của developer.
Automation Action tác động lên chính những bản ghi đã kích hoạt nó, không có khái niệm duyệt qua một tập bản ghi khác, không có vòng lặp, và không cộng dồn được kết quả qua nhiều dòng.
Do đó hễ yêu cầu có chữ với tất cả, từng dòng một, hoặc gom lại rồi, thì bạn nên dừng lại. Yêu cầu kiểu mỗi tối rà toàn bộ hợp đồng sắp hết hạn rồi tạo bản kê gửi trưởng phòng là việc của một tác vụ theo lịch có mã bên trong. Trong trường hợp các dòng độc lập với nhau thì vẫn lách được bằng một điều kiện thật hẹp, để mỗi bản ghi tự chạy phần của nó, nhưng khi đầu ra là một bản tổng hợp thì không có đường lách.
Hễ dữ liệu phải đi ra khỏi Odoo hoặc đi vào từ bên ngoài, tức đẩy chứng từ sang hệ thống hóa đơn hay nhận trạng thái giao hàng từ nhà vận chuyển, là bạn đang ở vùng tích hợp.
Hệ thống có sẵn hai đầu cho việc này, một sự kiện nhận webhook vào và một hành động bắn webhook ra, nên về kỹ thuật thì cấu hình được. Tuy nhiên chính tài liệu của Odoo khuyến nghị có developer hoặc người làm kỹ thuật tham gia từ lúc quyết định dùng webhook và suốt quá trình triển khai, bởi cấu hình sai có thể làm rối cơ sở dữ liệu và mất thời gian gỡ lại.
Phần cấu hình thì mười phút, còn phần khiến nó chạy đúng thì không nằm trên màn hình đó.
Ô điều kiện là một bộ lọc chứ không phải một đoạn logic.
Nó nối các vế bằng và, hoặc, phủ định, đi qua được trường quan hệ, nhưng chỉ trả lời đúng một câu là bản ghi này có thỏa hay không. Vì vậy ngay khi yêu cầu có dạng nếu thế này thì làm A, nếu thế kia thì làm B, còn lại thì làm C, và mỗi nhánh phụ thuộc dữ liệu ở một bảng khác, thì bạn đã ra khỏi vùng cấu hình.
Tách ba quy tắc cho ba nhánh thì về lý thuyết vẫn được, và với hai nhánh rõ ràng thì chấp nhận được. Nhưng từ ba nhánh trở lên với điều kiện chồng lấn nhau, bạn đang giấu một cây quyết định vào ba màn hình rời nhau, và người tiếp quản sáu tháng sau phải dò ngược từng quy tắc mới hiểu vì sao một đơn lại đi nhánh này.
Yêu cầu dạng vừa gõ vào ô này thì ô kia phải tự đổi ngay, chưa cần bấm lưu, nghe rất nhỏ, nhưng nó là dấu hiệu rõ nhất trong bốn dấu hiệu.
Hệ thống có đúng một lựa chọn cho việc này là sự kiện On UI change, và đi kèm hai ràng buộc: nó chỉ dùng được với hành động thực thi mã, và chỉ chạy khi người dùng sửa tay chứ không chạy khi trường bị một quy tắc khác đổi. Ràng buộc thứ nhất nghĩa là yêu cầu này luôn cần developer, không có đường vòng.
Đây cũng là chỗ nên nói thẳng về giới hạn của vai trò. Một người triển khai Odoo lâu năm khi hướng dẫn phần này đã nhấn mạnh rằng BA thường không dùng được hành động thực thi mã và cần dev hỗ trợ, còn mục đích của việc nắm công cụ chỉ là biết hệ thống làm được gì để tư vấn đúng. Trên Odoo 19 ràng buộc còn cứng hơn, bởi ô nhập mã chỉ dành cho nhóm quản trị cài đặt, nên tài khoản ngoài nhóm đó sẽ không thấy ô nhập.
Còn một giới hạn nữa nằm ngoài bốn dấu hiệu trên, và nó làm hỏng nhiều cam kết nhất.
Quy tắc theo thời gian không tự chạy đúng vào lúc tới hạn. Nó chờ một tác vụ theo lịch tên là Automation Rules: check and execute quét qua rồi mới thực thi, và tác vụ này mặc định chạy bốn tiếng một lần.
Điểm tinh tế mà phần lớn tài liệu hướng dẫn chưa nêu là chu kỳ đó không cố định. Khi có một quy tắc thời gian với độ trễ ngắn, hệ thống tự rút chu kỳ quét xuống còn khoảng một phần mười độ trễ đó, chẳng hạn độ trễ ba tiếng thì chu kỳ về mười tám phút, với mức sàn một phút và mức trần bốn tiếng.
Nhưng cơ chế này chỉ biết rút ngắn chứ không biết nới ra, và chu kỳ là của cả hệ thống chứ không của riêng quy tắc bạn vừa tạo.
Hệ quả về lâu dài là thêm một quy tắc có độ trễ dài hơn thì chu kỳ vẫn giữ nguyên, và ngay cả khi bạn tắt hết mọi quy tắc theo thời gian thì tác vụ theo lịch vẫn nằm ở chu kỳ ngắn nhất mà nó từng bị kéo xuống, chỉ có điều nó chuyển sang trạng thái không hoạt động. Muốn đưa chu kỳ về lại bốn tiếng thì bạn phải mở tác vụ theo lịch đó ra sửa tay.
Gói lại cho lúc ngồi với khách: bốn tiếng là mặc định và là mức chậm nhất, nhưng đây vẫn là quét theo lô nên đừng cam kết mốc phản hồi tính bằng phút.
Đi kèm là một bẫy vận hành. Sau khi lưu quy tắc theo thời gian, bạn phải mở tác vụ theo lịch đó ra bấm Run manually một lần để đặt lại mốc lần chạy gần nhất, bởi quy tắc chỉ thực thi với những mốc rơi vào khoảng giữa lần chạy trước và lần chạy hiện tại; bỏ bước này thì quy tắc có thể chạy hồi tố lên dữ liệu lịch sử, và thứ bạn nhận được là hàng loạt thư sinh ra cùng lúc.
Trong một quy tắc, các hành động chạy đúng thứ tự bạn xếp, nên đặt gửi thư trước rồi mới cập nhật trường thì thư mang giá trị cũ.
Giữa các quy tắc thì rối hơn, bởi chúng gọi lẫn nhau. Một quy tắc trên cơ hội tạo ra bản ghi hợp đồng, việc tạo bản ghi đó lại kích hoạt một quy tắc khác trên model hợp đồng, quy tắc này cập nhật một trường trên liên hệ, và trường đó lại đang được một quy tắc thứ ba theo dõi. Giao diện không có chỗ nào cho bạn thấy chuỗi đó.
Rủi ro rõ nhất nằm ở sự kiện tạo mới và mỗi lần sửa. Tài liệu của Odoo yêu cầu phải chọn trường được theo dõi trong ô When updating, nhưng màn hình không chặn bạn để trống, và để trống thì hành động có thể chạy nhiều lần trên một bản ghi, tức chạy lại ở mỗi lần bấm lưu.
Cách mô tả thường gặp còn nặng hơn, ở mức chạy lặp vô hạn; trên Odoo 19 hệ thống có đánh dấu những bản ghi mà một quy tắc đã xử lý trong cùng một lượt để quy tắc đó không tự gọi lại chính nó, nên cách nói chính xác là quy tắc chạy lại mỗi lần lưu chứ không phải lặp không dừng.
Thêm một lớp về quyền: trên Odoo 19, quy tắc được tìm, lọc và thực thi dưới quyền hệ thống chứ không dưới quyền người vừa bấm lưu, nên đừng giả định người dùng thiếu quyền trên một model thì quy tắc sẽ không chạm được vào model đó.
Vì vậy trước khi đưa một quy tắc lên hệ thống thật, hãy chạy qua danh sách này:
Nếu dự án có yêu cầu rơi vào bốn dấu hiệu trên thì đó không còn là chuyện cấu hình, và lúc đó bài về nguyên tắc làm toàn bộ bằng code cho cả dự án là thứ nên đọc trước khi quyết định. Cần nói thêm rằng chính công cụ kéo thả đi cùng Automation Action lại hữu dụng nhất ở một giai đoạn sớm hơn nhiều, khi bạn cần dựng một màn hình mẫu để khách nhìn thấy thứ mình đang mô tả.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận