工作流參考手冊(編輯修改稿)

　

【文章內容簡介】 連接線 上為“默認值“所指的后繼活動“人工活動”一定會被觸發；又由于滿足“ num5”的條件所以“人工活動 1”也會被觸發 2) 由活動射出的連線上中 沒 有默認值 ，全部設置條件 如上圖所示，由于“開始活動”的“分支模式”是 “ 多路分支 ” 并且在處理的過程中 “num==6” ，那么根據上面的算法說明由于 射向 “活動 B與 “ 活動 D”的連線上的條件都滿足，因此“活動 B與 “ 活動 D” 在開始活動結束后被觸發。 參與者設置 活動參與者實際上是指在流程實例運行過程中，流程實例 “ 流轉 ” 至此時該活動實例所對應的工作項有哪些人可以執行。在流程定義時設置 活動的參與者實際上是圈定流程實例運行至此時可以執行該活動實例所對應工作項的人員范圍，可以是機構、角色或人。 EOS WorkFlow 提供了 4 種可以獲取參與者的方式： 組織機構與角色 ：參與者由開發人員從機構樹中獲取 – 只選擇一人：表示該活動所對應的工作項直接分配給該人處理 – – 超過一人：表示該活動所對應的工作項由這些人中的某個人以 “ 領取 ”的方式處理 虛擬崗位（機構 +角色） ：表示 在不設置崗位的情況下，由部門 +角色共同決定一個人工活動的參與者。 流程啟動者 ：表示活動參與者為該流程的啟動者 活動執行者 ：表示活動 參與者為某個已完成的活動實例所對應工作項的執行者 從相關數據獲取 ：表示活動參與者由相關數據指定。由相關數據獲取參與者的規則詳見 從相關數據獲取參與者 從規則邏輯獲取 ：表示活動參與者由某個規則邏輯的返回值 確定。由規則邏輯獲取參與者的規則詳見 從規則邏輯獲取參與者 特別說明 :如果要改寫組織機構權限并在參與者設置的時候顯示新的組織機構樹，具體操作請參見知識庫文檔： 組織機構與工作流集成方案 .doc 虛擬崗位（機構 +角色）設置參與者 圖 通過機構 +角色實現虛擬崗位設置參與者 用角色 +機構的方式設置參與者需要特別注意的是，在該活動激活以前一定要將上圖中機構變量路徑設置到相關數據區中。 此外，還有 一種方法設置一組機構：把多個機構 寫成 如下格式 ： list id1/id / id2/id / /list 這樣機構變量路徑 xpath 寫成： list//id 即可。這樣，工作流引擎也會找 到多個機構 id， 從而 實現 設 置一組機構 +角色的要 求。 如下 圖所示： 圖 設置一組機構變量 從相關數據區設置 參與 者 1）從相關數據獲得一個具體的參與者 【算法說明】 從相關數據的 XPATH 中，直接指定一個參與者。 注：這種方式獲得的參與者只能是個人。 相關數據必須滿足下面的結構。 XXXXtiger/XXXX 2）從相關數據獲得某一類型的參與者（指定一個或一組人員） 【算法說明】 從相關數據的 XPATH 中，獲得某一類型的參與者?？梢允且粋€人，也可以是某一角色或某一機構的一組人。相關數據必須滿足 下面的結構。 XXXX id/ name/ type/ /XXXX 3）從相關數據獲得一系列參與者 【算法說明】 從相關數據的 XPATH 中，獲得一組參與者。可以是一個人、一個角色、一個崗位、一個機構，也可以是機構、角色或個人的集合，還可以是崗位列表的集合。相關數據必須滿足下面的結構。 list Participant id/ name/ type/ /Participant Participant id/ name/ type/ /Participant /list id 和 type 的含義如上所示 [特別說明 ]： 在上面 XPATH 結構中如果 type 是 “ person”， 那么 id 即為用戶ID； 如果 type 是 “ role”，那么 id 即為角色 ID；如果 type 是 “ anization”，那么 id 即為機構 ID； 如果 type 是 “ position”，那么 id 即為崗位 ID； 如果 type是 “ position_list”，那么 id 即 需滿足如下格式： Condition type=OR // type=”OR”表示組織機構 roleIDrolea/roleID // 角色 ID ID$ID/ID // 獲取機構 ID 的 XPATH（相對于相關數據的根路徑）。 ”$”不可少，標識其后的串是個 XPATH。 /Condition 此外，還有一種方法設置一組機構：把多個機構寫成如下格式： list id1/id / id2/id / /list 這樣機構變量路徑 xpath 寫成： list//id 即可。這樣，工作流引擎也會找到多個機構 id，從而實現設置一組機構 +角色的要求。 從規則邏輯設置 參與者 從規則邏輯獲取參與者 【算法說明】 從業務邏輯獲取參與者列表，然后再按照“分配到組織機構”的模式進行分配。從業務邏輯返回 Dom 當中找到參與者列表的方法： 1） 如果返回的結果中包括下面的結構，系統從 list 節點中獲取多個參與者。 list Participant id/id name/name type/type /Participant Participant id/id name/name type/type /Participant /list 2） 如果從規則 邏輯中沒有找到 list 節點，那么系統會查找 Participant 節點 .獲取參與者。格式如下所示： Participant id/id name/name type/type /Participant id 和 type 的含義同上。 [特別說明 ]： 如果如上所示的兩種結構都存在于調用的規則邏輯的返回的結果中，那么系統只會從 list 節點中獲取參與者。 在上面 XPATH 結構中如 果 type 是 “ person”， 那么 id 即為用戶 ID； 如果 type是 “ role”，那么 id 即為角色 ID；如果 type 是 “ anization”，那么 id即為機構 ID； 如果 type 是 “ position”，那么 id 即為崗位 ID； 如果 type是 “ position_list”，那么 id 即 需滿足如下格式： Condition type=OR // type=”OR” 表示組織機構 roleIDrolea/roleID // 角色 ID ID$ID/ID // 獲取機構 ID 的 XPATH（相對于相關數據的根路徑）。 ”$” 不可少，標識其后的串是個 XPATH。 /Condition 此外，還有 一種方法設置一組機構：把多個機構寫成如下格式： list id1/id / id2/id / /list 這樣機構變量路徑 xpath 寫成： list//id 即可。這樣，工作流引擎也會找到多個機構 id，從而實現設置一組機構 +角色的要求。 工作流 參與者設置機制說明 流程實例根據流轉條件依次激活實例中的相應的活動，當活動分配給某個參與者（唯一的 userID）的時候，就在 WFWorkItem 表中形成一條工作項記錄，主鍵為 workItemID。在 WFWorkItem 工作項信息表里還有個很重要的字段：participant。這個字段描述該工作項的參與者具體是誰。在工作項參與者WFWIParticipant 表中，也有工作項 workItemID 和參與者 participant，不過，這個表里描述的是根據流程定義，活動被激活后工作項的分配情況， 根據流程定義的設置形 成相應的記錄，比如，流程定義中有 3 種參與者，那么在WFWIParticipant 表中也形成 3 條記錄， 所以這里的參與者有可能是具體個人（ userID），也可能是角色（ role），也可能是機構（ ID），也可能是崗位（ positionID）， 當工作項沒有領取的時候，在 WFWorkItem 表中也會形成一條記錄，這條記錄的參與者字段 participant 是用“ |”隔開的參與者串，這個串中的參與者是在流程定義的時候定義的。 當工作項被領取以后，就會在工作項表WFWorkItem 表里出現具體的執行人信息。此外，有時候 工作項會出現該派的情況，這個時候，改派以后具體參與者也在工作項表 WFWorkItem 表有描述，而工作項參與者 WFWIParticipant 表不會有什么變化。 時間限制 活動的時間限制表示活動實例啟動啟動后必須在多長時間內完成。在活動時間限制的設置中 EOS WorkFlow 為開發人員提供了指定具體的限制時間、超時是否進行郵件通知、是否在超時前進行提醒、是否發提醒通知等功能。 活動時間限制的設置：開發人員可以根據業務需要在 “ 人工活動 ” 和 “ 子流程活動 ” 中進行設置。 活動時間限制的計時：從活動實例啟動時開始計時 活動時間限制的獲?。褐苯又付?、從相關數據獲?。ǜ袷剑? 表示時限為 3 天 5小時 20 分鐘） 活動還有超時的觸發事件設置，可以針對超時做具體的操作。 EOS WORKFLOW 判斷流程或人工活動超時的原理 流程或人工活動的時間限制中設置的限制時間將寫入表 WFProcessInst 或WFWorkItem 的 limitNum 字段中，單位為毫秒， limitNumDesc 是其描述字段；finalTime 是時間限制到達后的時間。 EOS WorkFlow 將當前時間與 startTime相減的結果與 limitNum 比較， 一旦超出時間限制就將 isTimeOut 字段置為 Y，表示超時 ； timeOutNum 表示超時了多長時間，在流程結束時寫入。如果設置了超時提醒，該字段可能出現負數，是未超時的表現，只有正數才表示超時的時間，timeOutNumDesc 是其描述字段。 多工作項 一個活動到底產生多少個工作項并且產生的這些工作項又由誰來做呢？ EOS WorkFlow 就工作項的產生和分配問題提供了 2種策略： 按參與者設置個數領取工作項： 按照此活動參與者的個數產生工作項。每個參與者一個工作項，若參與者中包括若干人員（比如參與者的類型為機構 或角色），則這些人員可通過先 “ 領取 ” 的方式執行工作項。 例如：某活動設置了 3 個參與者： tiger，角色 B(包含 fish 和 goose 兩人 )，機構 A(包含 kitty、 snoppy、 micky 三人 )，那么按照此策略將產生 3個工作項。具體分配為： tiger 一個工作項，由其直接執行 (該參與者只有一個人所以無需先領取 )；角色 B一個工作項，由 fish 或 goose 中的一個人以領取的方式執行；同理，機構 A一個工作項，由 kitty、 snoppy 或 micky 中的一個人以領取的方式執行 。 按操作員個數分配工作項 ：根據參與者中的人 員個數產生工作項，并且這些工作項將直接分配到參與者中的人員，每人一個。 例如，上面的例子若按此策略將產生 6 個工作項， tiger、 fish、 goose、 kitty、snoppy， micky 每人分配一個工作項，直接執行。 多工作項執行 不管工作項的個數如何相關人員每個人至多只能執行一個。 未完成工作項自動終止 1） 選擇 “ 是 ” ： 工作流引擎在結束活動實例的同時對于那些剩余的未完成的工作項作 “ 停止 ” 處理 。 2） 選擇 “ 否 ” ： 那些剩余的未完成的工作項仍處于 運行 狀態，盡管此時活動實例已結束。這些工作項的擁有者此時無論 是否處理它們，已不會對運行的流程造成任何影響，只有當流程實例結束時，引擎才會將這些工作項終止 活動項與 工作項 活動項和工作項是一對多的關系， 人工活動被激活后，形成活動項實例繼而有生成工作項實例，供參與者操作。在工作項 表 WFWorkItem 中保存了活動項實力和工作項之間的關系。 通過 BL_finishActivityByDefID 結束活動的方式結束工作項 在現有工作流工作項結束調用中一般都會采用 BL_finishWorkItem這個運算邏輯調用，但是也有情況可以