In the development of common ERP system and OA system, Workflow engine Is an essential tool. Before, there was a comparison between activiti and jbpm when selecting workflow engine. At that time, the decision was to use jbpm, but it was found that this choice was not appropriate in the actual development process. At present, we choose activiti as the engine of workflow module for the following reasons:
1. Activiti has a more concise and robust interface
Since version 5, JBPM has restarted the stove, completely abandoned the code base of JBMP4, and re implemented based on drools. JBPM5 and JBPM6 seem to lack a qualified system architect. Their interface design is incredible. Basically, they provide another set of JBPM interfaces according to the interfaces of drools. The interface with the same name, implementation classes, and code system are in confusion.
A typical example is to query to-do items. The interface in JBPM is as follows:
List<TaskSummary> getTasksAssignedAsBusinessAdministrator(String userId, String language); List<TaskSummary> getTasksAssignedAsExcludedOwner(String userId, String language); List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, String language); @Deprecated List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, String language); @Deprecated List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, String language, int firstResult, int maxResult); List<TaskSummary> getTasksAssignedAsRecipient(String userId, String language); List<TaskSummary> getTasksAssignedAsTaskInitiator(String userId, String language); List<TaskSummary> getTasksAssignedAsTaskStakeholder(String userId, String language); List<TaskSummary> getTasksOwned(String userId, String language); List<TaskSummary> getTasksOwned(String userId, List<Status> status, String language);
Obviously, the above interface designer did not consider the modification and extension needs of the interface, and provided various complex queries through one method after another, which will lead to the addition of a query filter in the future, so we must add a getXXX method, which is ugly. Then look at the interface of 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<String> 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<U> list(); List<U> listPage(int firstResult, int maxResults); }
It also queries to-do items. Activiti provides the TaskQuery interface, which can set various query filtering and sorting methods, and finally execute the query through the list method. Compared with jbpm, it also provides the paging query function, with both sides making decisions.
2. Activiti supports hot deployment at any time after starting the engine
JBPM has a weakness. A runtime service can only specify bpmn resources when it is started. Once it is started, bpmn can no longer be updated or added. This will lead to the difficulty of system integration, because we naturally want the whole system to run with only one workflow engine instance. Activiti provides deployment mechanism, which supports the hot deployment and hot update of bpmn resources
3. Activiti has more friendly and easy-to-use Eclipse editing plug-ins and online plug-ins
From the following figure, you can see the intention of Activiti in process editing and the careless intention of JBPM in process editor:
4. Activiti relies on fewer jar packages
Activiti relies on fewer third-party jar packages, mainly mybatics, while JBPM relies on a large number of jars, from drools to complex hibernate, to fragmented jar packages that are split by itself, which makes people think that it is a huge monster.
5. Activiti has a more user-friendly experience
Although jBPM and activiti both use bpmn format as process definition language, they both extend some custom functions by using bpmn format specification, and provide their own way of binding forms according to these extensions. JBPM core engine does not have any abstraction about forms at all. Its working mechanism is through global constants, process variables, task variables. These concepts are very technical.
Activiti, by contrast, is closer to the actual application scenario. It provides form settings for start nodes and human tasks. Users can set field names and field types. The platform of activiti can generate forms according to these settings, but it also supports the expression of relationships with third-party forms without using its platform and only using the engine. The metadata information of these form settings can also be obtained through the interface.
JBPM5 and JBPM6 using the drools rule engine to implement the workflow engine sounds like a cool concept, but the JBPM development team obviously does not have a good grasp of the changes in the entire architecture. Therefore, choosing activiti as the workflow engine is the right way for at least a few years. When we need to implement the rule base in the future, we will introduce the drools toolkit separately. I believe that drools will be a more reliable tool than JBPM.
If JAVA base is a little bit different, XJR can be used for rapid development framework, mainstream Activiti workflow engine and bpmn specification can be used to import and export XML and Json, as well as add dynamic personnel selection, convenient countersign setting, convenient task delegation setting, add custom form, custom node button and dynamic variable selection (including countersign variable and press Button variables, form variables) and the attribute optimization of each node follow the user-centered optimization principle, which makes the operation of the whole process simple and fast, and realizes the free editing of process template based on 0 in a short time.