In terms of manhours what would it take to design and implement a https://zeebe.io worker that talks to ERPnext rest api for the purpose of command and control over ERPNext?
How can ERPNext be configured / modofied to emit events towards the zeebe platform?
Please comment on know how an approximate solution design could look like and send me a quote / estimate as PM.
Thanks in advance!
I don’t know anything about Zeebe, but ERPNext has a full webhooks system out of the box. Without coding, you can ping an external API on any doc event. Similarly, you can do quite a bit with existing ERPNext API methods or create new ones with Server Scripts and a few lines of code.
As far as I am concerned, ERPnext and zeebe is a match in heaven, so I suggest having a look, if time permits it and curiosity itches.
Thanks for pointing out the event “sourcing” capabilities of ERP next. I assume for proper emittance of custom messages, an addon/customization would be required.
ERPnext acting as a job worker to zeebe should conceptually as simple as writing a standalond command and control server that bridges available zeebe jobs to the erpnext api.
I’ve used ERPNext a fair bit with Huginn, which seems to be very similar in some ways and very different in others than Zeebe. My biggest complaint with Huginn is that each node is atomic, which makes it conceptually difficult to visualize and troubleshoot full workflows. It’s also clearly not designed for the kind of scale that Zeebe can handle.
I read through the docs a bit, and they made sense at an abstract level but I’m still not clear on what development is necessary for an actual workflow. What would Frappe need to do to be a Zeebe worker? Does it need to implement a specific API? Or does it just need to be available to make/receive API calls that can be defined on the Zeebe side?
I think it is relatively straight forward, in that an independently scalable e.g. go programm would do the longpolling against the command & control layer within zeebe and issue
/relay “to order” specific commands to the erpnext api.
What I like about zeebe is precisely its very elegant solution to the well defined worflow orchestration problem across system boundaries.
Combined eith openintegrationhub to sync the data plane across system boundaries, this becomes a truely powerful tool for business integration with and around erpnext.
I really like openintegrationhub… i am new to erpnext but this is something we want to try. Let me do a POC. I hope this will be helpful to others… @blaggacao do you have something specific in mind which events will be good to start with.
To add to the conversation
I also saw this repo Zeebe and ERPNext related repo in my search and started exploring the documentation before I can get started
Honestly, there’s not much to show! Set up Huginn as per standard instructions, then use Frappe’s REST/RPC endpoints and webhook triggers as per your use case.
Is there a particular problem you’re encountering?
Looking for alternatives to making workflows easier to work with
Were you successful with this?
project didnt take off
Just to update this thread, I’ve switched from Huginn to n8n for services integrations, and I absolutely love it.
There’s an ERPNext API node built in, which allows easy reading and writing of Frappe documents. There’s no ERPNext Trigger yet, which would automatically create and manage webhooks on the ERPNext side, but it should be relatively easy to create. In the meantime, the n8n generic webhook does the job.
Very interesting. Can you maybe post a simple instruction (in a separate post) so other users could follow how this was done and potentially build up on this/benefit from your experience?
Hello @peterg
I’ve used n8n previously along with ERPNext and I share your sentiment, I also love it.
However, I now install ERPNext as a docker image and not on native hardware, but have no idea as to how to install n8n along with it. Any thoughts?
I don’t know much about docker networking, but certainly what you’re describing is possible. If you’re on the same machine, I think it’s just a matter of exposing a local port. All this gets set when the docker instance gets started, I believe.