We are looking at Flowable(new but with history) and Camunda(established and with history). It seems flowable is more user friendly, but besides that, Camunda has 27000 ines of code vs Flowable 9000. Now that doesn’t mean anything, so I’d like to hear the advantages and disadvantages of each BPM. Thanks!
Hi,
How did you come to 9000 lines of code? Did you count the lines in the different modules of Flowable?
Both project have the same origin but have went their own way after that.
With Flowable 6 there are a lot of improvements to the core engine that are only available in the Flowable project, naming some:
- The execution tree is rewritten and allows for a lot more flexibility and predictability
- Pluggable persistency layer (open up possibilities for NoSQL storage and custom history info storage)
- Support for BPMN adhoc sub processes
You are right in saying that Flowable is relatively new, but it’s basically only the project name that is new. The code and the team behind it has been building this process engine for more than 7 years.
Best regards,
Tijs
3 Likes
Hi, tijs
I have being studying Flowable recently and I’m sure it’s an excellent BMP engine.
But Camunda looks like it has more improvement on performance and HA.https://camunda.com/products/performance/
I really want to hear your opinion about this article and whether Flowable has the same or better improvement.
Thanks
Hi,
Thanks for asking this question.
I think that I can say that it’s actually the other way around in regards to performance improvements and general engine improvement.
-
Camunda was forked from Activiti when we were still doing most of the Activiti engine work and they stayed on the Activiti 5 Engine architecture, while with Flowable we moved on to a new and improved version of the Engine, that we call the v6 engine. It has a lot of advantages over the 5 Engine because every execution and scoped execution is predictable and consistent now with v6. In v5 there are a lot of cases where execution reuse, inconsistent usage of executions for multi instance and parallel and inclusive gateways etc lead to an execution model that is unpredictable and inconsistent. In v6 this has been all refactored to an Engine that creates and deletes executions in a consistent and stable way. Each scope (process instance root, embedded sub process scope, multi instance scope) has its own execution, so that scoped variables are tightly bound to their scope as you would expect. This is just a very brief summary, and there’s a lot more to tell about the v6 Engine improvements.
-
All the items mentioned in the link you shared were already implemented by Activiti before the Camunda fork. So all these benefits are also present in the Flowable project and have improved there as well.
-
The Flowable v6 Engine has focused a lot on adding additional performance improvements, like doing counts on an execution and task level for attached jobs, identity links, variables etc to improve the deletion logic of these entities. There’s very smart caching implemented while doing process execution, to make sure that we only execute the SQL statements that are needed. Also, bulk insert and update statements were implemented to improve the performance of inserting lots of variables or activity instances at once in the database. You can have a look here for more performance info https://blog.flowable.org/2018/03/05/flowable-6-3-0-performance-benchmark/
-
Flowable has an async history manager option that executes the historic data calls asynchronously from the runtime data persistency. In this way you can store the historic data in ElasticSearch for example, but it also improves the performance of the runtime Engine. You can read more about it here https://blog.flowable.org/2018/03/13/async-history-performance-benchmark/
-
The last point is a personal opinion and that is that in the Flowable project we are very focused on the v6 engine architecture. When we did the first stages of the MongoDB implementation for Flowable (https://github.com/flowable/flowable-engine/tree/mongodb), we used the pluggability on the persistence level of Flowable to implement the MongoDB specific persistence logic. Camunda has made the choice to go with a completely new architecture for the Zeebe project and have to divide their development work between two very different engines. For me this means that with Flowable you have the benefit that our focus is on one Engine implementation and architecture and that all improvements and bug fixes are targeted at this Engine.
Hopefully I’ve been able to express the major differences in the approaches of the two projects and made my opinion clear to you. Let me know if anything is unclear or needs more explanation.
Best regards,
Tijs
5 Likes
I just wanna say: thank you for giving us such excellent product, cool !
1 Like
The execution tree is rewritten and allows for a lot more flexibility and predictability.
Could please elaborate on predictability. Do you mean that some times there will be flaws in execution? If so what are those cases
In the “v5” architecture (Activiti, Camunda, Flowable 5), the execution tree has all kinds of optimizations and reuse of scopes that makes it very hard to predict exactly what the process is by looking at its execution tree. There are some situations where a BPMN process will go into a loop and just not execute (unless you explicitly handle every diferent situation within the tangled optimizations).
With the (completed) v6 architecture, there’s no reuse of execution scopes and 1:1 mapping to BPMN and execution means these scenarios work fine.
Cheers
Paul.
Indeed flowable is good. What i think would make it better is a few clear tutorials and a more comprehensive documentation on BPMN. I mean like a document to teach BPMN using flowable and it’s functionalities. that would be awesome.
As of 2020, Are there any noteworthy Flowable improvements happened in comparison with Camunda?
There’s a release planned next week - look out for that, as it has some big improvements and new features. If you take a look at the Flowable release notes since we started, you’ll see what architectural improvements have been made - the v6 execution model, DB abstraction, async history, refactoring of job, runtime & history schema, native CMMN, dynamic injection, batch complex migrations… just a whole lot things.
Cheers
Paul.
1 Like
I’m afraid Flowable’s migration does not work as expected. Even using the same process definition to migrate a started process instance cause abnormalities: some tasks just disappear.
Here is another thread describing the same issue: Process Migration with Active Parallel Executions in Subprocess
I understand all the shortcomings of camunda 7 and understand what is written here, but every time I go to the flowable site I spend a lot of time and cannot figure out how to start using flowable. I sigh and continue to use camunda. Here is such an experience. This is the 3rd try.