1. 引言
由於Activiti面世出現也比較早，加上是Java領域的開源工作流，自然而然也被很多企業個人拿來使用，有做做簡單的或有深入的二次開發使用的。作為一個資深的BPM領域技術專家，貌似如果沒有研究過Activiti的話會顯得不專業，所以我們也免不了俗，自然而然也是對Activiti做過剖析。
關於Activiti的選型還是有必要說一說，從純技術角度上說，不從所謂商業角度，因為那不是討論的范疇。所以正好以此為契機把它整理成一篇全面一些的文章，就想着也提供給有需要的技術達人在Activiti選型時的參考。Activiti本身有很多優秀的地方，但也有很多弊端，談論過程中如果您有不同的觀點我們也是很歡迎接受的，我們也是從某個角度談談聊聊，僅作參考。
2. 什么是Activiti
Activiti是Tom Bayen（jBPM創始人）自2010年離開jBoss加入Alfresco公司后的又一力作：第一版在2010年5月發布，當時僅支持最簡單的流程處理，之后的版本陸續完善了對BPMN 2.0規范的支持。其核心是使用Java開發的。其前就是JBPM。
早年關於研發工作流的廠商也少，而Activiti開源早，所以占領的知名度的先機，但目前國內自主研發的流程引擎也越來越多，而且更加符合中國國情的項目，甚至遠遠越過了Activiti。易用易上手。容易擴展，即拿即用。
2.1. Activiti核心數據庫表
Activiti的后台是有數據庫的支持，所有的表都以ACT_開頭。
ACT_RE_*: 'RE'表示repository。 這個前綴的表包含了流程定義和流程靜態資源 （圖片，規則，等等）。
ACT_RU_*: 'RU'表示runtime。 這些運行時的表，包含流程實例，任務，變量，異步任務，等運行中的數據。 Activiti只在流程實例執行過程中保存這些數據， 在流程結束時就會刪除這些記錄。 這樣運行時表可以一直很小速度很快。
ACT_ID_*: 'ID'表示identity。 這些表包含身份信息，比如用戶，組等等。
ACT_HI_*: 'HI'表示history。 這些表包含歷史數據，比如歷史流程實例， 變量，任務等等。
ACT_GE_*: 通用數據， 用於不同場景下，如存放資源文件。
3. Activiti優點
1、 最大的優點就是免費開源，這也是很多人選擇的原因
2、 小項目中應用簡單的串行並行流轉基本能滿足需求。
4. Activiti存在問題
4.1. 節點定義概念不同
節點理解不同：在Activiti中將節點理解為腳本任務，用戶任務等，這樣表達有點讓人容易產生理解偏差，通常在我們的理解里如果是一個任務那么任務就是一件具體的事情，比如讓一個人去挑水，就是一件很具體不可再細分的事情，所以叫把節點叫用戶任務是不太准確，因為節點來說必然是可再細分的對象，有可能多個人處理，或者其它可再分的情況。
在微軟的ＷＦ工作流中把節點叫作“活動”Activity（活動），我認為是比較好的，因為一個節點就是一個集體活動的事情，一個流程是由一個個集體事務（活動）組成一個流程，流程是最大集體事務，分解成一個個節點活動，那么活動是由人員參與進來的，多個人參與一個活動共同完成這個活動。
這里談的其實涉及到表達的問題，其實都是一些看法和思考，采用什么“粒度划分”，采用哪個名詞表示從中國式的流程來看，個人認為將節點使用“活動”來表達表示可再分，任務僅僅就表示一個任務已經是最細顆粒度不可再分為更好，更易理解。
思想定了就會影響設計，通常在設計代碼寫法上也會把這種表達用來命名。
4.2. 缺乏詳細的節點實例和任務實例關系軌跡，缺乏可“追溯”性
缺少節點實例軌跡數據的持久化，Activiti運行時緊緊圍繞act_ru_execution這張表來工作，此表也是整個流程引擎的運行核心表，執行時是一個樹型表，這張表就是節點運行實例的過程，而且使用PARENT_ID_來從一個節點到多個節點的過程，只是僅僅有一個Parent_Id_來維護是不夠的，因為我們知道關系有可能這是樣的正向生成的樹，也有倒生長的樹：
如上圖：E到F，G 是正向成長的，而F,G到H是倒掛的樹，雖然上圖有點簡單，但意思也能表達到，就是正向樹與倒向樹時，僅有一個ParentId是不能滿足的，當Activiti倒向樹時這個表的數據相對會復雜很多，對於這情況情如果你不能很精深理解Activiti或者因二次開發功能上的需求強制使用代碼來修改這張表，那么將會埋下不少的“坑”，給將來程序留下不少隱患。Activiti對於這表的執行過后會進行刪除數據，節點完成一個就會刪除一條數據，也就是節點實例數據並不持久保存， 執行完就刪除掉還節點數據庫容易，其實這樣問題又來了，駁回怎么辦，這也是Activti對駁回的支持很弱的原因，幾乎也在告訴你不好意思，我們國外沒有駁回的概念。通常辦法就是在節點上做事件切面然后記錄下來，但往往記錄的也只能是節點定義Id之關的過程，並沒有實例緊密性的關系層次記錄。
二次開發住住因業務要求，中國式的流程審批的要求，對此表的修改估計是很多基於Activti為基礎開發的工作流必不可少的事情，如果是正向樹通過刪除或修改數據來改變流程的流轉相對危險沒有那么高，如果是一個倒掛樹的模型時，那將會很麻煩，同時不可預見性的概率將增大。
比如下圖模型。
同時Activiti缺少任務實例軌跡（此任務並不是Activiti對節點叫任務的表達），因為業務過程往往需要有追溯，工作流的好處正因為有流程的理念並有“追溯”明確落到到人的責任痕跡，所以精確清晰的“追溯”是必不可少的，需要知道A任務是由哪個任務傳遞過來的，知道從哪里來然后又去了哪里，哪些人參與了，發生了什么事情。
缺乏詳細的軌跡也是導致Activiti先天關於駁回功能的脆弱性，當然強制擴展軌跡記錄也是做得到，只是所記錄的也並不是完全正確。Ativiti的執行過程是必須依懶流程圖的，如果圖上沒有畫線是不能執行的。
4.3. 擴展需要與很多的Event來實現
Activiti需要經過大量的擴展才能應用起來，直接從官網下載下來的Activiti要達到企業級應用還需要一段痛苦的改造之路要走。Activti的擴展非常依懶事件監聽和AOP切面事件，其中一個常用的擴展之一就是在執行過程修改Activiti的源代碼，然后在網關節點的代碼中廣播各種事件通過SpringMVC來捕獲這些事件，交給事件來進行流程執行過程中的數據進行記錄，從而達到擴展的目的，從表面上來看似乎問題不大，但從日積月累后你會發現，整個執行過程就像一個GOTO語法，代碼執行到路亂跳，非常的不好維護，可讀性也差，一是維護人員的技術門檻非常高，二是越到后面代碼越難維護。久而久之會把項目拖跨。
4.4. 二次開發難度大，門檻高
要真正把Activti用好的話，其實還需要做大量的開發封裝，首先得對Activiti有進行學習研究，理解透了才能進行改造。
Activti最明顯的一個地方就是事件機制，簡單來說把Activti執行過程理解為一條直線，這條執行直線上你要做很多的AOP攔截，對這個攔截進行事件拋出，然后自己再捕獲這個事件進行擴展開發。如下圖：正如下圖所示，AOP是非常好的設計思想，只是其實一個核心邏輯通過大量的AOP來擴展后達到核心運行邏輯這勢必數據容易導致混亂和數據的脆弱性，使用過度事件廣播來達到改造的目的，而且事件之間還存在相關聯。
5. 總結
Activti的學習價值比較高，是工作流入門的好教材，可以學習里面好的代碼風格和思路。但是要拿Activiti做到中國式的企業級應用門檻和難度很高。想用Activiti來做企業應用，還需要經地大量的改造，本文提到的缺點僅僅也只是一部份，實際中碰到的問題將更多。
6. 推薦學習資料
自行百度搜索WFMC工作流標准聯盟的相關文檔