Well, that sounds nice to fend off my activist vocalism, but it does not really solve the problem at hand:
Firstly, I’m a singleton. So I would never dare to seriously offer to the public a half baked, unsupported dependency for them to build a business critical workflow engine on top.
We need a blessed and officially supported pathway to workflow managament.
build something “quick and easy” within the community’s comfort zone (= python/frappe)
Disclaimer: I’m not only a fierce adversary of NIH syndrom, but I also don’t have much sympathy for comfort zones as they tend to produce suboptimal outcomes.
So in the case that upstream maintainers want to exploit the powers of workflow managament for their open source erp suite, and only in that case, they have to decide between those two lines of thought.
As I said, we have to acknowledge that every line of code written is a (huge) legacy. If we take a closer look this is true for the second option (home grown solution) in even more than one direction:
Maintenance of the code itself
Improve the thought model behind the implementation: a feature is always also a promise to the users.
Having far less dedicated resources than the camunda community, the second point is going to be a constant catch-up game for which the erpnext community probably lacks resources to spare.
I’m actually pretty confident that the upstream maintainers will have the wisdom to make the right choice here (as they did by incoportating java based QZ Tray for host device access). As we can see from this thread, a demand for a solution seems to exist.
I’m not deflecting your activism. I’m suggesting that this…
…is a false and unproductive dichotomy.
Frappe is full of features that are implemented faster/better/stronger elsewhere. That doesn’t make them bad features. Frappe’s public-facing cms framework doesn’t come close to Drupal or Jamstack, for example, but it is nevertheless extremely useful to those whose needs are simple and who don’t want to manage a whole separate technology stack. For somebody who just wants to define a leave approval process, likewise, telling them that they need to load up a complex third-party orchestration platform is not a great answer.
Zeebe looks great. The next step, however, is not activism. The next step is a proof of concept. Frappe already has all the hooks you need, and I strongly suspect that little to nothing in the core code will need to change to make the integration possible. There’s no need to wait for a blessing.
Zeebe may look good. But have a look at the license:
Condition 2: Without limiting other conditions in this Agreement, the grant of rights under this Agreement does not include the right to provide a Commercial Process Automation Service.
A “Commercial Process Automation Service” is a service intended for or directed towards commercial advantage or monetary compensation for the provider of the service enabling third parties (other than the provider’s employees or Contractors) to deploy and execute Custom Processes or to access the Software via its APIs.
By just quickly reading, I would understand that no commercial support may be provided to clients by Frappe Consultants based on Zeebe, since they would provide a “service directed towards … monetary compensation” “enabling third parties [the customers of the consultant] to deploy and execute Custom Processes…”
Maybe I am wrong, but this should be considered first…
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.
In the case of Frappe/ERPnext I would suggest that the value of the product or service DOES NOT derive entirely or substantially, from the functionality of the Software (N8N).
Both n8n and zeebe seem.to operate under the faircode.io philosophy. (btw that’s a marketing invention of the creator of n8n)
However n8n seems quite a lot more restrictive than zeebe.
“Service” in “Commercial Process Automation Service” coincides with kubernetes’s usage of the term, as long as it is commercial (either public or private). This clause is meant to fend off big money competition against their own SaaS offering.
n8n is quite a bit more restrictive, which generally prohibits making money with their software.
And if workflow management is part of the requirements, that is has an identifiable price tag, then it is definitively of substatial value to the product or service offering (of an independent integrator).
n8n does compete in simplicity, though, while zeebe competes on industry standards: BPMN 2.0 — a slightly more concerted (much more than) marketing initative from the founders of camunda, among others.
It is hard to say who is the right go-to partner community for the ERPnext community.
Standards have certain appeal and conduct implicit long term guarantees, though.
Since time constraints on my end are not a shameful circumstance, I’m still actually looking into the option for somebody to step up. Sure, I would prefer to upstream the investment and put it at the source rather than a local and siloed reverberation of the cause with little long term upside potential.
Done that in the past. It’s utterly frustrating to my vision’s aspirations.
Yeah, conductor is the third elephant in the space. While there is also openintegrationhub.org which overlaps a little, but rather is in the data synching business.
What I find especially hard to beat with zeebe is the self documenting nature of litterally programming your workflows upon BPMN 2.0 graphically. In an organizational context an undocumented workflow is a non existing one (employee turnover, compliance, auditing, etc
).
I did not expose them initially, since I’m (persobally) already past the technology evaluation phase. I should have mentioned them as well. There is also luigi and apach airflow which have been used in similar scenarios and surely a lt more.
Elegant solution would be to capture/trigger the workflows based on erpnext events. An abstraction layer/adapters can provide integration to various workflow engines. And ability to provide a view into ErpNext as to what is happening with a given workflow. Is this possible?
Edit: Just want to thank everyone for this very informative discussion
That’s great, and it’s a really positive way to move this forward. If I can help in any way, I absolutely will, because I unambiguously see the longterm value. Up to now, I’ve done some workflow integration using Huginn/Zapier/n8n/myddleware, but none of it has ever felt like a great solution. It feels hacky and extremely prone to silent failure. At first glance, at least, Zeebe looks like a vastly more robust approach.
The challenge here, though, is familiar to open source. Frappe is complicated, and Zeebe is complicated. Both have relatively small expert user bases. Finding someone with deep knowledge of both going to be tough. Given that you are literally the only person who has ever posted the word “Zeebe” on this forum, I wonder if that person even exists right now.
Likewise, I don’t think it’s fair/accurate to accuse anyone in the Frappe community of Not Invented Here syndrome. Frappe is open and accessible from its very first design principles. The potential for interoperability with something like Zeebe (or Shopify, or Twilio, or Drupal, or Zapier, or PayPal, or microservices…) is fundamental to how Frappe works. It has taken a tremendous amount of work to make this possible.
The reality is much simpler: up to this point, nobody has put the time and energy into making a Zeebe integration happen. Nobody is opposed to it, but integration takes work and expertise that few have. Simple workflow management internal to Frappe has a legitimate place, and that functionality can coexist beautifully with integrations to external orchestrators. If both options exist, maintainers will be in a far better position to make good decisions about how much complexity Frappe wants to manage in-house.
To get that integration, the next steps are clear. Somebody with good technical knowledge of Zeebe needs to be able explain exactly what Frappe needs to be able to do to integrate. How do we get that specifications document?
my idea is to support integrating ERPNext with existing mature workflow tool, after I finished my DDMRP project, I can join force to do those workflow project.
It’s absolutely imperative to decouple the modelling of processes from the execution of those processes.
Think of the modelling of processes as writing the business logic in a graphical manner, with icons and other modelling artifacts adhering to a well defined standard.
Think of the execution of processes as giving this logic (the model) to an interpreter for subsequent execution. Any execution engine which conforms to that modelling standard can then execute the models. This, in theory at least, affords you to swap either the modeler or the engine for a more suitable alternative at some later stage.
The de facto process modelling standard right now is BPMN 2.0, which is also an ISO/IEC 19510 standard. https://www.omg.org/bpmn/ What I like about the Camunda Modeler (https://bpmn.io/) is that you can reduce or limit the collection of modelling artifacts to suite your requirements, ie initially only avail a minimal set of modeling artifacts, which will allow ERPNext to grow into accommodating more advance modelling over time.
The choice of an engine is then for all intents and purposes immaterial, as it reduces into a “black box” and only it’s API is of concern. Using the API, ERPNext can then schedule and invoke the execution of models, and receive status updates in return.
@EugeneP Please excuse my newbie-ness… What is the relationship between BPMN and Unified Modeling Language (UML)? Has one replaced the other? Or do they server different purposes? (I know very little about UML and less about BPMN but I am completely on-board with the need for modeling.
UML and BPMN serve very different modelling purposes. However, both are managed and cared for by the OMG group.
Simply search UML vs BPMN and you’ll have hours of reading!
In my mind, the biggest difference is that BPMN is executable! It is a programming language, for lack of a better analogy. In addition to the pretty picture of the conventional model, you also supply the necessary metadata for it to be executable on a process engine that complies with the BPMN standard.
To be accurate BPMN is not executable, it is a Modeling Notation.
Typically, it is compiled to Business Process Execution Language (BPEL), a horrible XML based language, that is recognized by all the big Java frameworks.
Because BPEL and BPMN are designed separately, BPEL can be generated from something other than BPMN and BPMN can be compiled to something other than BPEL.
@MichaelPinkowski A good way to understand BPMN is “programming in the large”, as opposed to Python, Java, etc that are “programming in the small”. BPMN defines processes that can take months and involve people as well as machines. Programming in the small happens in a single machine and aims to complete in milliseconds (vastly over generalizing).
UML can serve as an initial design tool &/or a post-development documentation tool. It rarely keeps pace with actual software development. Initiatives to generate code from UML, (MDA), have gained little traction, since users respond much better to “User Story” type functional specifications on the one hand, and developers dislike the generated code, on the other.
BPMN has gained traction because it is aimed at a narrower audience, business process professionals; it’s a great explanation tool that also has the depth to be a software (BPEL) generation tool.
When I was researching ERPNext and various other solutions, we considered building some django apps ourselves to implement our workflows. http://viewflow.io/ integrates well with Django and was one we looked at. Much more simplistic than Camunda but also maybe more approachable. Something like this might be a candidate for more direct integration (although now that I look I’m not sure about the licensing issues).
MOST of OUR business workflows will probably end up in a custom app anyway, which means we could add whatever workflow logic we need into it via Python. That will work but isn’t as elegant.
Yes you’re absolutely correct, and I was quietly expecting someone to correct me sooner or later. However I could not do it as well as you did, so I’m very happy you did.
My company has been involved in Business Process Automation (BPA), as the major driving force behind Digital Transformation, since 2010. From a business point of view, in other words, end users defining, using and executing processes, I always loose them when I talk too technical. There are many caveats, half-truths and dangerous analogies scattered throughout this post. Yet they may make sense to a particular reader, depending on which hat you wear, and at the same time cause another to cringe.
As I’ve mentioned in an earlier post, we integrate ERPNext into process automation for a number of our clients, but it’s too external as far as the end user is concerned. They have to open separate applications to model and view the execution statuses of those processes. To have an integrated process management capability within ERPNext would be a dream come true.
Imixs-Workflow is a human-centric workflow engine. This means the engine focus on a concrete business process executed in an enterprise by different participants. The main goal is to encourage human skills and collaboration in a model-driven way. In this way Imixs-Workflow can help to document the activities of a business process and to make it transparent for all parties involved. This is more about compliance guidelines and to ensure that operations at certain times can only be executed by authorized persons. For example something like an approval process according to the 4-eye principle. Typical uses case are long running business workflows like a purchase order, approving a budget plan, closing a contract or supporting a complex quality approval process.
This is different to most engines mainly trying to control your back-end tasks or even more technical engines controlling microservices, scripts, containers or CD processes.
The topic is unfortunately very confusing and I see very often that BPMN engines are compared with each other addressing very different concepts.
Loonflow is at the same level of Django-River, they are implemented in Django, but define most of the patterns needed for business workflows, with a big differenciation against Django-ViewFlow, they are basedly on top of configuration, instead of code
LiteFlow is an Simpler Workflow Engine, with many interest features, like integration with Redis and MongoDb, but lacks an web-api to handle, also, most of the workflows should be defined by code.
Like LiteFlow, PyFlow, is a extreme liteweight workflow engine, with support of distributed tasks in Python
These are the most interesting and resourcefull workflow engine (where some implement support to BPMN, or can be used to), that I have been collecting in the years.
