第四章 利用 BigTable 建構 DRA4WfMS 文件池
第二節 流程活動的通知功能
對於工作流程管理系統來說，支援通知 (notification) 功能是很常見的。當 一個流程活動已經準備好讓某個參與者執行時，系統就會立刻通知他。然而，
在這個資料表裡所包含的資訊，對於入口伺服器來說並不足以讓其去決定是否 應該要通知隨後流程活動的參與者。舉例來說，對照圖四.4 來看，在圖四.2 的
工作流程中的流程活動 “A_0” 以及 “B1_0” 已經執行完成。當流程活動
“B1_0” 執行完成時，系統會新增第三列，然後得知隨後的流程活動跟參與者 分別是 “C_0” 以及 “C_Agency”。然而，因為在流程中，流程活動 “C_0” 前 有個包含流程活動 “B1_0” 及 “B2_0” 的 “AND-join”，“C_Agency” 不應該被 通知開始執行 “C_0”。這個 “AND-join” 表示 ”C_0” 只有在流程活動 “B1_0”
以及 ”B2_0” 都執行完成的時候才能開始執行。我們建議為每個工作流程建構 一個像是圖四.5 的通知表 (notification table)，此通知表的內容是基於圖四.2 的 工作流程定義而建立。對照到這個表的第四列，根據 “ID WF3456” 的工作流 程定義，當流程活動 “B1_i” 以及 “B2_i” 都完成之後，流程活動 “C_i” 才能 開始執行。這裡的i 代表著流程活動的索引。第一列代表 “A_0” 應該在工作流 程程序開始執行時才應該執行，而 “A_i” 要在 “D_i-1” 完成之後才能執行。
Row Activity:Notification tw.edu.ntnu_WF3456_A_i START (i=0) | Finished[D_(i-1)]
tw.edu.ntnu_WF3456_B1_i Finished[A_(i)]
tw.edu.ntnu_WF3456_B2_i Finished[A_(i)]
tw.edu.ntnu_WF3456_C_i Finished[B1_(i)] & Finished[B2_(i)]
tw.edu.ntnu_WF3456_D_i Finished[C_(i)]
圖四.5. DRA4WfMS 通知表的片段資料
一般來說，當我們必須要提取跟儲存 DRA4WfMS 文件時，是不需要使用 MapReduce 計算的。當一個參與者接收到包含工作流程定義編號、工作流程程
序編號、流程活動編號以及索引等資訊的通知，並要求他執行一個流程活動時，
參 與 者 可 以 使 用 這 些 資 訊 跟 入 口 伺 服 器 提 出 提 取 的 請 求 ， 去 提 取 需 要 的 DRA4WfMS 文件。在流程活動執行結束之後，他可以根據通知內所包含的資 訊來上傳帶有執行結果的 DRA4WfMS 文件到入口伺服器上。
通知的資訊可以透過 E-mail 或者是其他任何種類的通訊系統傳送給參與 者。當參與者收到通知資訊時通常會將其儲存，並且根據其資訊來開始執行流 程活動。然而，通知資訊是有可能會遺失的。直觀的來說，這個問題的其中一 個解決方案就是讓系統維護一份所有參與者的待辦列表。然而，參與者的待辦 列表有可能會隨著其身分的變換而動態地改變。當參與者的通知訊息遺失或是 參與者的身分改變，我們必須搜尋整個 DRA4WfMS 文件池來得知該使用者的 待辦列表。因為我們支援多租戶架構，我們必須提供有效率的方法去搜尋資料
31
表。很幸運地，Hadoop 支援 MapReduce 計算框架來對 HBase 資料表中的行 做平行處理。為了得知參與者的待辦列表，我們在 DRA4WfMS 文件池中使用 MapReduce 計算。每行會被平行處理，“Activity:NextActivities” 的資料單元會
被檢查，以找出該流程活動的隨後流程活動的參與者是否包含某個參與者的編 號。隨後，我們使用 DRA4WfMS 通知表來決定某個流程活動是否準備開始執 行。
32