談談activiti個人理解及基礎Demo環境搭建

Activiti是一個開源的工作流引擎，它實現了BPMN 2.0規範，可以釋出設計好的流程定義，並通過api進行流程排程。

Activiti 作為一個遵從 Apache 許可的工作流和業務流程管理開源平臺，其核心是基於 Java 的超快速、超穩定的 BPMN2.0 流程引擎，強調流程服務的可嵌入性和可擴充套件性，同時更加強調面向業務人員。

Activiti 流程引擎重點關注在系統開發的易用性和輕量性上。每一項 BPM 業務功能 Activiti 流程引擎都以服務的形式提供給開發人員。通過使用這些服務，開發人員能夠構建出功能豐富、輕便且高效的 BPM 應用程式。

使用場景：多人協作的（或者需要動態變動）的業務流程場景。

通俗易懂activiti使用場景理解：

（以請假為例：開始->請假->審批【部門經理】->審批【總經理】->結束）

在傳統的涉及到業務狀態相關的場景下，一般都採用在資料庫表中增加一個欄位status，來表示當前業務流程的狀態。每次有人申請請假，則在資料庫中記錄一條記錄，初始status設定為0。如果該請假事件已經被部門經理審批通過了則設定status=1，如果該請假事件已經被部門經理審批拒絕了則設定status=2。然後程式裡面判斷如果status==1則表示部門經理審批通過了，然後將請假事件流轉到總經理來處理。同樣總經理審批過了則設定status=3，如果此時總經理審批拒絕了則設定staus=4.這樣頁面展示時候就可以根據status來判斷當前請假事件處在什麼流程狀態當中。

使用activiti優勢？

如果使用activiti，還是以上述請假流程為例：

（開始->請假->審批【部門經理】->審批【總經理】->結束）

在activiti中設計一個業務處理流程（如下表格請假業務流程xml示例）：下圖xml檔案，描述了開始到結束及中間幾大任務過程。

activiti會自動生成23張資料庫表來記錄各種業務流程的狀態及操作事件。若以上述請假為例：第一步將該請假業務流程部署到activiti系統，當系統將該業務流程部署啟動時，則業務流程開始，即張三提出一次請假申請業務流程開始了，activiti在部署該業務流程時候，會自動記錄該流程中所有任務及當前處理到那個任務狀態。（相比於傳統的處理方式，activiti將狀態自動儲存到資料庫裡面了，不需要使用者去設計資料庫表欄位status來標識業務流程當前狀態）。傳統方式如果需要去取當前業務狀態，則自己封裝api從業務service層到資料庫Dao向資料庫取得status欄位值，即當前業務流程狀態。那麼activiti裡面該如何獲取當前業務流程狀態呢？activiti中封裝了一系列API（核心的都有幾十上百個，幾乎常用的業務場景全部已經封裝好了），可以去獲取當前業務流程的狀態。在傳統的方法中，如果一個狀態改變，需要流轉到下一個狀態，需要編碼人員，寫程式碼判斷狀態去流轉。而在activiti中，它靈活的事件機制能夠自動高效的推動業務流轉。

使用activiti缺點：

第一就是學習成本，activiti的簡單demo實驗不難。但是若想靈活運用activiti來適用於比較多的真實業務場景，還是需要不少的時間。至少需要熟練掌握activiti常用的核心API呼叫。

第二：由於activiti實現了BPMN 2.0規範，因此大部分業務場景下的業務流程都能支援，這樣就導致資料庫系統相當龐大（23張表），在大型系統中，如果採用activiti會導致後期業務流程過多導致資料庫資料太龐大，可能會影響到整個業務系統的自定製靈活性，包括一些資料庫訪問的效能問題，而且一般大公司一般有技術研發能力開發自己的類似能支撐自身業務的系統（個人猜想）。

activiti動態編排：能夠實時動態編排業務流程。第一次部署時需要部門經理審批接著則是總經理審批，某天公司有新制度，不希望總經理來審批，希望部門經理全權負責，那麼在傳統方法可能就需要去修改程式碼來改變流程了。但是在activiti中由於一切業務流程關係都用23張資料庫表進行了記錄。因此只需要重新編寫新的業務流程xml，然後重新部署，即可生效，靈活性就凸顯出來了。

activiti優秀的事件監聽機制。這樣就不需要像傳統方法那樣去寫狀態判斷程式碼，然後流轉。而activiti有其自身的事件機制，自動跟著你設計好的業務流程xml，來流轉。

（上述僅代表個人觀點，理解不正確地方感謝大家指正~！！！）