background
Workflow is an important part of the application development platform, which is used to realize the process processing function of the business system.
Generally speaking, it includes three parts, one is the workflow engine, the other is the process modeling, and the third is the derivative assistance, including the initiation process, my to-do, my completed, and end documents.
2020 Technology Selection
This is a field with a high degree of demand, so there are corresponding technical components. In 2020, technical pre-research has been carried out, mainly jbpm and activiti, as well as the flowable and camunda branches generated by the split of activiti. The development context is roughly as follows :
Origin : jBPM3 is a complete workflow system implementation for developers.
**Development: **jBPM4 introduces PVM to make it more scalable, and at the same time increase BPMS features, these features include support for BPMN, a business-oriented Web modeler and the addition of simple statistical analysis functions.
Split:
1. Tom Baeyens, the main creator of JBPM, had a major disagreement with his partners on the future architecture of JBPM, so Tom left Jboss and joined Alfresco, followed the code of jBPM4, and founded Activiti5. Activiti5 is an open source workflow system based on jBPM4. The integration with Alfresco increases its process visualization and management capabilities. At the same time, the innovative Activiti Cycle collaboration component supports the coordination between process-related personnel and strengthens the integration capabilities.
2. Jboss company completely abandoned the architecture of JBPM4, completely refactored based on Drools Flow, and launched JBPM5. Support BPMN, support BAM through the merger with Drools, and add support for process visualization through the content warehouse. Due to the abandonment of jBPM4's PVM, the scalability of the engine is compromised and jPDL is no longer supported.
fission
- Camunda, one of Activiti's biggest contributors, said that Activiti may be too constrained to Alfresco's needs for a document-centric workflow, ignoring the more general BPM platform that Activiti started with. Camunda announced that they are forking a new open source project from Activiti, that is camunda BPM.
- The core team of Activiti, because of disagreement with Alfresco on the future development direction of the project, chose to leave collectively and created Flowable.
- Activiti's own development is slow, and Activiti has stagnated in the past few years and has begun to eat its money. For the two new specifications of CMMN/DMN and more specifications of BPMN, the Camunda framework has been the first to respond and support them, but Activiti5 still cannot support these specifications, resulting in the loss of many users, and many users turned to the Camunda camp. The official codes of activiti6 and activiti5 have announced that maintenance has been suspended. Activiti7 is a gimmick. The core uses activiti6, and does not inject more new features into the engine. It just encapsulates some applications in the upper layer outside activiti, and develops towards the cloud. Version 6.0 is said to have left a large number of framework-level bugs, which were fixed in flowable.
According to the data collected from various aspects
, activiti is better than jbpm
, and jbpm is the first
to exit flowable.
Data 1:
From multiple dimensions, camunda is better than flowable
https://blog.csdn.net/qq_30739519/article/details/86682931
Information 2:
Flowable takes the 6.4.1 version as a watershed and vigorously develops its commercial version products. The open source version is not maintained in time. Some functions are no longer released in the open source version, such as form generator (form engine), synchronization of historical data to other data sources, es, etc. dmn is currently a semi-finished product, not as stable and easy to use as camunda, and has weak support for dmn specifications. Some components of the commercial version are commercialized, so the open source version is no longer maintained. Mongdb is also currently in commercial products, and the open source version is almost unusable. (Source: https://blog.csdn.net/qq_30739519/article/details/
Based on the above situation, the main branch of activiti has been desolate, and the former is chosen among the two branches of camunda and flowable. Integrating the native workflow engine was a lot of work. It took several months to realize the main functions, but the effect was not very satisfactory. The following is the design list for the integrated development at that time.
Backend workflow engine integration is not a problem at all for me. The biggest problem lies in the front-end modeling based on bpmn2.0. On the one hand, the front-end modeling components are complex and the data are vague. It is difficult to obtain the required methods and data to realize the functions. It takes a long time to try repeatedly, and finally some functions The method of back-end processing is adopted to solve it indirectly; on the other hand, activiti (camunda) is a large and comprehensive component that defines all aspects of process processing, so there are a lot of configurations that need to be set when process modeling, including some relatively obscure The name and concept are not friendly to modeling users, especially domestic users.
What impresses me deeply is the setting of the conditional edge. When process modeling is required, select the conditional edge, and then enter an expression on the form, such as ${contractMoney}>100 0000, which is not friendly and error-prone.
Current Technology Selection
After three years, restarting the workflow integration work again requires technical pre-research to see whether there have been new changes and better choices in the past few years.
After a brief look at the recent situation, the latest major version of activiti is still 7, and flowable is still 6.
As for camunda, I checked. The previous integration used 7.13, and now there is 8. However, 8 has replaced the new process engine Zeebe, which is no longer the activiti one. The most popular ones on the market are still based on comunda7 or flowable6.
Found an article published on March 31 this year, "Activiti5, activiti6, activiti7, flowable, camunda7, camunda8 process engine comparative analysis and selection reference" ( https://blog.csdn.net/wxz258/article/details/ 129884545 ),
the conclusion is as follows:
Brief summary: Domestic users who need to privatize the deployment process engine are recommended to choose camunda7. Most of the components are open source and can be used for free. The technology ecology is good and programmers can get started easily. Customers who have significant needs for process automation and high concurrency can consider choosing camunda8, but it requires a large amount of extended custom development, which requires high technical team capabilities. The domestic mainstream Yuncheng low-code platform uses camunda7 as the process engine. At present, camunda7 is gradually becoming popular in China, and it has the momentum to surpass activiti and flowable.
Another way is domestic self-research, and there are very few open source ones. Some have been doing it for a long time. Jinan gallops JFlow ( https://gitee.com/opencc/JFlow?_from=gitee_search ), unfortunately, it is vue3 The version uses Ant UI library instead of Element Plus, and it is not yet open source. Although the H5 version can also be used, it uses the old jquery and layui. If it is introduced into my platform, it will be too heavy.
The other one is https://gitee.com/gailunJAVA/dingding-mid-business-java?_from=gitee_search . This dude focuses on the workflow field. He is familiar with activiti, camunda, and flowerable, and provides support for various versions. It mainly works on the back end, and the front end is mainly supported by other open source projects.
Technical solution selection
In the process of technology pre-research, the idea of technology realization has been inspired. The main reason is to find an open source project modeled after the DingTalk process ( https://github.com/StavinLi/Workflow-Vue3 ). The technology stack also uses vue3+element plus, which is consistent with my current platform. The implementation effect is as follows:
This model is much more concise, intuitive and convenient than the process modeling based on bpmn2.0 specification that comes with camunda.
Using it as a substitute for process modeling, the main problem is that if the json output by the above component is parsed and converted into the data format agreed by the bpmn protocol. This piece is implemented by yourself, and the conversion is realized by calling the API of camunda.
The above solution selection is based on comprehensive consideration of various factors, based on the existing front-end technology stack of the platform (vue3+Element Plus), and the camunda back-end integration implementation that has been invested for several months, and provides a friendly UI for process modelers And experience, the final decision.
Workflow is a large component, and platform integration involves a lot of development. Next, we will open a sub-category of integration, which is still a weekly rhythm, so stay tuned.
Development platform information
Platform name: One Two Three Development Platform
Introduction: Enterprise-level general development platform
Design information: csdn column
Open source address: Gitee
open source protocol: MIT
open source is not easy, welcome to favorite, like, comment.