There’s also a BPMN library in Erlang but not sure what it’s worth: GitHub - synrc/bpmn: BPMN: Business Process Model Notation ISO 19510:2015 · GitHub
href
MrDoops
How does the elixir community prefer model long running business processes? I’m talking typical business processes like Approval/QA, Submission tracking, etc. or scenarios where you want a Status field to work with and users who work out of buckets or lists of these tasks/records of a state. From what I’ve observed there are a few options:
- Classic CRUD: Relational database with some kind of Status/Stage enumerable field & state machine business logic around commands. This would probably reveal itself as a Phoenix/Ecto application running on Postgres.
- CQS: Can be CRUD in the background, but with more domain specific Commands and further decoupled business logic processing. Maybe a GenServer or gen_statem with Structs/Maps to model the state where persistence to a database is only a minor implementation detail?
- CQRS & EventSourcing: e.g. GitHub - commanded/commanded: Use Commanded to build Elixir CQRS/ES applications · GitHub
@StefanHoutzager How does BPMN or S-BPM fit into implementation patterns like above? Elixir being an Actor model language with great macro capabilities would suggest it’s a great fit, but I’ve not found very many resources for bridging the gap between this world of BPM, Pi-Calculus, the Actor Model, and Elixir. It’s a fascinating area, so it’s a bit surprising I haven’t found more discussion about it in the community. I’ve read the paper you linked in the other thread, but it’s still very speculative, are there any other resources you’d recommend?
2
StefanHoutzager
I have seen it before. I cannot conclude much from the description except that it (the documentation itself + at least the list of supported bpmn elements) is very incomplete. It might be a valuable starting point. It is not actively maintained.
It is not that hard to build a bpms yourself. Good modelers (browser-based) are available as open source.
0
StefanHoutzager
Answering tomorrow. The paper about S-BPM was not that interesting I concluded after writing some things myself.
0
StefanHoutzager
Someone who has written interesting, down to earth about DDD, µS, orchestration / the place of an orchestration engine & choreography, event driven architecture and more buzzwords is Bernd Rücker. See f.e. https://blog.bernd-ruecker.com/flowing-retail-demonstrating-aspects-of-microservices-events-and-their-flow-with-concrete-source-7f3abdd40e53 and associated links. Another interesting link is Complex Event Flows in Distributed Systems: Bernd Rücker Discusses Workflow Engines at QCon NY - InfoQ . Also worth a read: Is BPM Dead, Long Live Microservices?
Netflix has an orchestrator also: techblog.netflix.com/2016/12/netflix-conductor-microservices.html
I think you can extract answers to your questions from these links, if you still have questions I’ll try to answer them.
Erlang and the languages built upon it’s VM are used to build massively scalable soft real-time systems with requirements on high availability, so they are a perfect fit for an orchestration engine. Indeed the actor model is a good fit. I have not found a use case for macro’s yet while building my bpms.
1
StefanHoutzager
As you can see again there is almost no interest. I will stay amazed. As punishment I will not open source my project, hahaha. But serious: it almost for sure would not be worth the effort.
0
dimitarvp
By saying “executable workflows in JSON or XML”, do you mean like interpreted in real time? That sounds awfully slow and inefficient…
I have stumbled upon one organization in my career that seriously loved workflows and flowcharts. They fought with IBM Rational and a few others that supposedly translated digital UML diagrams to code, about ~16 years ago, and never had any half-semblance of success. So in my case I guess I am conflating BPM(N) with these older tools which were only a way to sell extremely expensive consultancies without actually delivering any business value.
In terms of more formalized processes, I personally would compromise a bit by re-molding some of my older messy imperative code in Ruby, Go, Java and PHP to state machine implementations and would change them to event-sourced paradigm where it makes sense (in truth, almost everywhere actually). But going all the way to executable flowcharts… I get UML war veteran flashbacks.
As a generic copy-paste inspirational quote: do your own thing and don’t care what people think. If Einstein listened to his critics we would not have his amazing body of scientific work today!
1
StefanHoutzager
Interesting reaction. 
I would say try it out for yourself, concerning performance. All these sloppy, expensive and awful engines work that way. It has reasons that I don’t want to explain again and again.
0
dimitarvp
Well it’s about scaling and future-proofing IMO. I can try it on my pretty strong desktop PC and equally as powerful MBP and it will probably work lightning fast but what about when you integrate that software in a huge org that relies on it as the backbone of all their operations – CRM, accounting, ERP, logistics etc.?
I worked with SOAP and WSDL (and a few higher-level protocols that assembled them in bigger operations) at their dawn and I have to tell you, things go out of control very quickly and very badly.
So please don’t take this as an attack. I am very definitely less experienced than you but so far have not seen any good evidence that such systems are sustainable and that they fix more problems than they solve…
0
StefanHoutzager
And I am not going to prove anything for anybody with such shallow interest and prejudices.
0