Nghiên cứu vấn đề nhiều phiên bản và ngoại lệ trong quy trình quản lý với SOA xử lý bó và xử lý ngoại lệ trong hệ thống quản lý quy trình

LỜI CAM ĐOAN Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình khác như đã ghi rõ trong luận văn, các công việc trình bày trong luận văn này là do chính tôi thực hiện

LÝ HOÀNG HẢI

Nghiên cứu vấn đề nhiều phiên bản và ngoại lệ trong quy trình quản lý với SOA

(XỬ LÝ BÓ VÀ XỬ LÝ NGOẠI LỆ TRONG HỆ THỐNG QUẢN LÝ QUY TRÌNH)

Chuyên ngành: Khoa học Máy tính

LUẬN VĂN THẠC SĨ

TRƯỜNG ĐẠI HỌC BÁCH KHOA ĐẠI HỌC QUỐC GIA TP HỒ CHÍ MINH

Cán bộ hướng dẫn khoa học : TS Đặng Trần Khánh

Cán bộ chấm nhận xét 1 :

Cán bộ chấm nhận xét 2 :

Luận văn thạc sĩ được bảo vệ tại

HỘI ĐỒNG CHẤM BẢO VỆ LUẬN VĂN THẠC SĨ

TRƯỜNG ĐẠI HỌC BÁCH KHOA, ngày tháng năm 2008

Tp HCM, ngày tháng năm 2008

NHIỆM VỤ LUẬN VĂN THẠC SĨ Họ và tên học viên : Lý Hoàng Hải Giới tính : Nam / Nữ  Ngày, tháng, năm sinh : 15/10/1982 Nơi sinh : Tp.HCM Chuyên ngành : Khoa học Máy tính

Khoá : 2006

1- TÊN ĐỀ TÀI :

Nghiên cứu vấn đề nhiều phiên bản và ngoại lệ trong quy trình quản lý với SOA (Xử lý bó và xử lý ngoại lệ trong hệ thống quản lý quy trình)

2- NHIỆM VỤ LUẬN VĂN :

3- NGÀY GIAO NHIỆM VỤ :

4- NGÀY HOÀN THÀNH NHIỆM VỤ :

5- HỌ VÀ TÊN CÁN BỘ HƯỚNG DẪN : TS Đặng Trần Khánh

Nội dung và đề cương Luận văn thạc sĩ đã được Hội Đồng Chuyên Ngành thông qua

CÁN BỘ HƯỚNG DẪN CHỦ NHIỆM BỘ MÔN

(Họ tên và chữ ký)

LỜI CAM ĐOAN

Tôi cam đoan rằng, ngoại trừ các kết quả tham khảo từ các công trình

khác như đã ghi rõ trong luận văn, các công việc trình bày trong luận văn này là

do chính tôi thực hiện và chưa có phần nội dung nào của luận văn này được nộp

để lấy một bằng cấp ở trường này hoặc trường khác

Ngày 1 tháng 7 năm 2008

LỜI CẢM ƠN

Tôi xin gởi lời cảm ơn chân thành và sâu sắc nhất đến TS Đặng Trần Khánh đã tận tình hướng dẫn tôi và tạo mọi điều kiện để tôi có thể hoàn thành luận văn này

Tôi cũng xin cảm ơn gia đình đã động viên và tạo mọi điều kiện tốt nhất

để tôi có thể tiếp tục theo đuổi việc học tập nghiên cứu Tôi trân trọng dành tặng thành quả của luận văn này cho Cha Mẹ Nhờ công lao dưỡng dục của Người mà con mới có được thành quả như ngày hôm nay Con xin hứa sẽ tiếp tục cố gắng phấn đấu để vươn cao hơn nữa

ABSTRACT

Nowadays, in order to improve the efficiency and avoid mistakes, organizations and enterprises are trying to establish and to standardize their business processes In that context, workflow management systems have been applied popularly Those are software systems which support the management, monitoring and coordination of activity automatically or semi-automatically However, the state-ot-the-art architectures do not consider well enough about batch processing The systems do not concern about the jobs within each workflow instance Therefore, they cannot automatically merge jobs in order to improve the efficiency of the execution In this thesis, we propose a framework for the workflow management system in which the jobs information are managed directly by the system We point out components which should be changed/added in to the system Besides, we also propose a solution of merging

jobs to improve the efficiency of the execution

TÓM TẮT LUẬN VĂN

Hiện nay, nhằm tăng tính hiệu quả công việc và giảm thiểu các sai sót, các tổ chức cũng như các đơn vị kinh doanh sản xuất đều cố gắng xác lập và chuNn hóa các quy trình nghiệp vụ của mình Trong thời gian gần đây, để các quy trình được tiến hành chặt chẽ, có kiểm soát, hệ thống quản lý quy trình đang từng bước áp dụng rộng rãi Đây là các hệ thống phần mềm giúp quản lý, giám sát và điều phối các hoạt động trong quy trình một cách tự động/bán tự động Tuy nhiên, kiến trúc hiện nay của các hệ thống quản lý quy trình chưa quan tâm đúng mức đến xử lý bó (batch processing) Hệ thống không quan tâm đến các thành phần công việc bên trong mỗi quy trình nên không thể tự động gom nhóm các công vịêc lại cho phù hợp nhằm tăng tính hiệu quả khi thực hiện Trong luận văn này, chúng tôi đề nghị một framework cho hệ thống quản lý quy trình trong đó hệ thống nắm giữ thông tin về các thành phần công việc trong quy trình Chúng tôi chỉ ra các thành phần cần phải

bổ sung vào kiến trúc của các hệ thống quản lý quy trình truyền thống N goài ra, chúng tôi minh họa một giải pháp gom nhóm các công việc nhằm tăng tính hiệu quả trong thực thi quy trình

XỬ LÝ BÓ TRONG HỆ THỐNG QUẢN LÝ QUY TRÌNH

MỤC LỤC

CHƯƠN G I MỘT SỐ KIẾN THỨC N ỀN TẢN G 1 

I.1 Một số thuật ngữ về quản lý quy trình và xử lý bó 3 

I.2 Tổng quan về định nghĩa, thực thi và thay đổi quy trình 6 

I.3 Toàn cảnh hệ thống hướng quy trình (workflow-based system) 7 

I.4 N goại lệ 9 

CHƯƠN G II TỔN G THUẬT CÁC N GHIÊN CỨU CÓ LIÊN QUAN 11 

II.1 Xử lý bó 11 

II.2 Xử lý ngoại lệ 14 

II.3 Framework các hệ thống quản lý quy trình 17 

CHƯƠN G III GIỚI THIỆU BÀI TOÁN 20 

CHƯƠN G IV GIẢI PHÁP XỬ LÝ BÓ TRON G WfMS 23 

IV.1 Mở rộng động cơ thực thi (Execution Engine) nhằm hỗ trợ xử lý bó 23 

IV.2 Meta Data hỗ trợ xử lý bó 28 

IV.3 Cơ chế xử lý ngoại lệ trong xử lý bó 33 

IV.4 Framework một hệ thống WfMS hỗ trợ xử lý bó và xử lý ngoại lệ 34 

CHƯƠN G V SỬ DỤN G DỰ BÁO ĐỂ TĂN G TÍN H HIỆU QUẢ TRON G XỬ LÝ BÓ 45 

V.1 Dự đoán thời gian thực thi của hoạt động trong quy trình 46 

V.2 Dự đoán thời điểm sớm nhất WF instance đạt đến một hoạt động 48 

V.3 Các chính sách gom nhóm công việc 57 

CHƯƠN G VI TỔN G KẾT VÀ HƯỚN G PHÁT TRIỂN 73 

PHỤ LỤC 1: TÀI LIỆU THAM KHẢO 74 

XỬ LÝ BÓ TRONG HỆ THỐNG QUẢN LÝ QUY TRÌNH

DANH MỤC HÌNH

Hình 1 Quy trình mua sắp thiết bị 3 

Hình 2 Định nghĩa & Thực thi quy trình 6 

Hình 3 Thay đổi quy trình 7 

Hình 4 Workflow-based system 7 

Hình 5 Quy trình cho thuê xe 11 

Hình 6 Hàng đợi công việc 12 

Hình 7 Các dạng xử lý bó 13 

Hình 8 Mô hình tham chiếu WfMS 17 

Hình 9 Framework hỗ trợ adaptive workflow[25] 19 

Hình 10 Quy trình xử lý học vụ 20 

Hình 11 Cơ chế thực thi với token 24 

Hình 12 Biến dữ liệu toàn cục 25 

Hình 13 Token chứa batch data 27 

Hình 14 Activity N otation 29 

Hình 15 Xử lý bó và XOR-SPLIT 29 

Hình 17 Sử dụng B-JOIN 30 

Hình 16 B-Join N otation 30 

Hình 18 B-JOIN có deadline 31 

Hình 19 B-JOIN với false token 31 

Hình 20 B-JOIN nhiều workflow instance 32 

Hình 21 Framework hỗ trợ xử lý bó & xử lý ngoại lệ 34 

Hình 23 Cấu trúc một nơron 47 

Hình 22 Mạng nơron 3 lớp 47 

Hình 24 Hàm sigmoid 47 

Hình 25 Treach(X) 49 

Hình 27 Schema VD2 51 

Hình 28 Schema VD3 52 

Hình 29 Mã giã dự đoán thời gian thực thi 55 

Hình 30 AN D-JOIN 56 

Hình 31 Ví dụ gom nhóm công việc 58 

Hình 32 Gom nhóm công việc cùng WF instance 58 

Hình 33 Chính sách gom nhóm 62 

Hình 34 Mã giả Enable 63 

Hình 35 Dự đoán chính xác 65 

Hình 36 Dự đoán không chính xác 66 

Hình 37 Schema tuần tự 67 

Hình 38 Mô phỏng với chính sách 1 69 

Hình 39 Mô phỏng với chính sách 2 70 

Hình 40 Mô phỏng với chính sách 3 70 

Hình 41 Schema phức tạp 71 

XỬ LÝ BÓ TRONG HỆ THỐNG QUẢN LÝ QUY TRÌNH

Bảng 1 Kết quả mô phỏng schema tuần tự 71 

Bảng 2 Kết quả mô phỏng với schema phức tạp 72 

XỬ LÝ BÓ TRONG HỆ THỐNG QUẢN LÝ QUY TRÌNH CHƯƠNG I MỘT SỐ KIẾN THỨC NỀN TẢNG

gày nay, xây dựng quy trình và liên tục cải tiến quy trình là một hoạt động quan trọng trong các doanh nghiệp Thật vậy, thực tế hoạt động của các doanh nghiệp cho thấy nếu các quy trình nghiệp vụ được chuNn hóa, được định nghĩa một cách tường minh và được áp dụng đồng bộ trong toàn đơn vị, cũng như thường xuyên được rà soát, cải tiến thì sẽ giảm thiểu được rất nhiều các sai sót trong hoạt động và tăng đáng kể hiệu quả công việc Xây dựng và chuNn hóa quy trình hoạt động là chuNn mực trong việc hoàn chỉnh cơ cấu tổ chức và hoạt động của đơn

vị N hiều tiêu chuNn quản lý chất lượng như ISO, CMM đánh giá các doanh nghiệp chủ yếu dựa trên mức độ trưởng thành của của các quy trình nghiệp vụ tại doanh nghiệp đó Trong bối cảnh đó, hệ thống quản lý quy trình làm việc trở thành một công cụ hỗ trợ đắc lực cho các tổ chức, đặc biệt là các tổ chức có nhiều quy trình nghiệp vụ phức tạp như các cơ quan quản lý hành chính nhà nước, hoặc bộ máy quản lý hành chính của trường đại học Trong các đơn vị này, có rất nhiều quy trình nghiệp vụ Hơn nữa, các quy trình này trải rộng và ảnh hưởng đến nhiều cá nhân và phòng ban khác nhau Việc quản lý thực thi các quy trình này, nếu làm bằng tay, rất

dễ gây ra thiếu sót và gây ra những thời gian trễ trong chuyển tiếp công việc giữa các phòng ban N goài ra, tiến độ thực hiện các công việc cũng rất khó kiểm soát Do

đó, việc sử dụng các hệ thống quản lý quy trình để tự động hóa công việc ở đây có ý nghĩa rất lớn

Trong nhiều trường hợp, mỗi lần chạy của quy trình (workflow instance) không chỉ giải quyết cho một công việc đơn lẻ mà thường là giải quyết cho một nhóm các đối tượng đồng thời Việc xử lý đồng thời nhiều công việc như vậy ta gọi là xử lý

bó (batch processing) trong quy trình Thí dụ: Quy trình xử lý học vụ thực hiện tại đầu mỗi học kì của trường Bách Khoa không giải quyết cho một sinh viên đơn lẻ

mà giải quyết đồng thời cho nhiều sinh viên Tương tự trong quy trình đặt hàng, N

mỗi lần thực hiện sẽ xử lý cho nhiều đơn hàng Hơn thế nữa, đối với một số hoạt động trong quy trình, nếu ta xử lý bó thì sẽ tăng tính hiệu quả, giảm chi phí Thí dụ trong hoạt động đặt hàng từ nhà cung cấp, nếu ta gom được nhiều đơn hàng lại với nhau đặt hàng một lần thì sẽ được lợi Hoặc trong hoạt động kí duyệt, nếu ta gom lại nhiều công việc vào chung một danh sách thì người kí duyệt chỉ cần phải kí một lần

và quan trọng là chỉ tạo ra một văn bản duy nhất chứa tất cả các công việc thay vì nhiều văn bản Qua đó, chúng ta thấy việc WfMS hỗ trợ xử lý bó có ý nghĩa quan trọng Tuy nhiên, kiến trúc hiện nay của các hệ thống quản lý quy trình chưa quan tâm đúng mức đến xử lý bó (batch processing) Hệ thống không quan tâm đến các thành phần công việc bên trong mỗi quy trình nên không thể tự động gom nhóm các công vịêc lại cho phù hợp nhằm tăng tính hiệu quả khi thực hiện Trong bài báo này, chúng tôi đề nghị một framework cho hệ thống quản lý quy trình trong đó hệ thống nắm giữ thông tin về các thành phần công việc (job) trong quy trình Chúng tôi sẽ chỉ ra các thành phần cần phải bổ sung vào kiến trúc của các hệ thống quản lý quy trình truyền thống nhằm hỗ trợ xử lý bó N goài ra, chúng tôi cũng minh họa một giải pháp gom nhóm các công việc nhằm tăng tính hiệu quả trong thực thi quy trình

Phần còn lại của luận văn này được tổ chức như sau: phần I trình bày một số khái niệm và kiến thức nền tảng về quản lý quy trình bằng máy tính và xử lý bó trong quản lý quy trình; phần II tóm lược các công trình có liên quan đến đề tài mà chúng tôi đã tìm hiểu trong thời gian vừa qua; phần III đưa ra một framework có chứa các thành phần nhằm hỗ trợ xử lý bó và xử lý ngoại lệ; phần IV trình bày một minh họa

về gom nhóm các công việc nhằm tăng tính hiệu quả trong xử lý bó; phần V sẽ tóm lược lại nội dung và nêu lên một số hướng phát triển trong tương lai

I.1 Một số thuật ngữ về quản lý quy trình và xử lý bó

Trong phần này, chúng tôi sẽ giải thích một số thuật ngữ cơ bản được dùng trong phần còn lại của luận văn:

Quy trình (workflow hay viết tắt là WF) bao

gồm một chuỗi các hoạt động (activity) cần

thực hiện theo một thứ tự nhất định để hoàn

thành một công việc nào đó N ó hướng dẫn cho

các cá nhân tham gia vào quy trình biết công

việc cần phải làm Thí dụ quy trình mua mới tài

sản và thiết bị trong trường Bách Khoa (Hình

1) như sau: Quy trình bắt đầu với bước Quyết

định mua sắm thiết bị Sau khi có quyết định

mua sắm thiết bị, một trong hai bước Tổ chức

đấu thầu hay Xét chọn đơn vị cung cấp sẽ được

thực hiện tùy theo giá trị của gói thầu Sau đó,

trường sẽ làm việc với đơn vị cung cấp rồi thực

hiện bàn giao thiết bị và bước cuối cùng là làm

thủ tục thanh toán Khi thực hiện, mỗi bước

trong quy trình sẽ được thực hiện bởi một/một

số cá nhân trong đơn vị với một số tài nguyên

nhất định Mỗi bước trong quy trình có thể là một hoạt động cơ bản (activity) hay lại là một quy trình con Các bước trong quy trình có thể được làm tự động, bằng tay hoàn toàn hoặc có sự trợ giúp của các phần mềm máy tính

Hệ thống quản lý quy trình (WfMS – Workflow Management System) là hệ thống

thông tin hỗ trợ việc định nghĩa, thực thi, quản lý và giám sát các quy trình

Hình 1 Quy trình mua sắp thiết bị

Đặc tả workflow (workflow schema) chứa các thông tin mô tả về cách thực thi quy

trình dưới nhiều góc nhìn khác nhau [23] chia các thông tin này thành 5 loại như sau:

a) Dòng điều khiển (control flow): mô tả trình tự thực thi của các bước Các bước

có thể thực thi tuần tự hay song song hoặc lặp lại nhiều lần Một dạng biểu diễn thường gặp của dòng điều khiển là lưu đồ

b) Dòng chảy dữ liệu (data flow): mô tả thông tin trao đổi giữa các bước: output

của một step sẽ là input của step nào kế tiếp

c) Tài nguyên: mô tả các tài nguyên cần thiết để thực thi mỗi bước trong quy trình d) Thông tin hướng thời gian (temporal): mô tả các ràng buộc thời gian trong quy trình (thí dụ: thời gian thực thi mỗi bước, khoảng cách thời gian nghĩ tối thiểu giữa 2 bước liền kề, ….)

e) Thông tin Contigency: bao gồm các thông tin liên quan đến xử lý lỗi, ngoại lệ (thí dụ: bước nào trong quy trình có thể roll-back và dùng thao tác gì để roll-back, cách thay đổi quy trình khi một ngoại lệ xảy ra…)

Workflow meta data là ngôn ngữ dùng để định nghĩa workflow schema N ó bao

gồm một tập các kí hiệu tương ứng với nhiều ngữ nghĩa khác nhau Mỗi WfMS sẽ hiểu một meta data nào đó và người thiết kế quy trình phải dùng meta data đó để mô

tả các quy trình nghiệp vụ Một meta data mạnh sẽ giúp người thiết kế diễn đạt được một cách trong sáng các quy trình nghiệp vụ

Workflow Instance: Workflow schema chỉ mô tả thông tin về một quy trình Khi

cần áp dụng quy trình nào, WfMS sẽ tạo ra một workflow instance từ workflow schema của quy trình đó Quan hệ giữa workflow schema và workflow instance giống như quan hệ giữa class và object trong hướng đối tượng Thí dụ: ta sẽ có nhiều workflow instance mua thiết bị ứng với nhiều lần mua thiết bị khác nhau Các

động (activity) trong quy trình theo thứ tự đã được mô tả trong schema Việc thực

thi một activity trong một workflow instance nào đó sẽ tạo ra một activity instance

Workflow Agent (gọi tắt là Agent) là các ứng dụng thực thi/hỗ trợ người dụng

thực thi các hoạt động trong quy trình Các agent này có thể là một ứng dụng độc lập, một thư viện hay là một web service trong hệ thống xây dựng theo kiến trúc hướng dịch vụ (SOA) Thí dụ: agent là ứng dụng hỗ trợ người sử dụng kí vào các văn bản điện tử; agent là ứng dụng cho phép người sử dụng nhập vào thông tin của các đơn hàng

N hững người tham gia thực thi quy trình có thể phân thành 3 loại sau:

a) WF administrator: người chịu trách nhiệm quản lý quy trình WF administrator

định nghĩa quy trình bằng cách dùng các công cụ của WfMS để tạo ra một workflow schema mô tả quy trình WF administator là người yêu cầu WfMS tạo

ra các workflow instance để thực thi quy trình N goài ra, anh ta cũng là người chịu trách nhiệm thay đổi quy trình nhằm cải tiến nó hoặc đáp ứng với những ngoại lệ phát sinh trong quá trình thực thi quy trình

b) WF operator: người chịu trách nhiệm thực hiện trực tiếp các hoạt động trong

quy trình Các bước khác nhau có thể được thực hiện bởi các WF operator khác nhau Thí dụ: trong quy trình xử lý học vụ thì WF operator là giáo vụ khoa, ban chủ nhiệm khoa, thư kí

c) WF end-user: là người chịu ảnh hưởng từ kết quả của quy trình Thí dụ: trong

quy trình xử lý học vụ thì WF user là sinh viên bị xử lý học vụ WF user có nhiệm vụ cung cấp các thông tin đầu vào cho toàn bộ quy trình và nhận kết quả trả về từ quy trình

end-N goài ra, chúng ta còn có 2 thuật ngữ quan trọng liên quan đến xử lý bó:

- Job: một đối tượng công việc xử lý bởi quy trình

- Batch Processing: một workflow instance có thể xử lý đồng thời nhiều Job

Ta nói nó xử lý một batch gồm n job

Thí dụ xét hoạt động chuyển điểm dự thính của sinh viên vào bảng điểm chính thức Mỗi lần ứng dựng agent làm công việc chuyển điểm được thực thi thì nó sẽ nhận vào danh sách các sinh viên cần chuyển điểm và nó sẽ tiến hành chuyển điểm tự

động cho tất cả các sinh viên này Trong trường hợp này, batch là danh sách các sinh viên và job là từng sinh viên cần chuyển điểm

I.2 Tổng quan về định nghĩa, thực thi và thay đổi quy trình

Hình 2 mô tả quá trình định nghĩa và thực thi quy trình Đầu tiên WF administrator định nghĩa ra workflow schema (bước 1) Mỗi lần áp dụng quy trình,

WF administrator yêu cầu WfMS tạo ra một workflow instance (bước 2) Sau đó tại

bước 3, WfMS có nhiệm vụ căn cứ vào schema để tuần tự thực hiện các bước trong quy trình

WfMS sẽ lưu trữ thông tin về tiến độ thực thi của mỗi workflow instance Thông tin

này gọi là execution state của workflow instance WfMS căn cứ vào execution

state để xác định step kế tiếp sẽ thực thi ADEPT [19] quản lý execution state của workflow instance bằng cách đánh dấu trạng thái thực thi của mỗi bước ADEPT sử dụng 6 trạng thái khác nhau để đánh dấu trạng thái mỗi bước: not_activated (chưa

đủ điều kiện để thực thi), activated (đủ điều kiện để thực thi nhưng chưa thực thi), running (đang thực thi), completed (đã hoàn tất), failed (đã bị lỗi trong quá trình

Hình 2 Định nghĩa & Thực thi quy trình

Trong quá trình thực thi workflow instance, nếu có ngoại lệ phát sinh, WF administrator có thể thay đổi instance schema (bước 4) Lúc đó, workflow instance

sẽ trở thành biased

workflow instace N ó sẽ tiếp

tục được thực thi với schema mới không còn giống với schema gốc ban đầu

“Thay đổi instance schema” thực chất bao gồm 3 hoạt động như trong Hình 3 Đầu tiên, WF administrator sẽ mô tả thao tác thay đổi Bước thứ 2 là WfMS sẽ kiểm tra xem các thay đổi đó có thể thực hiện được với trạng thái hiện tại của workflow instance hay không Bước này gọi là kiểm tra tương thích (compliance checking) Việc có tương thích hay không là dựa trên điều kiện tương thích (compliance criteria) được quy định bởi WF adminitrator Thí dụ: điều kiện tương thích là các thao tác thay đổi không được phép tiến hành trên phần đã thực thi rồi

của workflow instance Trong trường hợp tương thích thì trong bước 3, execution

state của workflow instance sẽ được cập nhật để nó có thể tiếp tục thực thi với

schema mới Bước 3 này thường được gọi là migration Thay đổi động quy trình là một kỹ thuật quan trọng nhằm xử lý ngoại lệ Hiện nay, đã có nhiều kết quả nghiên cứu về vấn đề này Trong chương II, chúng tôi sẽ trình bày rõ hơn về giải pháp hiện tại để xử lý từng bước trong quy trình trên

quy trình Hình 4 Workflow-based system

Hình 3 Thay đổi quy trình

Trong các hệ thống này, phần lõi là module quản lý quy trình WfMS với một số chức năng cơ bản:

 WfMS cung cấp công cụ cho phép WF Administrator thiết kế worflow schema dựa trên một meta model nào đó

 WfMS cung cấp công cụ cho phép WF administrator chỉnh sửa lại các schema đã có cho phù hợp với những biến đổi trong quy trình nghiệp vụ hoặc xử lý các ngoại lệ

 Các phiên bản khác nhau của schema đựơc lưu trong một kho (repository) các schema WfMS có nhiệm vụ quản lý các phiên bản và chọn lựa sử dụng các phiên bản này theo một chính sách thống nhất

 WfMS cho phép WF administrator tạo ra workflow instance và quản lý sự thực thi của workflow instance

 WfMS cho phép WF administrator và WF end-user theo dõi tiến độ thực thi quy trình một cách trực quan Đây là một tính năng rất có ý nghĩa đối với các ứng dụng về quản lý hành chính như chính phủ điện tử

 …

Về mặt kiến trúc hệ thống, ta lưu ý là WfMS chỉ có nhiệm vụ quản lý quy trình chung, không có chức năng thực thi các bước trong quy trình Khi muốn thực thi

một bước nào đó thì WfMS sẽ chạy một ứng dụng (client) tương ứng với bước đó

N hững người cộng tác WF operator tham gia xử lý các bước trong quy trình sẽ làm

việc thông qua các agent, không tương tác trực tiếp lên WfMS Với thiết kế như vậy, ta tách rời công việc quản lý quy trình với công việc xử lý cụ thể các bước trong quy trình WfMS chỉ lo việc quản lý quy trình trong khi các agent xử lý các vấn đề nghiệp vụ của quy trình N hờ đó, ta có thể thiết kế WfMS tổng quát, áp dụng được cho các quy trình trong nhiều lĩnh vực

đơn bình thường Phần kế tiếp sẽ trình bày về kiến trúc hướng dịch vụ và áp dụng của nó trong quản lý quy trình

I.4 Ngoại lệ

Ngoại lệ ở đây được hiểu là những sự kiện, điều kiện, hoàn cảnh ngăn cản quy

trình hoàn thành một cách bình thường [25] N goại lệ tạo ra sự khác biệt (deviation) giữa kế hoạch (plan) và cái thực sự diễn ra

Ngoại lệ có thể là những lỗi phát sinh từ hạ tầng (infrastructure) hỗ trợ thực thi

quy trình Để thực thi thông suốt, hoàn tất quy trình, ta cần có sự hỗ trợ của WfMS

và các phần mềm xử lý các tác vụ từng bước trong quy trình N hư vậy việc thực thi thành công quy trình phụ thuộc rất nhiều thành phần như phần mềm WfMS, phần mềm xử lý tác vụ, phần cứng, mạng, DBMS, … N ếu bất kì các thành phần trên phát sinh lỗi thì đều phải có biện pháp khắc phục Biện pháp khắc phục có thể là tự động, bán tự động hoặc yêu cầu can thiệp trực tiếp từ con người Tuy nhiên, vấn đề quan trọng là hệ thống có thể phục hồi để tiếp tục thực thi từ trạng thái trước khi bị lỗi Quy trình nghiệp vụ thường không phải là một chương trình máy tính chạy tự động hoàn toàn mà cần có sự tham gia của con người ở nhiều mức độ khác nhau (thí dụ: con người ra các quyết định, kí duyệt các văn bản…) Việc thực thi lại từ đầu quy trình sẽ tạo ra nhiều vấn đề phức tạp Vì vậy WfMS phải có khả năng phát hiện và khắc phục các lỗi (tự động hoặc can thiệp của con người) và quan trọng là tiếp tục thực hiện quy trình chưa hoàn tất sau khi khắc phục lỗi

N goài ra, ngoại lệ cũng có thể hiểu là những tình huống cá biệt phát sinh trong

quá trình thực thi quy trình đòi hỏi phải có biện pháp xử lý riêng Thí dụ trong các quy trình về thủ tục hành chính, để thực thi một bước nào đó, theo quy định, người tham gia vào quy trình phải cung cấp một số giấy tờ nhất định N hưng trong thực tế,

có thể phát sinh thêm một số trường hợp cá biệt (có sự chấp thuận của người có thNm quyền) thì một số giấy tờ có thể được thay thể bằng một số giấy tờ khác và thậm chí lúc đó quy trình gốc có thể phải bổ sung thêm một số bước mới để xử lý những trường hợp cá biệt như vậy

Trong quá trình thực thi quy trình, việc xuất hiện các ngoại lệ là điều khó tránh

khỏi Do đó, việc tích hợp vào WfMS các khả năng phát hiện và xử lý ngoại lệ là điều cần thiết N ếu không thì khả năng ứng dụng của WfMS vào thực tế là rất thấp

CHƯƠNG II TỔNG THUẬT CÁC NGHIÊN CỨU CÓ LIÊN QUAN

Trong phần II này, chúng tôi sẽ tóm lược một số công trình có liên quan đến đề tài mà chúng tôi đã tìm hiểu được trong thời gian thực hiện luận văn:

II.1 Xử lý bó

Xử lý bó tồn tại trong cả quy trình kinh doanh lẫn quy trình sản xuất Tuy nhiên, các hệ thống quản lý quy trình cổ điển (WfMS) không hỗ trợ xử lý bó [17] Theo chúng tôi biết, [17] là bài báo đầu tiên quan trọng đề cập đến vấn đề xử lý bó động (dynamic batch processing) trong quy trình Hiện tại có rất ít các bài báo về lĩnh vực này

Hình 5 Quy trình cho thuê xe

[17] đưa ra một ví dụ xử lý bó trong quy trình cho thuê xe Quy trình được mô tả trong Hình 5 gồm 6 hoạt động Trước tiên, khách hàng điền vào đơn yêu cầu thuê

xe thông qua web Sau đó, đơn xin thuê xe sẽ được xét duyệt N ếu đơn không được xét thì thông báo từ chối cho khách hàng N ếu nó được thông qua, quy trình sẽ chạy sang hoạt động cho thuê xe Sau đó, tài xế sẽ được thông báo và cuối cùng khách hàng sẽ được thông báo và thu tiền

Trong [17], đối với mỗi khách hàng, hệ thống sẽ tạo ra một workflow instance và lần lượt các bước trong quy trình sẽ được thực thi Trong trường hợp, mỗi khách hàng thuê một chiếc xe thì hệ thống làm việc tốt Tuy nhiên, bài toán đặt ra là xe có khả năng chở nhiều người và một số khách hàng có nhu cầu muốn chia sẻ xe, tức là

đi xe chung với người khác để giảm chi phí thuê xe

Trong trường hợp này, hoạt động cho thuê xe và thông báo tài xế là hai hoạt động

có khả năng xử lý bó N ếu chúng ta gom được nhiều khách vào chung một xe thì chỉ cần thuê một xe và thông báo cho duy nhất một tài xế chạy xe đó N hư vậy là chúng ta muốn gom nhiều activity instance lại để thực thi đồng thời

Về giải pháp,WfMS trong [17] tương tự như đa số các WfMS truyền thống, các hoạt động trong workflow schema tương ứng với một hoặc nhiều ứng dụng agent

Khi workflow instance thực thi tới hoạt động nào đó (activity instance) thì một agent sẽ được chọn để thực thi Tại một thời điểm có thể có nhiều workflow instance, mặc dù tiến độ thực thi của chúng có thể khác nhau Do đó, mỗi hoạt động trong quy trình sẽ có một hàng đợi công việc chứa các activity instance cần thực hiện WfMS truyền thống sẽ lấy activity instance ra, chọn một agent phù hợp và yêu cầu nó thực thi activity instance

Các WfMS truuyền thống sẽ lấy các activity instance trong hàng đợi ra một cách tuần tự và submit cho mỗi agent mỗi lần đúng một công việc Cách xử lý này phù hợp đối với các agent không có khả năng xử lý bó

Trong trường hợp có khả năng xử lý bó, bài báo [17] đề nghị bổ sung thêm vào hàng đợi một thành phần có nhiệm vụ gom nhóm các activity instance lại trước khi submit cho agent Các activity instance sẽ được chọn lựa và nhóm theo một chính sách nào đó Sau đó, một agent phù hợp sẽ được chọn để xử lý nhóm đã được tạo ra

Hình 6 Hàng đợi công việc

Bài báo mô hình hóa một hệ thống xử lý bó gồm 6 thành phần: (1) một quá trình đến của các công việc (arrival process); (2) hệ thống có m agent; (3) mỗi yêu cầu công việc có một deadline; (4) một hàng đợi công việc; (5) khả năng xử lý của agent Cp Tức là agent có khả năng xử lý đồng thời tối đa Cp công việc; (6) một hàm phân phối xác suất thời gian xử

lý của agent

Cơ chế gom nhóm công việc

trong [17] được xử lý rất đơn

giản Việc gom nhóm công việc

trong queue trước khi thực thi

xảy ra khi queue có chứa một số

công việc bằng số công việc mà

Agent có thể xử lý đồng thời Cp

Hoặc việc gom nhóm xảy ra sau

một khoảng thời gian nào đó mà

chưa gom đủ số công việc tối đa

như trên

N goài ra, bài báo [17] còn

chia các xử lý workflow thành 3 dạng như trong Hình 7 Trong hình, schema có 3 hoạt động A,B,C Hoạt động có đường viền bao xung quanh là hoạt động có khả năng xử lý bó (gọi là BPA-Batch Processing Area) Phía trên các đường viền là tên của workflow agent dùng để xử lý hoạt động Trong Hình 7.a, chỉ có một hoạt động

B có khả năng xử lý bó Trong hình Hình 7.b, 2 hoạt động B và C có khả năng xử lý

bó nhưng chúng độc lập nhau Thí dụ có 2 activity instance của B là W1.B và W2.b thì chúng sẽ được nhập chung thành activity instance b’ trước khi được chuyển đến cho agent Agtb xử lý Sau đó, chúng lại được tách ra và nhập lại trước khi vào thực thi activity C Chính sách nhóm activity instance tại B và C có thể khác nhau.Trong Hình 7.c, các activity instance không tách ra khi thực thi xong B mà sẽ chuyển sang thực thi tiếp C Trong thí dụ về quy trình cho thuê xe ở trên thì sau khi nhóm một số

Hình 7 Các dạng xử lý bó

khách vào một xe thì ta ngay lập tức báo cho tài xế của xe đó biết N hư vậy nó thuộc loại c

Tóm lại, trong [17], việc nhóm các công việc để xử lý bó được tiến hành ở mức activity N hư vậy, ứng với mỗi công việc, một workflow instance sẽ được tạo ra Sau đó, khi tiến hành thực thi một hoạt động có khả năng xử lý bó nào đó thì một giải thuật chọn lựa và gom nhóm các công việc mới được tiến hành Tuy nhiên,

trong thực tế, có những workflow instance bản chất chứa nhiều job bên trong Thí

dụ: quy trình xử lý học vụ cho sinh viên thì một workflow instance sẽ xử lý cho nhiều sinh viên N ếu ứng với mỗi job chúng ta tạo ra một workflow instance thì số lượng workflow instance sẽ rất lớn làm tăng tải của hệ thống N goài ra, trong các hệ thống về quản lý quy trình, vấn đề auditing rất quan trọng N ếu chúng ta tạo ra nhiều workflow instance như vậy thì phí tổn auditing cũng sẽ tăng lên không cần thiết Một cách tốt hơn để giải quyết vấn đề là WfMS có thể xử lý được một workflow instance chứa nhiều job Việc gom nhóm bây giờ sẽ là gom nhóm các job trong các activity instance Chúng tôi sẽ trình bày chi tiết hơn về vấn đề này trong phần IV.1

Bên cạnh đó, giải thuật gom nhóm công việc trong hàng đợi của [17] tương đối đơn giản, chỉ dựa vào kích thước hàng đợi và thời gian chờ Thành phần gom nhóm nên có một cơ chế dự đoán thời gian thực thi các workflow instance để rút ngắn thời gian chờ không cần thiết Chúng tôi sẽ trình bày chi tiết hơn về vấn đề này trong chương V

II.2 Xử lý ngoại lệ

[5] phân loại ngoại lệ dựa trên tính biết trước của ngoại lệ: ngoại lệ có thể dự đoán trước và ngoại lệ không dự đoán trước Phần kế tiếp sẽ cung cấp thông tin chi tiết hơn về từng loại ngoại lệ này cũng như các hướng tiếp cận giải quyết các loại ngoại lệ này:

1 Ngoại lệ biết trước (Expected Exception):

Đây là những ngoại lệ mà người thiết kế quy trình dựa vào kinh nghiệm của mình

có thể nhận ra ngay từ khi thiết kế quy trình Chúng cũng có thể là những ngoại lệ chưa được đoán trước ngay từ ban đầu nhưng lại phát sinh trong những lần thực thi quy trình trước đây Trong trường hợp thứ hai thì ở lần đầu phát sinh chúng là những ngoại lệ thuộc loại không biết trước và đòi hỏi sự can thiệp con người để giải quyết (xem trong phần kế tiếp) Sau đó, ngoại lệ được ghi nhận lại và có thể xem như là một ngoại lệ biết trước

Về nguyên tắc, ta hoàn toàn có thể tích hợp các ngoại lệ loại này vào trong workflow schema thông qua các điều kiện rẽ nhánh ([20][7][8][2] áp dụng phương pháp này) Tuy nhiên, nếu tất cả các ngoại lệ có thể xảy ra đều được tích hợp vào schema thì độ phức tạp của quy trình sẽ tăng lên một cách đáng kể và làm cho quy trình gốc trở nên rối rắm, khó hiểu đối với người dùng [16] Hai ngôn ngữ hỗ trợ nhúng ngoại lệ vào trong schema là BPMN /BPEL[2] hay XML Process Definition Language (XPDL) [20]

[12,Error! Reference source not found.,18,6,3,4,11,14] giải quyết vấn đề bằng

cách tách xử lý ngoại lệ ra khỏi việc thực thi quy trình Bên cạnh việc định nghĩa workflow schema, người thiết kế workflow định nghĩa thêm các ngoại lệ Trong quá trình thực thi quy trình, WfMS sẽ dựa trên định nghĩa của ngoại lệ để tự động phát hiện ngoại lệ và thực hiện các hành động cần thiết để xử lý ngoại lệ N hờ việc tách ngoại lệ ra và định nghĩa riêng bên ngoài nên schema bây giờ sẽ đơn giản hơn

N goài ra, một ngoại lệ có thể chỉ cần khai báo một lần và được áp dụng cho một nhóm các quy trình

2 Ngoại lệ không biết trước (Unexpected Exception):

Trong thực tế, người thiết kế quy trình khó có khả năng dự đoán được hết tất cả các tình huống ngoại lệ phát sinh trong quá trình thực thi quy trình Trong một số lĩnh vực ứng dụng, đặc biệt là lĩnh vực y khoa, các quy trình luôn luôn phải được customize lại cho từng hoàn cảnh cụ thể Thí dụ như các quy trình điều trị bệnh Bệnh viện chỉ có thể đưa ra một phác đồ điều trị chung cho một loại bệnh nào đó

Sau đó, khi điều trị cho bệnh nhân thì phác đồ này luôn phải customize lại cho từng người Việc customize này phụ thuộc vào nhiều yếu tố khác nhau của bệnh nhân (như một tiền sử bệnh, thể trạng người bệnh, phản ứng với thuốc…) Các yếu tố này rất đa dạng nên khó có thể dự đoán được hết tất cả trường hợp Do đó, bên cạnh khả năng xử lý những ngoại lệ đã biết trước WfMS phải cho phép người sử dụng can thiệp trực tiếp, thay đổi hoạt động của quy trình để giải quyết các ngoại lệ mới phát sinh N goài ra, WfMS nên cung cấp các thông tin, các gợi ý hỗ trợ cho người sử dụng cách thức xử lý ngoại lệ mới dựa trên một cơ sở tri thức nào đó (knowledge-based exception handling) WfMS đề nghị trong [18] hỗ trợ người người sử dụng ra quyết định xử lý một tình huống mới dựa trên thông tin về việc xử lý các tình huống tương tự trước đây (Case-Based Reasoning exception handling)

Tóm lại, trong quá trình thực thi quy trình, việc xảy ra ngoại lệ là rất khó tránh khỏi Do đó, để công nghệ quản lý quy trình có thể được người sử dụng chấp nhận

và áp dụng vào thực tế thì WfMS phải cung cấp khả năng xử lý ngoại lệ cho người dùng Hệ thống có thể tự động phát hiện và xử lý ngoại lệ hoặc hệ thống cung cấp các phương tiện để người sử dụng có thể tự sửa đổi quy trình để đáp ứng với ngoại

lệ phát sinh Tuy nhiên, dù ở mức độ nào, để có thể giải quyết ngoại lệ thì WfMS bắt buộc phải được thiết kế sao cho mềm dẽo để có thể thay đổi động được các quy trình đang thực thi

Trong lĩnhvực xử lý ngoại lệ của quy trình, hiện đã có rất nhiều các bài báo liên quan đến lĩnh vực này Tuy nhiên, các tác giả đều chỉ nêu lên xử lý ngoại lệ cho cả workflow instance Khi áp dụng vào xử lý bó, chúng ta cần lưu ý thêm là ngoại lệ thường chỉ xảy ra cho một số job trong workflow instance chứ không phải tất cả các job trong workflow instance N goài ra, chúng ta cũng nên cố gắng nhập các công việc của các job bình thường và job bị ngoại lệ tại những hoạt động có khả năng xử

lý bó

II.3 Framework các hệ thống quản lý quy trình

N ăm 1995, tổ chức Workflow Management Coalition (www.wfmc.org) đưa một

mô hình tham chiếu (reference model) (Hình 8) cho việc hiện thực hệ quản lý quy

trình Mô hình tham chiếu này được mô tả trong [13]

Hình 8 Mô hình tham chiếu WfMS

Trong mô hình này, WfMS bao gồm một Enactment Service chứa Workflow Engine quản lý toàn bộ việc tạo và thực thi các workflow instance Đây là thành phần lõi của hệ thống Tuy nhiên, Workflow Engine chỉ chịu trách nhiệm điều phối

các hoạt động trong quy trình, không trực tiếp thực thi các hoạt động trong quy

trình Thay vào đó, nó sẽ gọi các ứng dụng Workflow Client (hay còn gọi là Agent)

để làm điều này Thiết kế này cho phép WfMS linh hoạt xử lý được nhiều loại công việc khác nhau N goài ra, hệ thống còn có thành phần Process Definition Tool là công cụ hỗ trợ người sử dụng định nghĩa quy trình Administration & Monitoring Tools là công cụ hỗ trợ quản lý và giám sát việc thực thi quy trình Bên cạnh đó, Enactment Service còn có thể tương tác với WfMS khác thông qua interface 4 [24] bổ sung vào mô hình tham chiếu trên một số thành phần nhằm hỗ trợ thay

đổi động quy trình (Hình 9) Trong hệ thống vẫn có Workflow Engine và Definition Tool, Workflow Client N ằm giữa Workflow Engine và Workflow Client là một

Work List Handler có vai trò là hàng đợi công việc Các hoạt động trong quy trình

khi đủ điều kiện thực thi sẽ được thêm vào Work List chờ Workflow Client lên lấy

về xử lý N goài ra, [24] bổ sung thêm một số thành phần

- Thành phần Verification Engine được trang bị cho Definition Tool để kiểm

tra tính đúng đắn (correctness) của schema lẫn các thay đổi tạm thời trên các workflow instance

- Version Tracker: Một quy trình có thể chịu nhiều thay đổi theo thời gian

Thành phần Version Tracker theo dõi và quản lý các phiên bản khác nhau của quy trình

- Compliance Module nhận vào chính sách thay đổi, tập các workflow instance

bị ảnh hưởng, instance logs và cập nhật lại trạng thái thực thi của workflow instance cũng như thực thi các thao tác undo (còn được gọi là compensation activities) cần thiết trước khi chuyển workflow instance sang thực thi với schema mới

- Modification Analyzer làm nhiệm vụ phân tích các thao tác thay đổi trên quy

trình để đưa ra những hướng dẫn cho người quản lý quy trình (WFA – Workflow Administrator) thí dụ như: mức độ tương thích, chi phí để thực hiện thao tác chuyển đổi (migrate) workflow instance sang schema mới…

- Workflow Repository được mở rộng để lưu trữ các thông tin về các thao tác

thay đổi

Tuy nhiên, trong các framework của [13] và [24], chúng ta thấy không có các thành phần liên quan đến xử lý bó

Hình 9 Framework hỗ trợ adaptive workflow [24]

CHƯƠNG III GIỚI THIỆU BÀI TOÁN

Chúng ta xem xét quy trình xử lý học vụ như sau: Đầu mỗi học kì, nhà trường tiến hành quy trình xử lý học vụ đối với các sinh viên thuộc diện yếu kém để quyết định thực hiện các biện pháp xử lý phù hợp (thí dụ: cảnh cáo, buộc thôi học một học

kì hoặc buộc thôi học hẳn) Quy trình bao gồm 10 hoạt động (Hình 10) bắt đầu bằng lập danh sách SV thuộc diện xử lý Danh sách này được trưởng phòng đào tạo kí

duyệt và chuyển xuống các khoa Các khoa sẽ thông báo cho sinh viên và nhận đơn xin cứu xét từ sinh viên Danh sách những sinh viên có đơn xin cứu xét sẽ được tổng hợp lại ở bước 6 Ở bước 7, hội đồng khoa sẽ họp để xét duyệt từng trường hợp Kết quả họp về cách xử lý cho từng sinh viên sẽ được tổng hợp và trình ban chủ nhiệm khoa kí duyệt (bước 9) sau đó chuyển lên phòng đào tạo xử lý tiếp (bước 10) Về mặt cấu trúc, quy trình khá đơn giản chỉ gồm các hoạt động diễn ra tuần tự, trong các trường hợp phức tạp, quy trình có thể chứa các điều kiện rẽ nhánh và vòng lặp

Mỗi đầu học kì, quy trình này được áp dụng Lúc đó, một workflow instance sẽ được tạo ra và thực thi Ở đây mỗi workflow instance sẽ xử lý cho nhiều sinh viên

Ta gọi là là xử lý bó Mỗi sinh viên cùng các thông tin có liên quan được gọi là một Job Chúng ta thấy có nhiều bước trong quy trình trên nếu xử lý bó (xử lý đồng thời

nhiều job) sẽ hiệu quả hơn Thí dụ ở bước thứ 9, nếu xử lý bó thì hệ thống sẽ sinh ra văn bản chứa danh sách các sinh viên và trưởng khoa chỉ kí duyệt trên 1 danh sách duy nhất Lúc đó, phòng đào tạo chỉ nhận một danh sách duy nhất

Tuy nhiên, hiện nay các động cơ thực thi (execution engine) của các WfMS chỉ

Hình 10 Quy trình xử lý học vụ

mỗi workflow instance sẽ nhận vào một khối dữ liệu và nó sẽ chuyển cho các agent

để chúng cập nhật dữ liệu mà không quan tâm đó là một khối dữ liệu cho một sinh viên hay nhiều sinh viên Việc lấy ra từng sinh viên để xử lý là do các agent thực hiện Với cách làm như vậy, chúng ta sẽ gặp phải hạn chế trong vấn đề xử lý ngoại

lệ Giả sử trong quá trình quy trình trên đang chạy đến bước thứ 3 thì một vài sinh viên trong số sinh viên bị xử lý học vụ rơi vào trường hợp ngoại lệ và phòng đào tạo quyết định chỉnh sửa lại schema (thí dụ: thêm một vài bước mới vào quy trình) để giải quyết riêng cho các trường hợp này Lúc đó, do WfMS không nắm giữ thông tin về các job trong workflow schema nên nó không thể tự mình tách các job này ra

và xử lý riêng

N goài ra, một vấn đề khác nữa là sau khi các sinh viên này trải qua các bước xử

lý phụ bổ sung sẽ quay trở về với các bước giống như trong schema cũ Tuy nhiên, lúc này có thể các sinh viên bình thường đã được WfMS yêu cầu thực thi trước Điều này dẫn đến việc các hoạt động sẽ phải thực thi hai lần không hiệu quả Thí dụ: họp khoa 2 lần, một lần cho sinh viên bình thường và một lần cho sinh viên ngoại lệ; hay tạo ra 2 danh sách rời cho trưởng khoa kí duyệt và chuyển lên phòng đào tạo trong khi thực tế chỉ cần một danh sách chung cho cả sinh viên thường và sinh viên rơi vào trường hợp ngoại lệ

Bên cạnh đó, để xử lý hiệu quả các ngoại lệ, WfMS phải cung cấp cơ chế cho phép nhập chung nhiều workflow instance Xét ngữ cảnh phòng đào tạo vì lý do nào

đó (thí dụ: do có sai sót trong lập danh sách trước đây), phòng đạo tạo muốn bổ sung thêm vào danh sách sinh viên xử lý học vụ sau khi workflow instance xử lý học vụ đã thực thi một số bước Đế làm được điều này, ta phải tạo ra một workflow instance mới với các job là danh sách các sinh viên vừa bổ sung thêm Workflow instance ngoại lệ và workflow instance gốc ban đầu có các hoạt động giống nhau

Do đó, để xử lý hiệu quả, ta nên trì hoãn workflow instance gốc nếu có thể để nhập chung một số công việc với workflow instance ngoại lệ tránh trường hợp một số công việc phải xử lý 2 lần như đã nêu trên Tuy nhiên, việc trì hoãn cũng không nên quá lâu Do đó, ta cần một cơ chế dự đoán thời gian thực thi của workflow instance

nhằm quyết định nên trì hoãn để nhập chung hay tách các workflow instance ra và

xử lý riêng

Chương IV sẽ trình bày một framework của hệ thống quản lý quy trình hỗ trợ xử

lý các vấn đề trên

CHƯƠNG IV GIẢI PHÁP XỬ LÝ BÓ TRONG WfMS

Hiện nay, các WfMS vẫn có khả năng xử lý được các công việc có tính chất bó Tuy nhiên, các WfMS sẽ không nắm thông tin về từng công việc trong bó N ó không quan tâm trong bó có bao nhiêu công việc, mỗi công việc có những dữ liệu

gì WfMS chỉ biết có một khối thông tin được truyền cho workflow instance và khối thông tin này sẽ lần lượt được cập nhật bởi các activity trong quy trình Việc quyết định có xử lý bó hay không sẽ hoàn toàn do các ứng dụng workflow agent phải quyết định và người phát triển các ứng dụng workflow agent phải xử lý việc này

Do WfMS không nắm thông tin về các công việc bên trong bó nên nó sẽ không thực hiện được các công việc quản lý bó như tách các job bị ngoại lệ ra riêng để xử lý, gộp chung các job lại để tăng tính hiệu quả công việc

Chính vì lý do đó, chúng tôi thấy rằng việc WfMS cần phải xử lý các thông tin về job trong workflow instance là cần thiết Trong phần này, chúng tôi đề nghị giải pháp liên quan đến xử lý bó gồm:

1 Mở rộng workflow meta data với một số phần tử (notation) mô tả các thông tin liên quan đến xử lý bó

2 Cơ chế thực thi thực thi hỗ trợ xử lý bó

3 Cơ chế xử lý ngoại lệ trong trường hợp WfMS có xử lý bó

4 Cơ chế gộp chung các workflow instace nhằm tăng tính hiệu quả trong xử lý bó Cuối cùng, các giải pháp trên sẽ được tích hợp vào một framework của một WfMS Riêng phần (4) với các giải thuật cụ thể sẽ được mô tả chi tiết hơn trong chương 4

IV.1 Mở rộng động cơ thực thi (Execution Engine) nhằm hỗ trợ xử lý bó

Khi cần thực hiện công việc, người

sử dụng sẽ yêu cầu một thành phần

trong WfMS là động cơ thực thi

(execution engine) tạo ra một workflow

instance từ một workflow schema nào

đó Sau đó, động cơ thực thi sẽ tiến

hành thực hiện workflow instance N ó

sẽ điều phối việc thực thi các activity

trong quy trình dựa trên thông tin được

mô tả trong workflow schema Trong

phần này, chúng tôi sẽ trình bày cách

hoạt động thông thường của một động

cơ thực thi Sau đó, chúng tôi đề nghị

XOR-Sau khi tạo ra workflow instance, động cơ thực thi sẽ sử dụng token để đánh dấu

Hình 11 Cơ chế thực thi với token

chờ đến khi người sử dụng thực thi thì chuyển sang trạng thái executing Sau khi A thực thi xong, token sẽ được chuyển cho XS (Hình 11.b) Tại đây, biểu thức điều kiện sẽ được đánh giá và token sẽ rẽ theo một trong 2 nhánh Trong hình vẽ thì token đi theo nhánh B Sau khi B thực thi xong, token sẽ chuyển sang XJ và cứ thế

cho đến khi nào token đi đến event End thì workflow instance kết thúc

N hư vậy, khi một activity hoàn tất, động cơ thực thi sẽ căn cứ vào dòng điều khiển mô tả trong schema để quyết định đNy token sang vị trí mới Activity khi nhận được token sẽ chuyển sang trạng thái active chờ thực thi Token ở đây có chức năng

kích hoạt sự thực thi của activity nên còn được gọi là true token Một số hệ thống còn sử dụng thêm false token để báo hiệu rằng activity bị bỏ qua

và không thể thực hiện được Đối với các hệ thống này thì tại các gateway Exclusive Decision, nhánh đúng sẽ nhận true token và nhánh sai sẽ nhận false token False token có cơ chế hoạt động hoàn toàn giống true token nhưng mục đích

nó là đánh dấy những activity không thể thực hiện được nữa

Về mặt dòng dữ liệu (data flow), mỗi

workflow instance sẽ có một tập các biến

Trong Hình 12 thì mỗi workflow instance

có 3 biến a,b,c Các activity trong workflow

instance có thể đọc và ghi vào các biến này

Các WfMS sẽ cung cấp cho các WF Agent

tập các hàm API cho phép việc truy xuất vào các biến trong workflow instance Một

số biến trong workflow instance được gán sẵn giá trị ngay khi được tạo ra Chúng đóng vai trò như các giá trị input, tham số cho workflow instance (thí dụ như mã số sinh viên, mã số đơn hàng, ) Một số biến sẽ lưu kết quả là giá trị kết xuất của workflow instance (thí dụ: kết luận có cứu xét cho sinh viên hay không, tổng giá thành đơn hàng, ) Trong quá trình thực thi của các activity, các activity có thể truyền dữ liệu cho nhau bằng cách tạo thêm các biến tạm trong workflow instance Một activity sẽ ghi dữ liệu vào biến tạm, activity sau đó sẽ đọc dữ liệu từ biến tạm

Hình 12 Biến dữ liệu toàn cục

N hư vậy, người sử dụng và agent phải hoàn toàn tự quản lý các job WfMS hoàn toàn không quan tâm workflow instance có bao nhiêu job, mỗi job có những dữ liệu

cụ thể nào N ó chỉ biết nhận một khối dữ liệu khi workflow instance được tạo ra và giao cho các Agent xử lý cập nhật dữ liệu Với cách làm như vậy, WfMS không thể

tự mình quản lý các job Thí dụ khi có ngoại lệ xảy ra cho một số các job chứ không phải tất cả các job trong workflow instance thì động cơ thực thi không thể tự động tách riêng các job bị ngoại lệ ra để xử lý riêng N goài ra, do không quản lý thông tin

về job, động cơ thực thi cũng không có khả năng nhập (merge) các job ở các workflow instance lại với nhau để thực thi xử lý bó để tăng tính hiệu quả Do đó, để

xử lý hiệu quả, động cơ thực thi bắt buộc phải quản lý và nắm giữ thông tin về từng job trong workflow instance

Cách xử lý khá đơn giản Dữ liệu chứa trong workflow instance, gọi là batch data, chứa một tập các job data có cấu trúc giống nhau Mỗi job data chứa các biến cho một job đang được xử lý bởi workflow instance Khi thực thi các activity trong quy trình, nếu activity không có khả năng xử lý bó thì động cơ thực thi sẽ gọi agent

có tính xử lý bó, 1 danh sách sẽ chứa nhiều sinh

viên) thì động cơ thực thi sẽ gọi agent một lần và

truyền cho nó cả batch data

Tuy nhiên, batch data ở đây không phải là dữ

liệu toàn cục của một workflow instance mà nó

được gắn với một token cụ thể Điều này là rất

cần thiết nếu workflow instance xử lý bó Thật

vậy, nếu trong workflow instance có chứa nút rẽ

nhánh như trong Hình 13 thì tại điều kiện rẽ

nhánh chỉ có một số job đi theo nhánh true và các job còn lại đi theo nhánh false

N hư vậy, token khi đến XOR-Splot thì bị tách ra thành 2 token đi theo 2 nhánh output (lưu ý là cả 2 token này đều là true token) Khi token bị tách ra như vậy thì batch data gắn với token ban đầu cũng bị tách ra tương ứng Thí dụ trong Hình 13, token ban đầu chứa 2 job (Job 1 và Job 2) Khi đi đến gateway rẽ nhánh thì tách ra thành 2 token, token trên chứa Job1, token 2 chứa Job2 N guyên nhân là do với dữ liệu chứa trong các biến của Job1 thì điều kiện rẽ nhánh tính ra là đúng trong khi đó thì Job 2 lại cho ra kết quả sai

N hư vậy, cơ chế thực thi quy trình dựa trên token có thể tóm tắt như sau:

 Sau khi tạo workflow instance, activity đầu tiên của nó sẽ được gán 1 token Token này sẽ được gắn kèm với một Batch Data chứa dữ liệu tất cả các job trong workflow instance Động cơ thực thi có khả năng thấy được và thao tác dữ liệu trên từng job độc lập

 Khi một activity có token thì activity đó sẽ chuyển sang trạng thái active chờ được thực thi Khi thực thi, nếu activity có khả năng xử lý bó thì động cơ thực thi sẽ truyền cho agent tất cả các job hiện đang chứa trong token đang nằm tại activity N ếu activity không có khả năng xử lý bó thì động cơ thực thi sẽ gọi agent xử lý activity nhiều lần Mỗi lần agent sẽ nhận một job data chứa trong token

Hình 13 Token chứa batch data

 Sau khi activity thực thi xong, token sẽ được truyền cho activity kế tiếp Trong trường hợp activity là một nút rẽ nhánh thì token sẽ được chia nhỏ ra thành 2 token như trong Hình 13 Batch data trong token ban đầu sẽ được chẻ ra thành 2 batch data gắn vào 2 token Job nào thỏa điều kiện rẽ nhánh thì thêm vào token mới tạo ra trên nhánh true và tương tự cho nhánh false

IV.2 Meta Data hỗ trợ xử lý bó

Workflow meta data là ngôn ngữ dùng để định nghĩa quy trình Workflow meta data phải có khả năng biểu diễn mạnh để người sử dụng nhúng các thông tin ngữ nghĩa vào quy trình Do đó, các giải pháp về workflow, xử lý ngoại lệ trong quy trình, xử lý bó đều gắn với một workflow meta data nào đó Ở đây, chúng tôi cũng làm như vậy

Hiện nay có rất nhiều workflow meta data N hiều tác giả khác nhau đưa ra nhiều workflow meta data khác nhau phù hợp với bài toán cần giải quyết như ADEPTFlex[19], YAWL[26], Routing Diagram[27], BPMN /BPEL[1] Trong đó, chúng tôi đánh giá BPMN (Business Process Modelling N otation) là một meta data mạnh N goài các notation bình thường về dòng điều khiển (rẽ nhánh, đồng bộ), nó còn có các notation biểu diễn cho xử lý ngoại lệ, sự kiện N goài ra, nó đã được chuNn hóa bởi tổ chức OMG và được khá nhiều công cụ thương mại hỗ trợ như WebSphere, SAP, Oracle Bên cạnh nó, song hành với BPMN là BPEL (Business Process Execution Language), một chuNn đặc tả quy trình dưới dạng XML rất phổ biến

Ở đây, chúng ta muốn cung cấp cho WfMS các khả năng xử lý bó thì chúng ta cũng phải mở rộng workflow meta data để cho phép người sử dụng nhúng các thông tin về xử lý bó vào trong workflow schema Phần bên dưới, chúng tôi đề nghị bổ sung thêm một số kí hiệu (notation/construct) vào meta data của BPMN Tuy nhiên, các construct sau đây hoàn toàn có thể được bổ sung thêm vào các meta data khác

Chúng ta biết một số activity có khả năng xử lý bó Chúng có khả năng xử lý đồng thời nhiều job trong một lần thực thi và khi xử lý đồng thời như vậy thì chi phí

sẽ thấp hơn nhiều so với khi thực thi activity đó nhiều lần để thực thi nhiều job Thí dụ: trong lĩnh vực điều vận (logistic), ta có nhiều đơn hàng nhận từ khách hàng Thay vì lập tức đặt hàng khi nhận được một đơn hàng nào đó, ta có thể trì hoãn một thời gian để gom chung nó với những đơn hàng khác trước khi đặt hàng nhà cung cấp Với đơn đặt hàng nhiều ta sẽ được các ưu đãi từ nhà cung cấp cũng như tiết kiệm được một số chi phí phát sinh do đi lại, giao dịch Một trường hợp khác là ta

có nhiều quy trình, mỗi quy trình đều đòi hỏi một số người nhất định tham dự cuộc họp N ếu ta có thể trì hoãn hợp lí các công việc để gom các buổi họp vào chung một buổi thì sẽ được lợi rất nhiều về mặt thời gian đi lại

N gười thiết kế quy trình khi định nghĩa schema sẽ mô tả

activity nào là activity có khả năng xử lý bó bằng cách

dùng notation 2 trong Hình 14 N otation 1 trong hình

dùng để biễu diễn activity bình thường không có khả năng

xử lý bó Khi activity có notation 1 nhận token thì động cơ thực thi sẽ tự động gọi

nó nhiều lần để thực thi từng job đang chứa trong token

2 Construct đồng bộ giữa các job

N hư đã trình bày ở trên, khi token đến gateway XOR-Split, nó sẽ được tách ra thành 2 token mới đi theo 2 nhánh Token đi theo nhánh true sẽ chứa các job có biểu thức điều kiện đánh giá là true Token đi theo nhánh false sẽ chứa các job có biểu thức điều kiện đánh giá là false Xét thí dụ trong Hình 15:

Hình 15 Xử lý bó và XOR-SPLIT

Hình 14 Activity Notation