Tích hợp DMN vào BPMN

1. Tổng quan Luồng Tích hợp từ Đầu đến Cuối

Cách tốt nhất để củng cố kiến thức là xem toàn bộ quá trình tích hợp diễn ra trong thực tế. Video hướng dẫn sau đây từ Camunda sẽ dẫn dắt bạn qua một ví dụ hoàn chỉnh: xây dựng một quy trình BPMN để gọi bảng quyết định DMN mà chúng ta đã làm quen.

Sau khi xem video, bạn có thể thấy một chu trình hoàn chỉnh và khép kín:

• Thiết kế: Bạn tạo các tệp .bpmn và .dmn một cách độc lập trong Camunda Modeler.
• Liên kết: Trong tệp .bpmn, bạn sử dụng Business Rule Task và trỏ đến ID của quyết định DMN (Decision Ref).
• Triển khai (Deploy): Cả hai tệp được deploy lên Camunda Engine. Chúng trở thành các "định nghĩa" (process definition và decision definition) sẵn sàng để được thực thi.
• Thực thi (Runtime): Khi một process instance chạy đến Business Rule Task, engine sẽ:
  1. Tìm decision definition tương ứng với Decision Ref.
  2. Lấy các process variables hiện tại làm đầu vào cho DMN.
  3. Thực thi DMN và trả về kết quả.
  4. Lưu kết quả đó vào một process variable mới (Result Variable).
  5. Tiếp tục chạy quy trình.

Với nền tảng là một developer, bạn có thể hình dung việc này tương tự như việc một service gọi đến một service khác thông qua một API đã được định nghĩa rõ ràng. Ở đây, BPMN là service "gọi", và DMN là service "được gọi", với Decision Ref đóng vai trò như endpoint và các biến là payload.

2. Các Mẫu Thiết kế (Design Patterns) Tích hợp BPMN và DMN

Biết cách kết nối là một chuyện, nhưng sử dụng kết nối đó một cách hiệu quả để tạo ra các thiết kế linh hoạt và dễ bảo trì mới là điều quan trọng. Dưới đây là hai mẫu thiết kế cực kỳ phổ biến.

Mẫu 1: Dùng DMN để Điều khiển Luồng Quy trình (DMN-driven Routing)

Đây là trường hợp sử dụng phổ biến nhất. Thay vì đặt các biểu thức logic phức tạp lên các nhánh của Gateway, bạn đẩy toàn bộ logic đó vào một bảng DMN.

Hãy xem sơ đồ quy trình sau:

Trong ví dụ này:

1. Decide Dish là một Business Rule Task gọi đến một bảng DMN. Bảng DMN này có thể dựa trên nhiều yếu tố đầu vào (ví dụ: season, numberOfGuests, dietaryPreference) để quyết định món ăn phù hợp.
2. Kết quả của DMN (ví dụ: desiredDish = "Steak") được lưu vào một biến quy trình.
3. Exclusive Gateway tiếp theo chỉ đơn giản là kiểm tra giá trị của biến desiredDish để định tuyến quy trình đến tác vụ chuẩn bị chính xác (Prepare Steak).

Lợi ích:

• Rõ ràng: Sơ đồ BPMN trở nên rất gọn gàng và dễ đọc, chỉ thể hiện các bước chính của quy trình.
• Linh hoạt: Nếu logic quyết định món ăn thay đổi (ví dụ: mùa đông thì ưu tiên món hầm), bạn chỉ cần cập nhật bảng DMN mà không cần chạm vào sơ đồ BPMN. Điều này giúp tách biệt "luồng quy trình" khỏi "logic nghiệp vụ".

Mẫu 2: Dùng DMN để Phân công Tác vụ (DMN-driven Task Assignment)

Một câu hỏi thường gặp trong các quy trình nghiệp vụ là: "Ai sẽ là người thực hiện tác vụ này?". Logic phân công có thể rất phức tạp, ví dụ: "Nếu yêu cầu vay dưới 100 triệu, nhân viên tín dụng có thể duyệt. Nếu từ 100 triệu đến 500 triệu, cần trưởng phòng tín dụng. Nếu trên 500 triệu và khách hàng là VIP, cần giám đốc chi nhánh."

Việc mã hóa logic này trực tiếp vào quy trình là không lý tưởng. Thay vào đó, chúng ta có thể dùng DMN.

Như bạn đã tìm hiểu trong bài viết ở bài học trước (Camunda BPM: User Task Assignment based on a DMN Decision...), một bảng DMN có thể nhận các biến quy trình (như amount, customerType) và có các cột output là assignee, candidateUsers, hoặc candidateGroups.

Sau đó, Business Rule Task sẽ thực thi DMN và trả về người/nhóm phù hợp. Tác vụ User Task tiếp theo sẽ sử dụng các biến kết quả này trong thuộc tính Assignee hoặc Candidate Groups của nó.

Lợi ích:

• Dễ quản lý: Toàn bộ ma trận phân quyền được quản lý tập trung tại bảng DMN, rất trực quan cho cả người nghiệp vụ và kỹ thuật.
• Giảm thiểu code: Bạn không cần viết các lớp Java hay script phức tạp để xử lý việc phân công.

3. Cấu hình Business Rule Task: Tóm tắt các Thuộc tính

Để củng cố lại các bước cấu hình, hãy xem lại các thuộc tính chính của một Business Rule Task khi tích hợp với DMN.

Tóm lại, 4 thuộc tính cốt lõi bạn cần nắm vững là:

1. Implementation: Phải được đặt là DMN để chỉ cho engine biết rằng tác vụ này sẽ thực thi một quyết định DMN. Các lựa chọn khác như Java Delegate hay External dùng cho các loại Service Task khác mà chúng ta đã học.
2. Decision Ref: ID duy nhất của bảng quyết định (được định nghĩa trong thuộc tính ID của decision trong tệp DMN). Đây là "địa chỉ" để engine tìm đến đúng bảng quyết định.
3. Result Variable: Tên của biến quy trình sẽ được tạo để lưu trữ kết quả trả về từ DMN.
4. Map Decision Result: Cách thức engine ánh xạ kết quả DMN vào Result Variable, tùy thuộc vào Hit Policy và số cột output (singleEntry, singleResult, resultList, v.v.).

Tổng kết

Qua bài học này, bạn đã đi từ việc hiểu cơ chế đến việc áp dụng nó vào một quy trình hoàn chỉnh. Việc tích hợp BPMN và DMN không chỉ là một tính năng kỹ thuật, mà còn là một phương pháp thiết kế mạnh mẽ giúp tạo ra các hệ thống linh hoạt và dễ bảo trì.

Những điểm chính cần ghi nhớ:

• Luồng tích hợp hoàn chỉnh bao gồm các bước: Thiết kế -> Liên kết -> Triển khai -> Thực thi.
• Sử dụng DMN để điều khiển luồng quy trình qua các Gateway giúp giữ cho sơ đồ BPMN đơn giản và tập trung vào luồng chính.
• Sử dụng DMN để quản lý logic phân công tác vụ giúp tập trung hóa và minh bạch hóa các quy tắc phân quyền.
• Việc tách biệt quy trình (BPMN) và quyết định (DMN) là một best practice quan trọng trong kiến trúc hệ thống BPM.

Xem trước bài học tiếp theo

Bây giờ bạn đã biết cách xây dựng và tích hợp các quyết định DMN. Nhưng làm thế nào để đảm bảo chúng hoạt động đúng như mong đợi? Trong bài học tiếp theo, "Kiểm thử và debug các quyết định DMN một cách độc lập", chúng ta sẽ tìm hiểu các kỹ thuật và công cụ để kiểm tra các bảng quyết định của bạn, cả khi chúng đứng một mình và khi chúng đã được tích hợp vào một quy trình lớn hơn. Đây là một kỹ năng thiết yếu để đảm bảo chất lượng và độ tin cậy cho các ứng dụng BPM của bạn.