基於 SOA 的工作流（WF）整合

轉自 http://www.ibm.com/developerworks/cn/webservices/1005_xiaojg_soawf/

 

什麼是流程

在面向服務體系架構（Service Oriented Architecture，SOA）中，流程是一個很重要的概念，其中業務流程管理包含了人工任務等，結合《面向服務體系架構（SOA）和資料倉儲（DW）的思考》（以下簡稱《 SOA 和 DW 》）以及《面向服務體系架構（SOA）和業務元件（BC）的思考》（以下簡稱《 SOA 和 BC 》）中關於共享庫、業務元件的設計，本文進一步給出了關於如何搭建企業級的工作流引擎，建立工作流管理元件的設計方法和實現。

流程和作業

流程（Process）是產生某一結果的一系列作業。流程是多個人員、多個作業按照一定的規則的有序組合。它關心的是誰做了什麼事，產生了什麼結果，傳遞了什麼資訊給誰。流程一定是體現企業價值的，沒有價值的流程是沒有意義的，因此每個流程都有其特定的目標。在資訊系統中，流程由若干作業（Operation）按照一定的規則組合而成，可以用業務流程圖來描述，其目標通過績效指標體現。作業是為了實現一個可定義的目標而進行的一系列活動，是業務流程的基本單元。在資訊系統中，作業的前端表現為若干介面，後端由若干個服務按照一定的規則組合而成。

在本文中，流程是指企業運作的所有流程，即企業的所有的活動都可以看作是一個個流程，流程是由若干個作業組成的，在 IT 技術上流程稱為工作流，作業稱為流程節點。

流程規範 XPDL 和 BPEL

在 IT 技術中，關於流程最早是以 WfMC 為代表的“業務流程開發商”， 工作流管理聯盟（WfMC）於 1993 年成立，他們主要擁護以 XPDL 作為描述語言來描述業務流程；之後是以 OASIS（Organization for the Advancement of Structured Information Standards，結構化資訊標準促進組織）組織為代表的，被 IBM，MicroSoft，BEA 所擁護的 BPEL/BPEL4WS 規範；之後向來以規範著稱的 OMG 組織也不甘示弱，聯合 BPMI 組織，獨闢蹊徑以 Notation Specification 為入口，首先推出了 BPMN 規範，進而推出了 BPDM（Business Process Definition Metamodel BPDM)。

2003 年 4 月 BPEL 規範提交給了 OASIS 更名為 WSBPEL（Web Services Business Process Execution Language）規範。此規範描述如何處理輸入的訊息，它不是一個關於業務流程規格化定義的規範。簡單的說，可以將它看作 XML 形式的程式語言，提供將 WSDL-Services 組合成控制流的能力。由於 BPLE 對於人工活動支援不好，為此進一步擴充套件為 BPEL4People（WS-BPEL Extension for People），從只能編排 Web 服務，擴充套件為同時支援對 Web 服務和基於角色的人工活動進行編排。

業務流程管理（BPM）和工作流管理（WFM）

業務流程管理 (Business Process Management BPM)，一般的定義是一套達成企業各種業務環節整合的全面管理模式。BPM 涵蓋了人員、裝置、桌面應用系統、企業級後臺應用等內容的優化組合，從而實現跨應用、跨部門、跨合作伙伴與客戶的企業運作。

根據 WfMC 的定義，工作流（Work Flow）就是自動運作的業務過程部分或整體，表現為參與者對檔案、資訊或任務按照規程採取行動，並令其在參與者之間傳遞。簡單地說，工作流就是一系列相互銜接、自動進行的業務活動或任務。

工作流管理（Workflow Management, WFM）是人與電腦共同工作的自動化協調、控制和通訊，在電腦化的業務過程上，通過在網路上執行軟體，使所有命令的執行都處於受控狀態。在工作流管理下，工作量可以被監督，分派工作到不同的使用者達成平衡。

在本文中業務流程管理（BPM），是指基於 BPEL 標準的業務流程整合，主要實現系統和系統之間的整合；工作流（WF）是指人工活動的業務流程，基於 XPDL 標準或者 BPEL4People 標準，主要實現人機互動的整合，目的是實現系統內部以及跨系統的流程審批。關於業務流程（BPM），當前有很多成熟的產品，不做過多介紹，本文以工作流管理（WFM）為主，進行設計。工作流是和績效緊密相關，每個崗位流程節點彙總在一起，在前端展示為個性化門戶，除了工作流的溝通之外還有訊息平臺實現人員之間的協同

回頁首

工作流管理（WFM）元件設計

企業可以看作是企業實體物件，包括組織、人員、產品等在不同的環境和條件下的不斷的運轉的過程，實體物件和運轉過程對映到資訊系統中，分別對應著資料（可以用 ER 圖描述）和業務流程（可以用流程圖、業務邏輯和業務規則描述）。資料和業務流程能夠全面反映實體物件及其運動的狀態。在現實社會中，實體物件的運動體現為一系列活動，在資訊系統中，活動表現為一個流程節點，實體物件通過一系列的業務活動直至最終完成任務，在資訊系統中體現為資料狀態的不斷變化，直到資料最終完成。

在《 SOA 和 BC 》一文中提到了關於基於 OSGi 的模組化的設計思路，工作流管理作為其中的一個公共元件的模組，如果是提升到企業級的公共服務平臺中，則是獨立的工作流管理業務元件，可以實現跨系統的工作流整合，以下結合《 SOA 和 BC 》的思路，進一步細化工作流管理模組（或工作流管理業務元件）的設計思路。

工作流元件的鬆耦合設計

傳統的辦公自動化或者協同辦公系統，要實現基於工作流的流轉，需要有兩個基本的功能：工作流引擎和自定義表單，有了這兩個基本功能就可以在一個系統中實現流程的流轉。但是如果要實現整合企業所有的應用（不管是什麼平臺、什麼開發商），特別是要將所有的業務全部整合到一個工作流中，就需要工作流元件提供一個鬆耦合的連線方式，將所有的應用整合在一塊，保證現有的系統都能最大程度的整合到統一的工作流中，從而實現統一企業的工作流。

結合《 SOA 和 BC 》的思路，將工作流元件作為一個獨立的公共元件，為了更好的實現和其它業務元件以及公共元件內部的不同模組之間的鬆耦合，工作流元件對外以 Web 服務的方式對外提供介面，通過 ESB 和業務元件進行呼叫。同時為了保證效能，可以將工作流引擎內嵌到業務元件中，通過類匯流排（API）進行呼叫。這樣既可以實現和內部業務元件之間的結合，也可以實現和應用外部的系統進行流程整合。從業務元件劃分角度來看，工作流模組可以作為獨立的業務元件，從方便管理角度來看，將其和其它的功能模組合併在一起，是公共元件的一個部分。公共元件模型如圖 1 所示：

圖 1. 公共元件模型－工作流模組

[ 注 ]

表單自定義功能是介面管理模組的重要功能之一。

本文中的工作流管理元件實際上是公共元件的一個部分

工作流元件和其他業務元件通過 Web 服務方式呼叫可以採用非同步和同步傳輸兩種模式。同步傳輸主要適用於兩個系統必須同時提交的業務場景，採用同步傳輸需要等待另外一個系統的反饋資訊，對提交 Web 服務的系統有效能的影響；非同步傳輸的方式主要適用於可以非同步提交 Web 服務的業務場景，保證了提交 Web 服務系統的效能，非同步提交的方式需要考慮接受服務的系統出現當機或者網路故障的情況下還可以準確無誤的將 Web 服務傳遞到接收系統。非同步傳輸一般通過訊息中介軟體完成。

關於鬆偶合的 Web 服務的呼叫順序在《 SOA 和 BC 》文中建議儘量採用觸發的方式進行呼叫，基於這種呼叫方式，業務元件對外只提供查詢或者寫入服務，而不會直接通過寫程式碼呼叫服務，實現業務元件的鬆偶合，這種呼叫方式同樣適應於工作流元件中。比如客戶註冊流程，一開始實在 CRM 系統完成的，但是如果隨著業務的發展，客戶註冊採用網上註冊，原來 CRM 系統客戶註冊流程的任務啟動就會發生變化，如果是採用的觸發的方式，僅僅修改流程的編排即可，而不需要修改 CRM 的程式。在工作流元件中，最好的一個實現方式就是由工作流元件進行流程的發起，如圖 2 啟動流程所示。

圖 2. 工作流元件的鬆偶合呼叫

為了實現鬆偶合，業務元件和工作流元件之間不進行業務資料互動，傳遞的僅僅是任務資訊。業務元件對外提供獲取資訊或者寫入資訊的 Web 服務，和普通的業務元件之間的 Web 服務沒有什麼區別，讀取資訊和寫入資訊是標準的業務服務，保證了為工作流使用的 Web 服務具有通用性。如果需要和工作流整合，僅僅提供一個特殊的 Web 服務“通知完成”將任務的完成狀況或者任務的基本資訊等傳遞到工作流元件，任務的基本資訊主要是為了痕跡化管理，將修改的資訊做一個記錄，便於未來的審計。通過這種模式實現業務資料和流程資料分離，工作流元件和業務元件不進行業務資料的互動，簡化了工作流整合的難度。工作流元件則提供啟動流程、修改流程狀態，啟動下一環節以及儲存任務基本資訊等 Web 服務。

為了使流程平臺具有良好的擴充套件性，如果工作流元件需要業務資料，比如需要根據業務資料進行判斷業務流轉，也是以 Web 服務的方式有業務元件提供一個標準的服務，通過 BPEL 實現，比如為了進行痕跡化，則需要對進行審批的內容進行儲存，通過 BPLE 呼叫查詢服務將資料儲存到流程資料庫中，其呼叫跟工作流引擎沒有關係。實現跨系統的流程流轉，也是通過 BPEL 的編排，通過呼叫業務 Web 服務實現。

工作流元件組成及和業務元件關係

作為公共元件的工作流模組主要包含三個主要功能：工作流引擎、待辦任務管理、工作流視覺化管理。工作流引擎是基礎模組，可以為所有的系統提供工作流引擎，實現工作流流轉的邏輯控制；待辦任務管理主要實現人機互動，提供一個統一管理的待辦任務管理，整合公共的工作流引擎以及企業已經存在的工作流引擎（如 OA），形成一個統一的待辦任務管理；工作流視覺化管理，主要用於工作流的視覺化展示，用於除了用於工作流定義外，可以實現流程監控、流程業務監控、流程導航等功能。

工作流管理元件和業務元件整合根據結合緊密程度可以分成三種：完全獨立的公共工作流管理元件，工作流引擎和業務完全隔離開，流程任務通過 Web 服務方式互動；內嵌的工作流管理模組，業務元件通過 API 的方式呼叫內嵌在業務元件中的工作流引擎，工作流引擎和公共的工作流引擎共享資料庫；公共工作流管理元件和內嵌工作流模組組合，工作流引擎有自己的流程資料庫，包含已有系統的工作流引擎有自己的流程資料庫，工作流引擎和業務元件緊密整合，通過 ESB 以 Web 服務方式或者通過資料匯流排和公共工作流引擎進行資料交換，內嵌的工作流引擎負責任務的處理，公共的工作流元件整合待辦任務。如圖 3 所示：

圖 3. 工作流模組內容及和業務元件關係

如上文所示，第一種方式是完全鬆偶合的；第二種方式易於開發，效能更好；第三種方式能夠整合已有的各種工作流引擎，適合於整合遺留系統。

工作流的流程節點型別

根據工作流元件跟業務元件的融合程度，可以將工作流元件和業務元件的關係分成以下幾種情況：

審批流程節點：直接和工作流元件整合，工作流元件中可以體現待辦任務，並帶有可以直接操作的表單（含帶有附件的表單），典型的例子是協同辦公中的公文流轉、單據審批等功能。審批流程節點是和工作流元件的耦合性最大，完全依賴於工作流元件工作。審批流程節點可以進行轉批、駁回等操作，詳細記錄流程相關的操作資訊。

圖 4. 審批流程節點帶個性化表單的鬆偶合設計

根據表單是否獨立，可以分成兩種實現方式，採用自定義表單或獨立開發表單。自定義表單中的資料來源有兩種，一種是由自定義表單直接讀寫資料庫（如上圖 1.1），一種是由自定義表單直接呼叫 Web 服務進行讀寫，業務元件提供 Web 服務，在自定義表單中進行展示（如上圖 1.2）。採用自定義表單的方式，和工作流元件結合緊密，不便於實現鬆偶合，為了實現更好的鬆偶合，可以獨立開發的表單，然後以 Web 服務的方式和工作流管理元件互動，使得表單和工作流引擎鬆偶合（如上圖 2.1），或者將工作流管理作為一個公共模組，內嵌到業務元件中，通過類匯流排（API）工作流引擎和業務元件整合（如上圖 2.2）。採用 2.1 方式能更加方便的元件鬆偶合的業務元件。

稽核流程節點：和工作流元件應用整合，通過 Web 服務互動，表單顯示格式固定，Web 服務可以攜帶稽核資訊，但是沒有個性化的表單操作，僅僅可以完成稽核確認功能。稽核流程節點可以進行轉批、駁回等操作，詳細記錄流程相關的操作資訊。稽核流程節點和業務元件之間是通過 web 服務互動的，因此是鬆偶合的，但是也限制了其應用，不便於直接操作業務元件的詳細內容。由於其模式簡單，適合於大規模使用，如訂單審批確認、領導審批等功能，（如圖 5－3.1 所示）。

圖 5. 不帶個性化表單的工作流

訊息流程節點：和工作流元件應用整合，僅僅提供待辦資訊，可以通過 Web 服務呼叫，根據查詢條件直接查詢本節點需要處理的任務，然後進入相應的操作介面進行操作，操作完成之後，任務狀態發生變化，待辦任務完成。通知流程節點僅僅是一個訊息通知，適合於大業務量的操作場景，可以實現簡單的業務整合，提高系統易用性，簡單記錄操作過程。（如圖 5－4.1 所示）

稽核流程節點和訊息流程節點差異主要體現在前者工作流模組為主，和工作流緊密整合，但是隻是簡單業務操作，後者則以業務元件為主，工作流簡單整合，但是卻可以完成複雜的業務操作。和工作流引擎模組無關，僅和待辦任務管理、流程視覺化管理模組相關。

訊息流程節點可以包含多種實現場景，由於和其它的業務元件是鬆耦合的，可以對整個系統的所有應用進行整合，主要包括：

• 通知流程節點：根據資料的狀態，由應用自動或者被動生成簡單的任務資訊，以通知的方式通知到工作流引擎，在待辦任務中僅僅提供待辦資訊數量，具體操作還是在原來的系統完成。自動生成通知資訊可以實時通知，但是需要原有的系統進行改造，被動通知則不需要原有的系統變化，僅僅是做一個資料查詢的介面即可完成。
• 預警流程節點：有預警模組生成預警資訊，將預警和流程結合起來，可以看到那些流程節點出現預警，並根據預警的級別，分成待辦任務、確認完成和確認瞭解三種型別。待辦任務需要啟動新的流程，對預警資訊進行處理（可以採用審批流程節點的處理）；稽核完成需要落實預警資訊的原因；確認瞭解則只需要瞭解即可。訊息和預警的差異主要是後者屬於異常的資訊。

導航流程節點：和工作流簡單整合，僅僅提供一個選單導航的功能，提高系統的易用性，沒有待辦任務資訊，簡單記錄操作過程，如操作人、時間、操作的功能，但是無法記錄具體操作了什麼內容。和工作流引擎模組無關，僅和流程視覺化管理模組相關。

人工任務流程節點：和工作流無關，僅僅為了完整流程而做的一個描述。為了進一步提升系統的易用性，可以在所有流程節點上（包含人工流程節點）增加說明文字，作為企業業務流程指導書。和工作流引擎模組無關，僅和流程視覺化管理模組相關。

通過以上分析，可以看到，為了搭建鬆偶合的工作流元件，可以採用通過服務匯流排（ESB）以 Web 服務方式或者通過類匯流排以 API 方式進行整合，搭建企業級的公共工作流元件。工作流元件和業務元件之間沒有直接的業務資料交換，工作流元件相對更加獨立；工作流元件包含了整合各種方式的工作流，特別是遺留系統的工作流引擎；工作流元件的適用範圍更廣，不僅僅是涉及流程審批，所有的業務系統都可以整合進來，建立一個企業的完整檢視的工作流，搭建了一個企業級的技術架構平臺。

回頁首

工作流管理（WFM）元件實現

工作流元件和工作流資料庫

如前文所示，工作流元件在應用方面主要包含三個部分：工作流引擎、待辦任務管理、工作流視覺化管理，在資料庫層面，主要包含兩個部分：流程資料和業務操作記錄，流程資料儲存企業所有流程的流程定義、流程執行狀態、待辦任務以及流程視覺化等流程本身的資料，業務資料儲存流程過程中的業務資料。由於業務資料結構多樣，為了保證對流程操作過程的詳細記錄，將所有通過工作流的業務操作資訊全部直接以 XML 方式存放到流程資料庫。如圖 8 所示：

圖 6. 流程整合平臺

基於 IBM 產品的實現

本文提到的整合平臺，基於 IBM 的產品共體系在實際搭建的時候需要包含應用伺服器（產品：WAS）、流程整合伺服器（產品：WPS，實現服務匯流排和流程編排）等，關於整合平臺的詳細描述，詳見《 SOA 和 DW 》一文中“基於 IBM 產品體系的實現”的描述。除此之外，本文中涉及到的內容還包括：工作流引擎、基於 XML 的資料庫、訊息中間等。

工作流引擎可以有多種實現方式，比如採用 IBM 的 WPS 或者 FileNet，或者浪潮 Loushang 工作流引擎等，本文以 FileNet 為例。流程資料庫採用 IBM 的 DB2 V9。

資料庫伺服器（IBM DB2 Enterprise Server，DB2）的 XML 主持

IBM^®DB2^®V9 整合了關係型資料伺服器的能力並進行了擴充套件，使得它能夠管理關係資料和 XML 資料，包括對資料的儲存，檢索，共享，確認等。這使得使用者可以擁有一個高效能，高可擴充套件性的平臺來方便的管理關係和 XML 這兩類的資料。pureXML 這個突破性的技術結合現有的資料管理技術可以帶給使用者所有期望從資料庫系統中獲得的功能特性。它提供高效能和高可靠性，並能夠在極大的減小管理成本的同時，提高可用性和效能。DB2 V9 實現了對 XML 資料的索引技術。通過建立索引，給查詢檢索提供很好的效能。如果沒有索引的存在，則任何查詢都要遍歷 XML 的整個樹形結構，其效率就很低了。

通過 DB2 V9，建立流程資料庫，可以有效解決多種格式的業務資料痕跡化管理帶來的資料儲存的問題，為流程審計提供資料。

工作流伺服器（FileNet）

FileNet P8 是 IBM 新一代的、統一的企業級內容和流程管理平臺，它包含廣泛的產品和服務，幫助使用者在面向服務架構（SOA）的環境中構建，部署，執行和管理企業的內容和流程。本方案中主要是採用 FileNet 的流程管理 (FileNet Business Process Manager) 功能。流程管理包含流程配置控制檯 (Process Configuration Console)，流程設計器 (Process Designer)，流程引擎 (Process Engine)，應用引擎 (Application Engine) 等產品和應用。

FileNet 的工作流具有分散式 (distributed)，可獲取性 (availability)，可調控性 (scalability)，安全，標準化的能力，可以有效的承擔公共工作流引擎的角色。

工作流模組實現舉例

以下以報銷流程為例說明工作流模組的使用，報銷單據憑證處理都是在財務系統完整的，但是財務系統一般不支援所有員工在財務系統中錄入報銷單據資料（如發票號碼、金額等），同時由於財務軟體是產品化的軟體，很難進行大的改造。因此實現每個員工填寫報銷單據，並由上級領導審批報銷單據，最後由財務進行稽核，需要一個報銷管理。報銷管理單據的維護、審批處理，資訊簡單，可以直接用表單定製和工作流管理模組定製出來，包括填寫報銷單據、直接上級審批、領導審批等流程節點，就像一般的辦公自動化系統實現的功能。

領導審批完成之後，啟動一個業務流程（採用 BPEL 進行編排），將單據資料自動寫入財務系統（只需要財務系統提供寫入單據 Web 服務）。由於財務系統無法進行大的改造，在財務審批、財務入賬環節，採用訊息流程節點處理方式，由財務系統提供一個查詢單據狀態的介面，這樣財務人員就可以在待辦任務中看到報銷單據的待辦，財務人員通過單點登入，點選待辦任務進入財務系統進行操作，報銷單據的填報者則不需要進入財務系統，在報銷系統中就可以看到報銷單據的整個流程的狀態，這樣既可以實現整合所有流程，又對財務系統本身不會造成大的影響。

圖 7. 報銷流程舉例

以上就實現工作流元件在資料庫設計以及基於 IBM 產品體系如何實現做了簡要說明，並以報銷流程舉例說明實現。

回頁首

總結

本文通過對業務流程管理（BPM）和工作流（WF）的分析，給出了一個企業級的工作流元件設計，擴大了工作流適用範圍，不再僅限於審批，而是擴充套件到所有的業務流程；提出了建立公共工作流引擎的思路，基於 SOA 的架構思想，整合企業流程；除了流程的整合，還對工作流和績效、審計、個人門戶和訊息之間的關係做了簡要說明。最後本文給出了工作流的實現思路以及基於 IBM 產品實現的產品支援。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-664056/，如需轉載，請註明出處，否則將追究法律責任。