Bài 31 — Camunda Platform — Engine và Modeler

Mở đầu — vì sao bài này quan trọng

Trong suốt 30 bài trước, bạn đã học cách tư duy về quy trình, vẽ BPMN 2.0 đúng chuẩn, tối ưu hóa và quản trị nó. Nhưng có một sự thật mà ít người nói thẳng với học viên: một sơ đồ BPMN dù đẹp đến đâu, nếu chỉ nằm yên trong file PDF hay trên tường phòng họp, thì nó vẫn chỉ là một bức tranh chết. Giá trị thật sự bùng nổ khi sơ đồ đó được "thổi hồn" — tức là một phần mềm có thể đọc đúng cái file bạn vẽ, rồi tự động điều phối công việc giữa con người và hệ thống theo đúng từng node, từng gateway, từng event bạn đặt vào.

Camunda chính là một trong những nền tảng làm được điều thần kỳ đó, và là cái tên được nhắc đến nhiều nhất khi người ta nói về "BPMN có thể chạy được" (executable BPMN). Đây là lý do tôi muốn dành riêng Bài 31 để mổ xẻ hai trái tim của Camunda: Modeler (công cụ vẽ) và Engine (động cơ thực thi). Hiểu rõ hai thành phần này, bạn sẽ thấy ranh giới giữa "người vẽ quy trình" và "người triển khai quy trình tự động hóa" mỏng hơn bạn tưởng — và đó chính là bước nhảy nghề nghiệp mà rất nhiều Business Process Analyst tại Việt Nam đang khao khát.

Khác với các công cụ chỉ để vẽ minh họa (mà chúng ta sẽ bàn ở các bài sau như Bizagi, draw.io), Camunda đưa bạn vào thế giới nơi sơ đồ và phần mềm là một. Hãy bắt đầu.

Khái niệm cốt lõi

Camunda là gì và triết lý "developer-friendly"

Camunda là một nền tảng quản lý quy trình nghiệp vụ (BPM platform) có nguồn gốc từ Đức, ra đời từ một công ty tư vấn BPM trước khi tách ra thành sản phẩm độc lập năm 2013. Triết lý cốt lõi của Camunda khác biệt rõ rệt: thay vì xây một bộ công cụ "no-code" khép kín, Camunda chọn con đường developer-first — nghĩa là nó được thiết kế để lập trình viên và nhà phân tích nghiệp vụ cùng làm việc trên một ngôn ngữ chung là BPMN 2.0 chuẩn, không bị "phương ngữ hóa".

Điểm mấu chốt bạn cần nhớ: file BPMN mà Camunda Modeler xuất ra là chuẩn XML BPMN 2.0 (đúng như Bài 27 trong dàn bài này sẽ đào sâu về XML serialization). Engine của Camunda đọc trực tiếp file XML đó và thực thi nó. Không có bước "biên dịch" sang một định dạng độc quyền nào ở giữa. Đây là cam kết "what you model is what you execute" — cái bạn vẽ chính là cái sẽ chạy.

Camunda Modeler — công cụ vẽ desktop

Camunda Modeler là một ứng dụng desktop miễn phí, chạy trên cả Windows, macOS và Linux. Nó được xây trên nền Electron (cùng công nghệ với VS Code, Slack), nên giao diện nhẹ và quen thuộc. Nhiệm vụ của nó:

• Vẽ sơ đồ BPMN 2.0 cho quy trình.
• Vẽ bảng quyết định DMN (Decision Model and Notation — sẽ học kỹ ở Bài 28).
• Vẽ form đơn giản (Camunda Forms) để gắn vào các User Task.

Điểm khiến Modeler đặc biệt so với một công cụ vẽ thông thường là panel thuộc tính (Properties Panel) bên phải màn hình. Khi bạn click vào một Task, một Gateway hay một Event, panel này cho phép bạn nhập các thuộc tính kỹ thuật mà Engine cần để chạy: ví dụ tên biến (variable), điều kiện rẽ nhánh (condition expression viết bằng FEEL hoặc JUEXL), loại implementation của Service Task (gọi job worker hay external task), người được giao việc (assignee, candidate group)... Đây chính là nơi sơ đồ "vô tri" biến thành sơ đồ "có thể thực thi".

Camunda Engine — động cơ thực thi BPMN

Camunda Engine là phần lõi, viết bằng Java. Nhiệm vụ của nó là đọc file BPMN, tạo ra các process instance (thể hiện cụ thể của một quy trình — ví dụ "đơn xin nghỉ phép của anh Nam ngày 5/6"), rồi điều phối các token đi qua từng node theo đúng token semantics (mô hình mà Bài 26 sẽ giảng). Engine lo những việc nặng nhọc: lưu trạng thái vào database, quản lý hàng đợi công việc cho con người, gọi API ra hệ thống ngoài, xử lý timer, retry khi lỗi, transaction...

Một điều quan trọng về kiến trúc: có hai thế hệ Engine mà bạn cần phân biệt rõ khi đi làm thực tế:

1. Camunda 7 (Camunda Platform 7): Đây là thế hệ "kinh điển", một Engine Java có thể nhúng (embed) thẳng vào ứng dụng Spring Boot của bạn chỉ bằng một dependency Maven. Tức là Engine chạy ngay trong cùng tiến trình (process) với ứng dụng của bạn, dùng chung database. Đây là kiến trúc cực kỳ quen thuộc với lập trình viên Java Việt Nam vì nó tích hợp mượt mà với hệ sinh thái Spring. Camunda 7 là mã nguồn mở (Apache 2.0) cho phiên bản Community.

2. Camunda 8 (Camunda Platform 8): Thế hệ mới, kiến trúc lại hoàn toàn theo hướng cloud-native, phân tán. Lõi của nó là một engine tên Zeebe — được thiết kế để xử lý hàng triệu process instance, không còn dựa vào database quan hệ truyền thống mà dùng event streaming. Camunda 8 hướng tới microservices và quy mô doanh nghiệp lớn (phần này liên quan đến Bài 53 về microservices orchestration). Lưu ý: Camunda 8 chủ yếu là mô hình thương mại (SaaS hoặc Self-Managed có license), khác với tinh thần "embed tự do" của Camunda 7.

Trong khuôn khổ bài này, khi nói "Engine nhúng Spring Boot", tôi đang nói chủ yếu về Camunda 7 — vì đó là cách dễ tiếp cận nhất để bạn tự tay chạy một process đầu tiên.

Hệ sinh thái xung quanh

Ngoài Modeler và Engine, Camunda còn có vài thành phần bạn nên biết tên để khỏi bỡ ngỡ:

• Tasklist: giao diện web để người dùng cuối thấy danh sách công việc (User Task) được giao cho mình và xử lý chúng.
• Cockpit (Camunda 7) / Operate (Camunda 8): giao diện vận hành để admin theo dõi process instance nào đang chạy, đang kẹt ở đâu, instance nào lỗi.
• Optimize: công cụ phân tích báo cáo, đo cycle time, tìm bottleneck (kết nối tới Bài 35, 46 trong dàn bài).

Tình huống thực tế

Ví dụ 1 — Công ty fintech "MoMoPay-giả định" tự động hóa quy trình duyệt khoản vay

Một công ty fintech tại TP.HCM (gọi tạm là VayNhanh, 120 nhân sự) có quy trình duyệt khoản vay tiêu dùng nhỏ. Trước đây, mỗi hồ sơ vay đi qua một chuỗi Google Sheet và email thủ công: nhân viên thẩm định nhập liệu, gửi email cho trưởng nhóm duyệt, rồi forward sang bộ phận giải ngân. Trung bình một hồ sơ mất 2,5 ngày, và 8% hồ sơ bị "rơi" vì email lạc giữa chừng.

Đội kỹ thuật quyết định dùng Camunda 7 nhúng vào Spring Boot. Họ vẽ quy trình trong Camunda Modeler: Start Event → Service Task (gọi API chấm điểm tín dụng) → Exclusive Gateway (điểm ≥ 600 thì auto-approve, < 600 thì sang User Task duyệt tay) → User Task "Trưởng nhóm duyệt" → Service Task (gọi API giải ngân) → End Event. Toàn bộ file BPMN này được đặt thẳng trong thư mục resources/bpmn của ứng dụng Spring Boot, và Engine tự deploy khi khởi động.

Kết quả sau 3 tháng: thời gian xử lý trung bình giảm từ 2,5 ngày xuống còn 6 giờ, tỷ lệ hồ sơ "rơi" về 0% vì mọi instance đều được Engine lưu trạng thái trong database, không thể biến mất. Bài học rút ra: sức mạnh thật của Camunda không phải ở sơ đồ đẹp, mà ở chỗ Engine đảm bảo không một quy trình nào bị bỏ rơi — đây là điều email và Excel không bao giờ làm được.

Ví dụ 2 — Ngân hàng "giả định" và bài học chọn Engine version

Một ngân hàng cỡ trung tại Hà Nội muốn tự động hóa quy trình mở tài khoản doanh nghiệp (onboarding KYC). Họ ước tính cao điểm có thể đạt 50.000 hồ sơ/ngày trong mùa cao điểm, và quy trình cần tích hợp với hơn 12 hệ thống lõi khác nhau qua microservices.

Ban đầu đội IT định dùng Camunda 7 nhúng cho nhanh. Nhưng kiến trúc sư hệ thống cảnh báo: với khối lượng instance lớn và yêu cầu mở rộng ngang (horizontal scaling) qua nhiều node, Camunda 7 với database quan hệ chung sẽ trở thành điểm nghẽn. Họ chuyển sang Camunda 8 với Zeebe — engine phân tán xử lý theo event stream, mỗi microservice đăng ký làm một job worker lắng nghe loại task của mình.

Bài học rút ra: Việc chọn Camunda 7 hay 8 không phải chuyện "phiên bản nào mới hơn thì tốt hơn". Camunda 7 nhúng cực kỳ phù hợp cho ứng dụng vừa và nhỏ, đội ngũ Java/Spring, triển khai nhanh. Camunda 8/Zeebe dành cho bài toán quy mô lớn, phân tán, microservices. Chọn sai version có thể khiến dự án hoặc bị over-engineering (8 cho bài toán nhỏ), hoặc bị nghẽn cổ chai (7 cho bài toán siêu lớn).

Ví dụ 3 — Startup logistics và sức mạnh của "vẽ là chạy"

Một startup logistics ở Đông Nam Á (đặt tên là GiaoTocDo, ~40 người) cần một quy trình điều phối đơn giao hàng có nhiều tình huống ngoại lệ: khách không nghe máy, đổi địa chỉ, hoàn hàng. Người vẽ quy trình là một Business Process Analyst — không phải lập trình viên giỏi — nhưng nhờ Properties Panel của Modeler, cô ấy tự cấu hình được các điều kiện rẽ nhánh và timer escalation (liên quan Bài 42) ngay trên sơ đồ. Lập trình viên chỉ cần viết code cho các Service Task (gọi API SMS, gọi API bản đồ).

Sự phân chia công việc này khiến vòng lặp chỉnh sửa quy trình rút ngắn đáng kể: khi nghiệp vụ thay đổi (ví dụ thêm bước gọi điện xác nhận trước khi giao), BPA tự sửa sơ đồ, redeploy, và quy trình mới chạy ngay — không cần build lại toàn bộ hệ thống cho những thay đổi luồng. Bài học rút ra: Camunda tạo ra một "ngôn ngữ chung" cho cả BPA và developer, giúp giảm khoảng cách giao tiếp vốn là nguyên nhân số một làm chậm các dự án tự động hóa quy trình.

Hướng dẫn từng bước

Đây là lộ trình thực hành để bạn tự chạy process BPMN đầu tiên với Camunda 7 + Spring Boot (cách dễ tiếp cận nhất cho người mới):

• Cài Camunda Modeler. Tải bản miễn phí từ trang chính thức của Camunda, giải nén và chạy. Không cần cài đặt phức tạp, không cần tài khoản.

• Tạo file BPMN mới. Trong Modeler, chọn "New BPMN Diagram". Bạn sẽ thấy canvas trắng với một Start Event sẵn có.

• Vẽ một quy trình tối giản. Kéo thả: Start Event → một User Task (đặt tên "Phê duyệt đơn") → End Event. Nối chúng bằng sequence flow. Đây là quy trình "Hello World" của BPM.

• Cấu hình thuộc tính kỹ thuật. Click vào toàn bộ sơ đồ (vùng trống), tìm ô Process Id trong Properties Panel, đặt một id rõ ràng như quy-trinh-duyet-don và bật cờ Executable. Cờ này cực kỳ quan trọng — nếu không bật, Engine sẽ bỏ qua process khi deploy.

• Gán người xử lý cho User Task. Click vào User Task, trong Properties Panel nhập Assignee (ví dụ demo) hoặc Candidate Groups. Đây là cách Engine biết đẩy việc này vào Tasklist của ai.

• Tạo dự án Spring Boot. Dùng Spring Initializr, thêm dependency camunda-bpm-spring-boot-starter (và camunda-bpm-spring-boot-starter-webapp nếu muốn có sẵn Cockpit/Tasklist). Thêm một database — để thử nghiệm, H2 in-memory là đủ.

• Đặt file BPMN vào đúng chỗ. Copy file .bpmn vừa vẽ vào thư mục src/main/resources (hoặc resources/bpmn). Khi ứng dụng khởi động, Camunda tự động deploy mọi file BPMN tìm thấy ở đây.

• Chạy ứng dụng và kiểm chứng. Khởi động Spring Boot. Mở trình duyệt vào localhost:8080, đăng nhập (mặc định demo/demo), vào Cockpit để thấy process đã deploy, và Tasklist để khởi tạo một instance mới rồi xử lý task. Chúc mừng — bạn vừa chạy một quy trình BPMN thật sự, không phải bản vẽ.

• Lặp lại vòng cải tiến. Sửa sơ đồ trong Modeler → copy đè file → restart ứng dụng → kiểm tra lại. Đây là nhịp làm việc cơ bản của một process automation engineer.

Lỗi thường gặp & mẹo

• Quên bật cờ "Executable". Đây là lỗi kinh điển của người mới. Bạn deploy thành công nhưng không thấy process đâu cả. Nguyên nhân: process chưa được đánh dấu executable nên Engine cố tình bỏ qua. Luôn kiểm tra ô này đầu tiên khi process "mất tích".

• Nhầm lẫn Camunda 7 và Camunda 8. Hai thế hệ có cách cấu hình, cú pháp biểu thức (expression) và mô hình triển khai khác nhau khá nhiều (ví dụ Camunda 7 hay dùng JUEXL/Spring EL, Camunda 8 dùng FEEL). Khi tra tài liệu trên mạng, luôn xác định rõ bạn đang đọc tài liệu cho version nào, kẻo copy nhầm cấu hình không chạy.

• Lạm dụng Service Task để nhồi logic phức tạp. Camunda mạnh ở điều phối (orchestration), không phải là nơi để viết toàn bộ business logic. Hãy giữ sơ đồ sạch sẽ, đẩy logic nặng vào service code, và dùng DMN cho các quyết định phức tạp thay vì nhồi 20 nhánh Exclusive Gateway.

• Mẹo — dùng External Task khi không thể nhúng Java. Nếu hệ thống của bạn viết bằng Python, Node.js, .NET... bạn vẫn dùng được Camunda qua mô hình External Task: Engine "treo" task lên, và worker viết bằng bất kỳ ngôn ngữ nào lấy task về xử lý qua REST API. Đây là cầu nối cho team đa ngôn ngữ.

• Mẹo — version hóa file BPMN. Coi file .bpmn như mã nguồn: đưa vào Git, review qua pull request. Vì nó là XML chuẩn, việc diff và quản lý phiên bản hoàn toàn khả thi và rất nên làm.

• Mẹo — đặt Process Id và Task Id có ý nghĩa. Engine và log dùng các id này. Đặt id kiểu Task_0x9a1b (mặc định) sẽ khiến bạn khốn khổ khi debug. Hãy đổi thành tên gợi nhớ.

Bài tập thực hành

• Cài và vẽ: Tải Camunda Modeler, vẽ quy trình "Đăng ký nghỉ phép" gồm: Start → User Task "Nhân viên gửi đơn" → Exclusive Gateway (số ngày ≤ 2 thì trưởng nhóm duyệt, > 2 thì giám đốc duyệt) → 2 nhánh User Task tương ứng → End. Nhớ bật cờ Executable và đặt id có nghĩa.

• Phân biệt kiến trúc: Viết ra một đoạn ngắn (5–7 câu) giải thích bằng lời của bạn: trong tình huống nào bạn sẽ chọn Camunda 7 nhúng Spring Boot, và tình huống nào bạn chọn Camunda 8/Zeebe? Dùng một ví dụ doanh nghiệp Việt Nam cụ thể cho mỗi lựa chọn.

• Chạy thử (nâng cao): Nếu bạn biết chút Java/Spring, hãy dựng một dự án Spring Boot với camunda-bpm-spring-boot-starter, deploy file BPMN ở bài tập 1, và khởi tạo một instance qua Tasklist. Ghi lại các bước và screenshot màn hình Cockpit.

• Tư duy phản biện: Liệt kê 3 lý do tại sao "BPMN chạy được" (executable) lại có giá trị hơn "BPMN chỉ để minh họa". Liên hệ với một quy trình thủ công ở chính nơi bạn làm việc hoặc học tập.

Tóm tắt

Camunda là nền tảng BPM đưa BPMN 2.0 từ bản vẽ thành phần mềm thực thi được, với hai trái tim: Modeler — công cụ desktop miễn phí đa nền tảng để vẽ BPMN/DMN cùng panel thuộc tính kỹ thuật, và Engine — động cơ Java điều phối process instance qua từng node. Bạn cần phân biệt hai thế hệ: Camunda 7 nhúng thẳng vào Spring Boot, lý tưởng cho ứng dụng vừa và nhỏ với đội Java; và Camunda 8/Zeebe kiến trúc cloud-native phân tán cho quy mô lớn và microservices. Triết lý xuyên suốt là "what you model is what you execute" — cái bạn vẽ chính là cái sẽ chạy, vì Engine đọc trực tiếp file XML BPMN chuẩn. Quanh hai thành phần lõi là Tasklist, Cockpit/Operate và Optimize lo phần giao việc, vận hành và phân tích.

Điều quan trọng nhất cần mang theo: giá trị của Camunda không nằm ở sơ đồ đẹp, mà ở chỗ Engine đảm bảo không quy trình nào bị bỏ rơi, mọi trạng thái đều được lưu, và BPA cùng developer làm việc trên một ngôn ngữ chung. Khi bạn nắm được điều này, bạn đã đặt một chân vào nghề process automation — bước nhảy nghề nghiệp mà chúng ta sẽ tiếp tục soi sáng ở các bài kế tiếp về Bizagi, Signavio và simulation.