摘要：開發項目管理軟件中很多業務都有一級審核、二級審核甚至多級審核機制。近期，在項目管理軟件迭代升級的需求分析過程中，客戶業務活動審核機制調整了多次需求，也出現了系統流程與業務耦合性增強的問題，對老版本中多套臨時表的維護越來越困難。在這種背景下，對開源工作流管理框架進行了研究，Activiti6.0在技術選型中脫穎而出，繼而又對Activiti6.0是否能夠實現具體項目的業務要求做了研究。

關鍵詞：Activiti6.0；BPMN；工作流；項目管理軟件

項目管理軟件沒有普及時，相關人員在項目管理過程中，一部電話加上堆積如山的文件是許多辦公桌的標配，流程審核是傳統手工遞交紙張的方式，逐級找領導簽字，效率低下。隨著PC辦公時代的到來，辦公人員只需要在項目管理系統中填寫工作內容，系統就會按照定義好的流程自動執行，各級審批者可以登錄PC系統，看到工作內容再進行相應的審批管理操作。辦公桌上干凈了許多。技術總是不斷在更新，人們的需求總是不斷增加。項目管理軟件也需要不斷做出迭代升級，如何實現業務與流程的分離？是不是可以將流程從業務中單獨剝離出來做統一的流程管理？基于這些問題筆者開始對工作流管理框架展開研究，以供讀者參考，共同完善。

工作流：對工作流程及其各操作步驟之間業務規則的抽象、概括、描述。

工作流程圖如圖1所示。一個比較形象的比喻是：工作流就像是列車的軌道，而所要執行的對象像是一輛自動運行的列車，只要列車啟動，它就能沿著軌道一直走到終點，其

中的節點就像是列車到達終點途中所要經過的火車站，它會告訴火車下一站是哪里，然后火車就往指定的下一站駛去，一直這樣開到終點站。

BPMN規范的發布是為了讓業務流程的全部參與人員對流程可以進行可視化管理，提供一套讓所有參與人員都易于理解的語言和標記。2011年1月發布BPMN2.0規范。我們首先要熟悉BPMN定義的每個元素代表的含義。使用BPMN2.0的目的是建立簡單并且易懂的業務流程模型，但是同時又需要處理高度復雜的業務流程，因此要解決這兩個矛盾的要求，需要在規范中定義標準的圖形和符號。

BPMN定義了基本元素。每個元素均有自己對應的圖形。除了基本元素，還有很多在其基礎上的子元素。最常見的網關，子元素為排他網關、并行網關、包容網關等等。

常見的工作流有Activiti、OSWork?ow、JBossjBPM、JFlow、FixFlow等。怎樣的流程描述文件可在不同的工作流中使用？除了圖形定義。一份用XML語法標準定義，依據BPMN2.0標準的流程描述文件，就可在不同的工作流中使用，只要該工作流符合BPMN2.0規范。特別標記的是，除了BPMN2.0標準的元素及其屬性外，工作流的供應商還可以在不改造已有屬性的基礎上，增添額外的屬性，但是增加的屬性不能與已有的屬性產生矛盾，還需要簡易易懂。比如：Activiti擴展的屬性，屬性名稱統一用“ctivity；”開頭。Activiti；class=“com.bestpay.DemoService”。

基于老版本維護越來越困難，筆者進行了開源工作流管理框架的研究。市面上開源工作流引擎框架有很多，例如：OSWork?ow、jBPM、JFlow、FixFlow、Activiti等。在技術選型中，主要遵循的原則是“主流，適用，簡單”。

Activiti6.0是在jBPM版本從1到4的基礎上開發的，是5.0的升級版，滿足BPMN2.0標準。很“主流”：Activiti6.0用戶多，文檔豐富，技術經歷市場已經成熟，網上社區強大，很多網站還有專欄討論，學習周期相對較短，界面簡單，有很好的發展趨勢；很“簡單”：可控可駕馭，可擴展，輕量級。Activiti6.0支持大部分工作流流程，少數工作流流程需要進行二次開發；很“適用”：滿足我們對軟件的各種需求。

3 Activiti
Alfresco軟件在2010年5月17日發布Activiti，它是一個業務流程管理（BPM）框架，它是覆蓋了業務流程管理、工作流、服務協作等領域的一個開源的、靈活的、易擴展的可執行流程語言框架。Activiti基于Apache許可的開源BPM平臺，采用了寬松的ApacheLicense2.0開源協議。創始人TomBaeyens也是jBPM的創始人，2010年，TomBaeyens離開了JBPM同時加入到Alfresco公司。2010年的5月17日，TomBaeyens發布了第一個Activiti版本，即5.0.alpha版，之所以把Activiti的第一個版本定義為5.0，外界猜測也許是為了讓它更像jBPM4的延續。

在Activiti中，流程引擎的實例對象是ProcessEngine