Biến Đổi Quy Trình Thành Bảng Quyết Định và Đánh Giá Kết Quả

1. Business Rule Task: Cầu nối giữa BPMN và DMN

Trong BPMN, phần tử được thiết kế đặc biệt để thực thi các logic nghiệp vụ là Business Rule Task. Đây chính là công cụ chúng ta sẽ dùng để gọi bảng DMN đã tạo.

Một quy trình BPMN đơn giản với Start Event, Business Rule Task và End Event.

Khi một tiến trình (process instance) đi đến Business Rule Task, Camunda Engine sẽ tạm dừng, tìm đến bảng DMN được chỉ định, thực thi nó với các dữ liệu hiện có, và sau đó tiếp tục quy trình với kết quả nhận được.

Hãy xem một ví dụ thực tế về cách thiết lập kết nối này. Video sau đây sẽ hướng dẫn bạn cách tạo một quy trình BPMN, thêm Business Rule Task, và cấu hình nó để gọi bảng DMN mà chúng ta đã tạo ở các bài học trước.

2. Thiết lập Kết nối và Luồng Dữ liệu

Sau khi xem video, hãy cùng phân tích các bước cấu hình quan trọng để dữ liệu có thể lưu thông giữa BPMN và DMN.

a. Truyền dữ liệu VÀO DMN (Input)

Cơ chế mặc định của Camunda rất tiện lợi: Tất cả các biến quy trình (process variables) hiện có sẽ tự động được cung cấp cho DMN engine khi nó được gọi.

Điều này có nghĩa là, nếu bảng DMN của bạn có một cột đầu vào với Input Expression là customerType, Camunda sẽ tự động tìm một biến quy trình tên là customerType và sử dụng giá trị của nó làm đầu vào cho DMN. Đây là lý do việc đặt tên nhất quán giữa các biến quy trình và biểu thức đầu vào của DMN là rất quan trọng để việc tích hợp diễn ra suôn sẻ.

b. Cấu hình để nhận dữ liệu RA (Output)

Phần này đòi hỏi chúng ta phải cấu hình rõ ràng trong Camunda Modeler, như bạn đã thấy trong video. Hãy chọn Business Rule Task và nhìn vào tab General trong Properties Panel.

Các thuộc tính chính bạn cần quan tâm là:

• Implementation: Phải được chọn là DMN.
• Decision Ref: Đây là ID của bảng quyết định mà bạn muốn gọi. ID này được định nghĩa trong thuộc tính Id của chính bảng DMN. Đây là "chìa khóa" để Camunda biết phải gọi đúng bảng nào lúc thực thi.
• Result Variable: Tên của biến quy trình mới sẽ được tạo ra để lưu trữ kết quả từ DMN. Ví dụ: drink trong video, hoặc approvedAmount.
• Map Decision Result: Thuộc tính này cực kỳ quan trọng, nó cho Camunda biết cấu trúc dữ liệu của kết quả DMN và cách ánh xạ nó vào Result Variable.
  • singleEntry: Dùng khi DMN trả về một giá trị duy nhất (một ô). Ví dụ, Hit Policy là First và chỉ có một cột output. Kết quả sẽ là một giá trị đơn (String, Integer, v.v.).
  • singleResult: Dùng khi DMN trả về một hàng duy nhất, nhưng hàng đó có thể có nhiều cột output. Kết quả sẽ là một đối tượng Map<String, Object>, trong đó key là tên của cột output.
  • collectEntries: Dùng khi DMN trả về nhiều giá trị từ một cột output duy nhất (ví dụ, Hit Policy là Collect). Kết quả sẽ là một List<Object>.
  • resultList: Dùng khi DMN trả về nhiều hàng, mỗi hàng có thể có nhiều cột output. Đây là trường hợp phức tạp nhất, kết quả sẽ là một List<Map<String, Object>>.

3. Xem Dữ liệu Chảy trong Thực tế

Lý thuyết là vậy, nhưng cách tốt nhất để hiểu là quan sát nó hoạt động. Hãy tiếp tục với video và xem cách tác giả khởi chạy quy trình, cung cấp biến đầu vào và kiểm tra kết quả trả về.

Qua ví dụ trên, bạn đã thấy một luồng dữ liệu hoàn chỉnh:
Biến quy trình (input) → Business Rule Task → DMN Engine → Kết quả (output) → Biến quy trình mới.

4. Xử lý Kết quả Phức tạp: Output Mapping

Trường hợp trong video tương đối đơn giản: Hit Policy trả về một kết quả duy nhất. Nhưng nếu bạn dùng Hit Policy Collect và DMN trả về một danh sách các kết quả thì sao? Result Variable của bạn lúc này sẽ là một danh sách (ví dụ: List<Map<String, Object>>).

Là một developer, bạn sẽ thấy rằng việc xử lý cấu trúc dữ liệu này là cần thiết. Ví dụ, bạn có thể muốn trích xuất tất cả các candidateUsers từ danh sách kết quả để gán cho một User Task.

Camunda cung cấp một công cụ mạnh mẽ cho việc này ngay trên Business Rule Task: tab Input/Output. Tại đây, bạn có thể định nghĩa các Output Parameter để xử lý Result Variable và tạo ra các biến quy trình mới, có cấu trúc gọn gàng hơn.

Hãy xem một ví dụ thực tế từ bài viết của Camunda.

Trong bài viết, sau khi nhận được dmnResult là một danh sách, họ sử dụng script ngôn ngữ FEEL trong tab Output để trích xuất thông tin:

• Để lấy danh sách candidateUsers:
  (for r in dmnResult return get value(r, "candidateUsers"))[item != null]
• Để lấy assignee đầu tiên trong danh sách:
  ((for r in dmnResult return get value(r, "assignee"))[item != null])[1]

Đây là một kỹ thuật rất mạnh, cho phép bạn giữ cho DMN chỉ tập trung vào việc ra quyết định, còn việc xử lý, chuyển đổi dữ liệu kết quả sẽ do Business Rule Task đảm nhiệm.

Tổng kết

Trong bài học này, chúng ta đã kết nối thành công hai thế giới BPMN và DMN, tạo ra một luồng dữ liệu tự động giữa quy trình và logic nghiệp vụ.

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

• Sử dụng Business Rule Task trong BPMN để gọi một bảng DMN.
• Dữ liệu đầu vào được truyền tự động bằng cách khớp tên giữa biến quy trình và Input Expression của DMN.
• Cấu hình Decision Ref để chỉ định bảng DMN cần gọi.
• Sử dụng Result Variable để đặt tên cho biến lưu kết quả trả về.
• Chọn đúng Map Decision Result (singleEntry, resultList,...) để phù hợp với cấu trúc dữ liệu đầu ra của DMN (phụ thuộc vào Hit Policy và số cột output).
• Sử dụng tab Input/Output với các script (như FEEL) để xử lý và ánh xạ các kết quả phức tạp (dạng danh sách, đối tượng) thành các biến quy trình dễ sử dụng hơn.

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

Bây giờ bạn đã nắm vững cơ chế trao đổi dữ liệu. Trong bài học tiếp theo, "Tích hợp và gọi một quyết định DMN từ một quy trình BPMN", chúng ta sẽ củng cố lại kiến thức này bằng cách xem xét nó trong một bức tranh lớn hơn. Chúng ta sẽ xem xét các phương pháp hay nhất khi tích hợp, các cách triển khai khác nhau của Business Rule Task, và cách cấu trúc một dự án hoàn chỉnh có cả BPMN và DMN.