1.3 工作流管理系統
1.3.1. 概述：
即workflow management system，簡稱wfms，是定義、建立、執行工作流的系 統。工作流管理系統為方便業務互動邏輯、業務處理邏輯以及參與者的修改，多數通過提 供視覺化的流程設計器以及表單設計器來實現，為實現工作流管理系統的擴充套件性。
1.3.2. 定義：
乙個軟體應用程式，它儲存流程定義並通過其工作流引擎元件來根據這些流程定義執行工作。工作流引擎是執行時執行模組
1.3.3. wfms的介面：
定義介面：允許流程開發人員部署流程定義；這裡的「流程開發人員」是業務分析師和軟體開發人員的組合
執行介面：使使用者和系統可以操作流程例項；流程例項是流程定義的執行；流程定義的控制流通過狀態機描述；執行介面的兩個主要方法是啟動乙個流程例項和通知工作流系統乙個狀態的結束
應用程式介面：表示由工作流系統發起的工作流系統和外部系統之間的互動。當使用者或系統管理乙個流程例項的執行時，會產生事件；流程定義中可以指定一段響應事件的可執行**邏輯，程式**能夠和組織內外部的其他系統通訊
監控介面：管理人員通過監控介面獲得流程執行記錄的統計資料；有時，執行記錄也可用於跟蹤審計
1.4 工作流引擎
英文全稱是：workflow engine，是指workflow作為應用系統的一部分，並為之提供對各應用系統有決定作用的根據角色、分工和條件的不同決定資訊傳遞路由、內容等級等核心解決方案。工作流引擎的幾個要素有：
1.4.1. 實體(entity)
是工作流的主體，是需要隨著工作流一起流動的物件(object)。例如，在乙個採購申請批准流程中，實體就是採購申請單；在公文審批流程中，實體就是公文
1.4.2. 參與者(participant)
是各個處理步驟中的責任人，可能是人，也可能是某個職能部門，還可能是某個自動化的裝置
1.4.3. 流程定義(flow definition)
是預定義的工作步驟，它規定了實體流動的路線。它可能是完全定義的，即對每種可能的情況都能完全確定下乙個參與者，也可能是不完全定義的，需要參與者根據情況決定下乙個參與者；
1.4.4. 工作流引擎(engine)
是驅動實體按流程定義從乙個參與者流向下乙個參與者的機制
流程定義的四個層次
流程定義的內容可以分為四個不同的層次：狀態（state）、上下文（context）、程式邏輯（programming logic）和使用者介面（ui）
l 狀態層
ø 所有的狀態表述和控制流屬於業務流程的狀態層；
ø 標準程式語言的控制流定義了必須被執行的指令的順序，由我們書寫的命令、if語句、迴圈語句等確定；業務流程中的控制流基本相同，但使用基本元素替代指令；業務流程中的基本元素是狀態；
ø 在流程中，狀態(或等待狀態)指定一種對外部參與者的依賴；狀態的意思就像「現在x系統或y人必須做某些事，在此等待直到參與者通知任務已完成的外部觸發」；
ø 流程定義中的狀態也指定了執行依賴於哪個參與者；wfms使用代表參與者的名字的資訊構建任務列表，這是wfms的通用特性；對於需要人參與的狀態，wfms必須在執行時計算出具體人，這樣的計算使wfms必須依賴於組織結構資訊；
ø 流程定義的控制流是一組和結合狀態之間關係的狀態；
ø 狀態之間的邏輯指定哪些執行路徑可以併發執行，那些是排它的；併發執行路徑用交叉和聯合來建模，而排它執行路徑用判斷和合入來建模；
ø uml活**經常被用來做業務流程建模；
ø 雖然活**是一種直觀和通用的表達，但在圖形表述上有乙個主要問題，就是沒有區分狀態和動作，都用活動來建模；
ø uml活**的第二個問題是在uml2.0版本中引入的，當多個遷移到達乙個活動（唯讀狀態）時，以前的版本指定為乙個預設合併，而在2.0版中指定為需要同步的預設聯合；
ø 只要對兩條構建語義作如下的變化，uml活**仍舊可以用來對業務流程狀態層建模：
ø 在用圖形表述業務流程時，只建模狀態層（狀態和控制流），不包括動作。這意味著圖形中的矩形都是狀態而不是活動；
ø 如果多個遷移到達乙個狀態，預設定義為不需要同步的合併；
ø 在流程執行過程中，wfms使用令牌（token）作為跟蹤流程狀態的指示器；當令牌到達乙個狀態時，被分配給wfms等待的外部參與者；
ø 外部參與者可以是個人、組織或者計算機系統，我們定義流程執行的執行人或系統為參與者（actor）；
ø 只有在wfms需要訪問組織結構資訊時，才將令牌分配給乙個參與者
ø 工作流系統通過分配令牌構建任務列表
l 上下文層
ø 流程上下文變數或簡稱變數，是與流程例項相關的變數；
ø 流程變數允許流程開發人員在流程例項的生命週期中儲存資料；
ø wfms具有固定的一組資料型別，也可以定義自己的資料型別；
ø 注意變數也可以儲存引用，例如可以引用資料庫中的記錄、網路上的檔案；
ø 工作流用於在組織內部的各種異構系統之間實現任務和資料進行協同；
ø 對於業務流程中人工執行的任務，wfms負責從其他相關系統，如sap、資料庫、crm系統、文件管理系統收集相關資料。在業務流程的每乙個人工步驟，只有相關的資料項從異構系統中收集和計算；
ø 通過這種方式，從不同系統來的資料被轉換並呈現為資訊
l 程式邏輯層
ø 動作是在流程執行過程中wfms為響應指定事件而執行的一段程式邏輯
ø 程式邏輯可以是二進位制或源**形式的、用任何語言或指令碼編寫的軟體片斷
ø 程式邏輯層根據指定事件的資訊將需要執行的所有軟體片斷組合
l 使用者介面層
ø 參與者通過向流程變數填充資料的事件，來觸發結束乙個狀態
ø 某些wfms允許指定哪些資料可以填充到流程中，以及如何儲存到流程變數中
ø 可以生成ui表單從使用者收集這些資訊
與wfms相對的可執行業務流程
l 當前bpm領域的新趨勢是可執行業務流程的集中規範
l xlang、wsfl 和bpml合併為基於互動（訊息交換）的bpel
l bpel在面向服務體系結構(soa)環境下定義，其前提條件之一是服務必須用wsdl宣告
l bpel規定了一套看作一種程式語言的xml語法，通過掉用wsdl中定義的服務整合控制流
l 可執行業務流程和基於狀態的wfms所使用的方法中，有三點主要的區別：
ø 基於狀態vs面向訊息：基於狀態的wfms以狀態（或者活動）概念為中心，工作流引擎維護狀態並計算從乙個狀態到另乙個狀態的遷移；另一方面，像bpel這樣的可執行流程以響應輸入訊息的定義為中心，可以將一組這樣的響應以及其他資訊看作乙個業務流程，這解釋了為什麼bpel是基於狀態的wfms的一些補充；例如，bpel響應輸入訊息的onmessage事件處理器，可以在狀態之間遷移時執行
ø 流程例項id vs訊息關係：可執行業務流程的複雜性之一是訊息關係；流程描述的一部分必須說明bpel引擎如何從輸入訊息中確定流程例項的標識，這必須基於輸入訊息的乙個資料項；而基於狀態的wfms為每個建立的流程例項生成id，客戶端可以在後面呼叫引擎api時使用這個id
ø 核心工作流引擎api vs抽象服務端點（endpoint）：基於狀態的wfms提供一組核心api，這意味著客戶端通過呼叫核心api管理所有流程例項的執行；在可執行業務流程中，每個流程表現為乙個服務，這意味著每個流程定義都有乙個不同的訪問點
工作流管理系統的概念介紹
什麼是工作流管理系統？工作流軟體，顧名思義，就是業務資訊資料在多個環節模組之間的流轉。按照工作流管理聯盟的定義，工作流指的是 業務過程的部分或全部在計算機應用環境下的自動化 在實際應用過程中，為了實現對業務過程的工作流管理，需要對業務流程及其各個步驟之間業務規則的抽象，概括，做成乙個統一通用的流程管...
工作流管理系統概念
為 了 實 現 組 織 目 標，有 關 業 務 活 動 依 時 序 或 邏 輯 關 系 相 互 連 接 構 成 業 務 流 程。在 業 務 開 展 過 程 中，文 檔 信 息 或 任 務，依 據 組 織 規 範 在 參 與 者 之 間 傳 遞 處 理 或 執 行。業 務 流 程 中，實 現 了 基 ...
工作流管理系統概述
一.概述 企 業在進行業務處理時，在進行公文審批時，都是以流程形式而進行的，在資訊化的過程中，企業 也將這些業務處理 公文審批的過程資訊化了，早期通常 是通過程式硬編碼的方式來處理這些業務 公文的流轉，隨著業務 公文的複雜的處理情況不斷出現以及需求的不斷變更，這種硬編碼的方式顯然已無法應對，這個 時...