原標題：activiti和jbpm工作流引擎哪個比較好？

在常用的ERP系統、OA系統的開發中，工作流引擎是一個必不可少的工具。之前在選擇工作流引擎時曾經在activiti和jbpm之間有過比較，當時做出的決定是使用jbpm，但實際開發過程中發現這個選擇是不合適的。目前我們改為選擇Activiti作為工作流模塊的引擎，理由如下：

1、Activiti擁有更簡潔健壯的接口

JBPM自從版本五后，便重啟爐灶，完全拋棄了JBMP4的代碼基礎，重新基于drools進行了實現。JBPM5，JBPM6似乎缺少一個合格的系統架構師，其接口設計匪夷所思，基本上是按照drools的接口再提供了一套JBPM接口，同名的接口，實現類不斷重復出現，代碼體系十分混亂。

一個典型的例子，同樣是查詢待辦事項，在JBPM中接口如下：

List getTasksAssignedAsBusinessAdministrator(String userId, String language);

List getTasksAssignedAsExcludedOwner(String userId, String language);

List getTasksAssignedAsPotentialOwner(String userId, String language);

@Deprecated

List getTasksAssignedAsPotentialOwner(String userId, List groupIds, String language);

@Deprecated

List getTasksAssignedAsPotentialOwner(String userId, List groupIds, String language, int firstResult, int maxResult);

List getTasksAssignedAsRecipient(String userId, String language);

List getTasksAssignedAsTaskInitiator(String userId, String language);

List getTasksAssignedAsTaskStakeholder(String userId, String language);

List getTasksOwned(String userId, String language);

List getTasksOwned(String userId, List status, String language);

上述接口設計者顯然沒有考慮接口的修改擴展需要，將各種復雜的查詢通過一個又一個的方法提供出來，這將導致今后增加一種查詢過濾就必須增加一個getXXX方法，丑陋之至，再看看Activiti的接口：

TaskQuery taskId(String taskId);

TaskQuery taskName(String name);

TaskQuery taskNameLike(String nameLike);

TaskQuery taskDescription(String description);

TaskQuery taskDescriptionLike(String descriptionLike);

TaskQuery taskPriority(Integer priority);

TaskQuery taskMinPriority(Integer minPriority);

TaskQuery taskMaxPriority(Integer maxPriority);

TaskQuery taskAssignee(String assignee);

TaskQuery taskAssigneeLike(String assigneeLike);

TaskQuery taskOwner(String owner);

TaskQuery taskOwnerLike(String ownerLike);

TaskQuery taskUnassigned();

TaskQuery taskUnnassigned();

TaskQuery taskDelegationState(DelegationState delegationState);

TaskQuery taskCandidateUser(String candidateUser);

TaskQuery taskInvolvedUser(String involvedUser);

TaskQuery taskCandidateGroup(String candidateGroup);

TaskQuery taskCandidateGroupIn(List candidateGroups);

TaskQuery processInstanceId(String processInstanceId);

TaskQuery processInstanceBusinessKey(String processInstanceBusinessKey);

TaskQuery processInstanceBusinessKeyLike(String processInstanceBusinessKeyLike);

TaskQuery executionId(String executionId);

TaskQuery taskCreatedOn(Date createTime);

TaskQuery taskCreatedBefore(Date before);

TaskQuery taskCreatedAfter(Date after);

TaskQuery excludeSubtasks();

TaskQuery taskVariableValueGreaterThan(String name, Object value);

TaskQuery processDefinitionName(String processDefinitionName);

TaskQuery withoutDueDate();

TaskQuery suspended();

TaskQuery orderByTaskAssignee();

TaskQuery orderByProcessInstanceId();

TaskQuery orderByDueDate();

long count();

U singleResult();

List list();

List listPage(int firstResult, int maxResults);

}

同樣是查詢待辦事項，Activiti中提供TaskQuery接口，可以設置各種查詢過濾，排序方式，最終通過list方法執行查詢，相比jbpm，它還提供了分頁查詢功能，雙方高下立判。

2、Activiti支持啟動引擎后隨時熱部署

JBPM存在一個軟肋，一個RuntimeService只能在啟動的時候指定bpmn資源，一旦啟動后便不再能夠去更新或者增加bpmn了，這會導致我們系統集成的困難，因為我們自然希望整個系統只有一個工作流引擎實例運行。Activiti則提供了Deploy機制，將bpmn資源的熱部署，熱更新都做了很好的支持

3、Activiti擁有更友好易用的Eclipse編輯插件和在線插件

從下圖就可以看到Activiti在流程編輯上的用心，以及JBPM在流程編輯器上的漫不用心：

4、Activiti依賴更少的jar包

Activiti依賴的第三方jar包較少，主要就是mybatics，而JBPM則依賴了一大堆的jar，從drools到繁雜的hibernate，再到自身拆分的零零散散的jar包，讓人不由覺得它是一個龐大的怪物。

5、Activiti擁有更友好的用戶體驗

雖然JBPM和activiti都是使用bpmn格式作為流程定義語言，但二者都相應地利用了bpmn格式的規范擴展了一些自定義的功能，根據這些擴展它們都提供了自己的綁定表單的方式。JBPM核心引擎完全沒有關于表單的任何抽象，它的工作機制是通過全局常量，流程變量，任務變量，這些概念十分技術化。

相比之下Activiti則更貼近實際的應用場景，它將為開始節點，以及人工任務提供了表單設置，用戶可以設置字段名稱，字段類型。通過Activiti的平臺可以根據這些設置去生成表單，但如果不使用其平臺只使用引擎的話，也支持通過它來表達與第三方表單的關系。這些表單設置的元數據信息也可以通過接口去獲取。

總結：

JBPM5，JBPM6使用drools規則引擎來實現工作流引擎聽起來是一個很酷的概念，但JBPM開發團隊顯然沒有很好地去掌控好整個架構的變化。因此選擇activiti作為工作流引擎至少在可見的幾年間都是正道，今后需要實現規則庫時，再單獨引入drools工具包，相信drools會是一個比JBPM靠譜的工具。

如果JAVA底子差一點的話可以用XJR快速開發框架，采用主流的Activiti工作流引擎，遵循bpmn規范，可實現XML、Json一鍵導入導出，以及添加了人員動態選擇、便捷式會簽設置、便捷式任務委托設置、添加自定義表單、自定義節點按鈕、動態變量選擇(包括會簽變量、按鈕變量、表單變量)以及各節點屬性優化，遵循以使用者為中心的優化原則，將整個流程的操作變得簡單、快捷，實現0基礎短時間可自由編輯流程模板。返回搜狐，查看更多

責任編輯：