Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã làm quen với hai "công tắc rẽ nhánh" cơ bản nhất của BPMN: Exclusive Gateway (XOR — chọn một nhánh dựa trên dữ liệu) và Parallel Gateway (AND — chạy song song nhiều nhánh). Hai loại này đủ để mô tả phần lớn quy trình hằng ngày. Nhưng khi bạn bắt đầu vẽ những quy trình thực tế có yếu tố "chờ đợi", "thời hạn", "phản hồi từ bên ngoài" hay "đua tranh giữa nhiều sự kiện", bạn sẽ chạm trần.
Hãy nghĩ về một tình huống quen thuộc: bạn đặt hàng trên Tiki, hệ thống chờ bạn thanh toán. Có ba khả năng xảy ra: bạn thanh toán thành công, bạn hủy đơn, hoặc bạn không làm gì cả và sau 24 giờ đơn tự hết hạn. Quy trình ở đây không "quyết định" dựa trên một biến dữ liệu có sẵn — nó đứng chờ và phản ứng theo sự kiện nào đến trước. Đây chính xác là lúc Exclusive Gateway thông thường bất lực, vì nó cần biết câu trả lời ngay tại thời điểm token chạy tới. Còn ở đây, câu trả lời nằm ở tương lai.
Bài 17 giới thiệu hai gateway nâng cao giải quyết đúng những bài toán "khó nhằn" này: Event-based Gateway (cổng dựa trên sự kiện) và Complex Gateway (cổng phức hợp). Nắm vững chúng, bạn sẽ mô hình hóa được những quy trình mà trước đây phải "vẽ chữa cháy" bằng nhiều task lằng nhằng — và quan trọng hơn, mô hình của bạn sẽ chạy đúng khi đưa vào một process engine như Camunda hay Bizagi.
Khái niệm cốt lõi
Event-based Gateway — cổng "đợi và đua"
Event-based Gateway là hình thoi (diamond) giống mọi gateway khác, nhưng bên trong có một biểu tượng đặc trưng: một ngũ giác (pentagon) nằm trong vòng tròn kép. Ký hiệu này gợi nhắc đến biểu tượng của Intermediate Event — và đó không phải ngẫu nhiên. Khác biệt cốt lõi của loại gateway này là:
> Nó không quyết định dựa trên dữ liệu, mà dựa trên sự kiện nào xảy ra trước.
Khi token chạy đến Event-based Gateway, quy trình dừng lại và chờ. Từ gateway này tỏa ra nhiều nhánh, nhưng mỗi nhánh bắt buộc phải bắt đầu bằng một trong hai thứ: một Intermediate Catch Event (sự kiện bắt — ví dụ Message, Timer, Signal) hoặc một Receive Task (task nhận tin nhắn). Tất cả các nhánh cùng "lắng nghe" đồng thời. Sự kiện nào xảy ra trước, nhánh đó thắng, token đi theo nhánh đó, và tất cả các nhánh còn lại bị hủy bỏ (canceled). Đây chính là khái niệm race condition (điều kiện đua) — chỉ một người về đích.
Hãy phân biệt rõ với Exclusive Gateway:
| Tiêu chí | Exclusive Gateway (XOR) | Event-based Gateway |
|---|---|---|
| Cơ sở quyết định | Dữ liệu/điều kiện có sẵn ngay lập tức | Sự kiện đến trước (tương lai) |
| Hành vi khi token đến | Đánh giá điều kiện rồi đi ngay | Dừng, chờ, lắng nghe nhiều sự kiện |
| Mỗi nhánh bắt đầu bằng | Sequence flow có condition | Catch Event hoặc Receive Task |
| Có yếu tố thời gian/chờ | Không | Có — đây là điểm mạnh chính |
Một biến thể đáng nhớ: Event-based Gateway có thể đóng vai trò bắt đầu một quy trình (instantiate). Khi đó, thay vì token chờ tại gateway, bản thân sự kiện đầu tiên đến sẽ khởi tạo một instance quy trình mới. Ký hiệu lúc này là ngũ giác trong vòng tròn đơn (thay vì kép). Bạn sẽ gặp dạng này khi mô hình hóa một quy trình "luôn sẵn sàng lắng nghe", ví dụ một dịch vụ chờ nhận một trong nhiều loại yêu cầu khác nhau từ khách hàng.
Complex Gateway — cổng cho logic không gọn gàng
Complex Gateway có ký hiệu là hình thoi với một dấu sao (asterisk/dấu hoa thị) bên trong. Đây là loại gateway dùng khi logic phân nhánh hoặc gộp nhánh quá phức tạp để diễn đạt bằng XOR, AND hay OR thông thường.
Hai tình huống điển hình cần Complex Gateway:
- Gộp nhánh kiểu "M trên N": Bạn có 5 nhánh chạy song song, nhưng quy trình chỉ cần 3 trong 5 nhánh hoàn thành là đủ để đi tiếp (ví dụ: cần 3 trong 5 chuyên gia thẩm định xong là duyệt được hồ sơ). Parallel Gateway đòi 100% (5/5), Inclusive Gateway phụ thuộc vào nhánh nào được kích hoạt — cả hai đều không diễn đạt được "3/5". Complex Gateway dùng một activation condition (điều kiện kích hoạt) để mô tả chính xác ngưỡng này.
- Logic phân nhánh điều kiện phức tạp trộn lẫn nhiều yếu tố mà không gateway chuẩn nào gói gọn được.
Mối liên hệ giữa hai gateway
Cả hai gateway trong bài này đều là "công cụ chuyên dụng" cho những bài toán mà gateway cơ bản không kham nổi. Event-based xử lý chiều thời gian và sự kiện bên ngoài; Complex xử lý logic gộp/tách phi chuẩn. Bạn sẽ thấy Event-based xuất hiện rất thường xuyên trong quy trình thực tế (vì quy trình nào cũng có chờ đợi và timeout), còn Complex thì hiếm hơn nhiều — và đó là điều bình thường.
Tình huống thực tế
Ví dụ 1 — Tiki: chờ thanh toán đơn hàng (Event-based Gateway)
Bối cảnh: Sàn thương mại điện tử Tiki xử lý hàng trăm nghìn đơn mỗi ngày. Với đơn chọn phương thức "chuyển khoản/thanh toán online", sau khi khách bấm đặt hàng, hệ thống tạo đơn ở trạng thái "Chờ thanh toán" và bắt đầu chờ.
Mô hình hóa: Sau task "Tạo đơn hàng", token chạy đến một Event-based Gateway. Từ đây tỏa ra ba nhánh:
- Nhánh 1 bắt đầu bằng Message Intermediate Catch Event "Nhận xác nhận thanh toán" — kích hoạt khi cổng thanh toán (ví dụ VNPay, ZaloPay) gửi tín hiệu thành công.
- Nhánh 2 bắt đầu bằng Message Intermediate Catch Event "Nhận yêu cầu hủy đơn" — kích hoạt khi khách bấm "Hủy đơn".
- Nhánh 3 bắt đầu bằng Timer Intermediate Catch Event đặt ở 24 giờ — kích hoạt nếu sau 24 giờ không có gì xảy ra.
Bài học rút ra: Nếu một junior analyst mô hình hóa cái này bằng Exclusive Gateway, họ sẽ bí — vì XOR cần biết "đã thanh toán hay chưa" ngay tại thời điểm token tới, trong khi câu trả lời nằm ở tương lai. Event-based Gateway chính là công cụ duy nhất biểu diễn đúng được "chờ và đua" này. Đây cũng là lý do mọi quy trình có timeout (giữ vé, giữ phòng khách sạn, OTP hết hạn) gần như luôn cần Event-based Gateway.
Ví dụ 2 — Ngân hàng: phê duyệt hồ sơ tín dụng "3 trên 5" (Complex Gateway)
Bối cảnh: Một ngân hàng TMCP tại Việt Nam thẩm định hồ sơ vay doanh nghiệp lớn (trên 50 tỷ đồng). Theo chính sách quản trị rủi ro, hồ sơ phải được gửi tới một hội đồng gồm 5 thành viên (đại diện khối tín dụng, pháp chế, thẩm định tài sản, quản lý rủi ro, và một thành viên độc lập). Quy định: chỉ cần 3 trong 5 thành viên phê duyệt là hồ sơ được thông qua, không cần chờ đủ cả 5 — để tránh tắc nghẽn khi có người đi công tác.
Mô hình hóa: Sau task "Gửi hồ sơ tới hội đồng", một Parallel Gateway tách thành 5 nhánh, mỗi nhánh là một task "Thẩm định bởi thành viên X". Sau đó, 5 nhánh gộp lại tại một Complex Gateway với activation condition: số nhánh hoàn thành với kết quả "Duyệt" >= 3. Khi điều kiện này đạt, token đi tiếp tới "Giải ngân"; các nhánh còn lại đang dang dở được xử lý theo quy tắc đã định nghĩa.
Diễn giải: Tại sao không dùng Parallel Gateway để gộp? Vì Parallel đòi cả 5 nhánh xong mới đi tiếp — nếu một thành viên đi công tác 3 ngày, cả hồ sơ đứng im. Tại sao không dùng Inclusive (OR)? Vì Inclusive gộp dựa trên "những nhánh nào đã được kích hoạt", không có khái niệm ngưỡng "3 trên 5". Chỉ Complex Gateway, với activation condition tường minh, mới mô tả đúng quy tắc nghiệp vụ này.
Bài học rút ra: Complex Gateway tỏa sáng khi nghiệp vụ có ngưỡng số lượng (quorum) — kiểu "đa số", "ít nhất N người", "2/3 hội đồng". Đây là tình huống chính đáng để dùng nó. Nhưng hãy luôn kèm một Text Annotation ghi rõ activation condition cạnh gateway, vì người đọc sơ đồ không thể đoán "3 trên 5" chỉ từ dấu hoa thị.
Ví dụ 3 — Grab: chờ tài xế nhận chuyến hoặc khách hủy (Event-based Gateway)
Bối cảnh: Khi một khách hàng ở TP.HCM đặt GrabBike, hệ thống đẩy yêu cầu tới các tài xế gần đó và bắt đầu một khoảng chờ.
Mô hình hóa: Sau task "Phát yêu cầu tới tài xế", token tới Event-based Gateway với ba nhánh:
- Message Catch "Tài xế nhận chuyến" → đi tiếp "Ghép chuyến → Bắt đầu hành trình".
- Message Catch "Khách hủy yêu cầu" → đi tiếp "Hủy chuyến → Thông báo khách".
- Timer Catch 90 giây → nếu hết 90 giây chưa ai nhận → đi tiếp "Mở rộng bán kính tìm tài xế / Báo không có tài xế".
Bài học rút ra: Khi thiết kế, hãy luôn tự hỏi "nếu không có sự kiện nào xảy ra thì sao?". Câu trả lời gần như luôn là: phải có một nhánh timer làm lối thoát. Một Event-based Gateway thiếu nhánh timer là một cái bẫy treo quy trình mãi mãi — instance sẽ kẹt ở đó vô thời hạn nếu không sự kiện nào tới.
Hướng dẫn từng bước
Khi bạn cần đưa Event-based Gateway hoặc Complex Gateway vào sơ đồ, hãy theo trình tự sau:
Bước 1 — Xác định bản chất bài toán. Tự hỏi: việc rẽ nhánh ở đây do dữ liệu có sẵn quyết định, hay do sự kiện trong tương lai quyết định? Nếu là sự kiện/thời gian → nghĩ tới Event-based. Nếu là logic gộp phi chuẩn (ngưỡng số lượng, điều kiện chồng chéo) → cân nhắc Complex.
Bước 2 — Với Event-based Gateway, liệt kê toàn bộ sự kiện có thể xảy ra. Đừng quên ba câu hỏi: (a) Trường hợp thành công là gì? (b) Trường hợp người dùng chủ động thay đổi (hủy, sửa) là gì? (c) Trường hợp không có gì xảy ra (timeout) là gì? Mỗi câu trả lời thường tương ứng một nhánh.
Bước 3 — Đảm bảo mỗi nhánh bắt đầu đúng phần tử. Mỗi nhánh sau Event-based Gateway phải mở đầu bằng Intermediate Catch Event hoặc Receive Task. Tuyệt đối không đặt một task thường (như "Xử lý đơn") làm phần tử đầu nhánh — đó là lỗi cú pháp BPMN.
Bước 4 — Bỏ mọi condition trên sequence flow của các nhánh. Khác với XOR, ở đây sequence flow không mang điều kiện. Việc chọn nhánh do sự kiện quyết định.
Bước 5 — Với Complex Gateway, viết activation condition rõ ràng. Diễn đạt điều kiện kích hoạt bằng ngôn ngữ chính xác (ví dụ: "ít nhất 3 nhánh trả về Duyệt"). Đặt một Text Annotation cạnh gateway để giải thích, vì dấu hoa thị tự nó không nói lên logic.
Bước 6 — Kiểm tra lối thoát và việc dọn dẹp. Với Event-based, kiểm tra có nhánh timer không. Với Complex, suy nghĩ điều gì xảy ra với các nhánh chưa hoàn thành sau khi điều kiện kích hoạt đã đạt — chúng bị bỏ qua hay vẫn chạy?
Bước 7 — Mô phỏng bằng token. Tưởng tượng đặt một đồng xu (token) tại điểm bắt đầu và "chạy" qua gateway với từng kịch bản sự kiện khác nhau. Nếu mọi kịch bản đều dẫn token tới một kết thúc hợp lý, mô hình của bạn đúng.
Lỗi thường gặp & mẹo
Lỗi 1 — Đặt task thường sau Event-based Gateway. Đây là lỗi phổ biến nhất. Người mới hay vẽ Event-based Gateway rồi nối thẳng tới task "Xử lý thanh toán". Sai. Phải có một Catch Event ("Nhận xác nhận thanh toán") đứng giữa. Mẹo: nhớ câu "sau cổng sự kiện luôn là sự kiện".
Lỗi 2 — Quên nhánh timeout. Mô hình hóa "chờ thanh toán" mà chỉ có nhánh "thành công" và "hủy", thiếu nhánh timer. Hậu quả: khi đưa vào engine, instance treo vĩnh viễn. Mẹo: với mọi trạng thái chờ, luôn hỏi "nếu chờ mãi không có gì thì sao?".
Lỗi 3 — Đặt condition lên sequence flow của Event-based Gateway. Một số người trộn lẫn tư duy XOR vào đây. Nhớ: cổng sự kiện chọn nhánh bằng sự kiện, không bằng dữ liệu.
Lỗi 4 — Lạm dụng Complex Gateway. Dùng Complex chỉ vì thấy nó "ngầu", trong khi một cặp XOR/AND đơn giản đã đủ. Hậu quả: sơ đồ khó đọc, đồng nghiệp không hiểu. Mẹo vàng: nếu phải dùng Complex Gateway, hãy chắc chắn không có cách nào đơn giản hơn — và luôn chú thích activation condition.
Lỗi 5 — Nhầm Event-based Gateway với Parallel. Event-based chỉ chọn một nhánh (nhánh thắng); các nhánh khác bị hủy. Nó không chạy song song nhiều nhánh. Nếu bạn muốn chờ đồng thời nhiều sự kiện và tất cả đều phải xảy ra, đó là bài toán khác (kết hợp Parallel + các catch event), không phải Event-based Gateway.
Mẹo chuyên gia: Trong Camunda hay Bizagi, hãy thử "play through" mô hình bằng tính năng mô phỏng/token simulation trước khi triển khai. Đặc biệt với Event-based Gateway, hãy test kịch bản "hai sự kiện đến gần như đồng thời" để hiểu engine xử lý race condition thế nào — thường engine sẽ chọn sự kiện được ghi nhận trước theo dấu thời gian.
Bài tập thực hành
Bài tập 1 — Đặt phòng khách sạn (Event-based). Một website đặt phòng giữ phòng cho khách trong 15 phút sau khi chọn. Hãy vẽ phần quy trình sau task "Giữ phòng tạm thời" sử dụng Event-based Gateway với các nhánh: (a) khách thanh toán → xác nhận đặt phòng; (b) khách hủy → nhả phòng; (c) hết 15 phút không thanh toán → tự động nhả phòng. Ghi rõ loại event ở đầu mỗi nhánh.
Bài tập 2 — Hội đồng tuyển dụng (Complex). Một công ty phỏng vấn ứng viên qua 4 người phỏng vấn song song. Quy tắc: ứng viên đậu nếu ít nhất 3 trên 4 người phỏng vấn chấm "Đạt". Hãy vẽ phần gộp nhánh dùng Complex Gateway và viết activation condition bằng lời. Sau đó tự đánh giá: liệu có cách nào diễn đạt rõ hơn không?
Bài tập 3 — Phân biệt (tư duy). Cho tình huống: "Khách hàng gửi khiếu nại; nếu khiếu nại loại A thì xử lý theo quy trình A, loại B thì quy trình B, được phân loại ngay khi nhận." Hỏi: nên dùng Exclusive Gateway hay Event-based Gateway? Giải thích tại sao. (Gợi ý: "được phân loại ngay khi nhận" nghĩa là dữ liệu đã có sẵn — đây là chìa khóa của câu trả lời.)
Bài tập 4 — Tìm lỗi. Một đồng nghiệp vẽ: Event-based Gateway → nối thẳng tới ba task "Xác nhận", "Hủy", "Hết hạn", mỗi sequence flow có một condition expression. Hãy chỉ ra hai lỗi trong mô hình này và đề xuất cách sửa.
Tóm tắt
Bài 17 trang bị cho bạn hai gateway nâng cao quan trọng:
- Event-based Gateway (ngũ giác trong hình thoi) là cổng "đợi và đua". Token dừng lại và lắng nghe nhiều sự kiện cùng lúc; sự kiện nào đến trước sẽ thắng và các nhánh còn lại bị hủy — một race condition thuần túy. Mỗi nhánh phải bắt đầu bằng Catch Event hoặc Receive Task, không mang condition trên sequence flow, và gần như luôn cần một nhánh timer làm lối thoát. Đây là công cụ không thể thiếu cho mọi quy trình có chờ đợi, timeout, hay phản hồi từ bên ngoài — như chờ thanh toán Tiki, ghép chuyến Grab, giữ phòng khách sạn.
- Complex Gateway (dấu hoa thị trong hình thoi) dành cho logic gộp/tách phi chuẩn mà XOR, AND, OR không diễn đạt nổi — điển hình là ngưỡng "M trên N" (như "3 trên 5 thành viên hội đồng phê duyệt"). Nó mạnh nhưng "mờ"; hãy coi nó là lựa chọn cuối cùng, luôn kèm activation condition và Text Annotation rõ ràng.