ERPNext.com Frappe Cloud Support Partners Foundation Frappe School

Let Us Make ERPNext a professional workflow alternative for real business use cases, your ideas count

IMHO, Frappe is actually an orchestrator that can instantly deploy modules (like microservices in the container world of docker and kubernetes) after the schema is defined under developer mode.

Workflow across doctype is a need and frappe needs such feature. I think this should be part of core.

@szufisher I am interested in your PR, Please reopen :slightly_smiling_face:

I also agree that ERPNext should have a more feature rich workflow capability.

The current workflow capability lacks things such as:

  1. Better modeling of real-world process flows, rather than the state transition tables currently in ERPNext
  2. Delegation and escalation of a specific “task” to an individual user, rather than the current role based allocation rules

We use the Camunda Modeler to design our process flows : https://camunda.com/products/camunda-bpm/modeler/
This modeler is written in JS and is opensource, hence incorporating it into ERPNext should not be too difficult. It’s a JS library and it can be customized to contain only the most basic modeling features :
https://bpmn.io/toolkit/bpmn-js/walkthrough/ and also https://github.com/camunda/camunda-modeler

We also use Camunda as our process engine, with integration via the APIs in both Camunda and ERPNext. We do not integrate any other system other than ERPNext and find it’s unfortunate that we have to break out of ERPNext in order to manage rather simple process flows.

Camunda Modeler : https://camunda.com/download/modeler/
Camunda Engine : https://camunda.com/download/

3 Likes

No not necessarily. If you have complex requirements you could drive state changes using the API from an external orchestrator. Likewise, code can run on workflow changes in frappe with the current system and do anything you like (such as call external software etc).

Right now I’m mostly interested in some very BASIC things that would allow us (and by us I mean ME) to implement some simple non-automated workflows just in frappe through the UI. There are a handful of things that I think would make what is there now dramatically more useful. I attempted to reimplement some of our Jira based workflows (which are NOT complex) in ERPNext and couldn’t. Notably there doesn’t seem to be a way to communicate validation on state changes (ie to report to user “field X must be Y”), or do any actions on state change other than setting a single field value. If those were improved it would at least meet MY requirements. Not attempting to claim MY requirements are everyone’s!

If adding features also means providing a documented escape hatch out of those features amd into a rock solid workflow solution, that can be acceptable.

Since every code/feature is a legacy, not documenting and fulky supportinh the escape hatch might be a dangerous path. If a full blown integration wiith camunda/zeebe is documented (maybe even integrate the modeler as @EugenP suggested) it will become a lot easier for maintainers and the broader community to not fall into the falsehoods of feature creep.

I don’t really see this as an either/or question. Frappe’s design philosophy has always tried to maximize both internal power and external integration.

To that end @blaggacao, no escape hatch is needed. The way to bypass frappe’s workflow mechanism is to never set it up. I don’t know much about Zeebe implementation requirements, but given the scope of Frappe’s document API I have to imagine that linking an external orchestrator would be both possible now and relatively straight forward.

Precisely to avoid feature creep, the Frappe maintainers have lately been encouraging integrations as separate apps, maintained by the community. You seem passionate and knowledgable about Zeebe, which makes you the perfect person to get that work going!

1 Like

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.

This thread suggests mainly two lines of thought:

  • build on the shoulders of giants (nanos gigantium humeris insidentes)
  • 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. :wink:

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:

  1. Maintenance of the code itself
  2. 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.

1 Like

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…

Looks like somebody already started with n8n:

Their license says:

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.

Have you had a look at this:

https://netflix.github.io/conductor/

Comming from Netflix under apache license.

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 :smile:

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.

Just a thought…

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.

1 Like

@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.