I want to replace a proprietary external solution with Flowable in the near future and have long watched this project from the Activiti (and jBPMN) days.
My use case, simplified, considers of a JEE platform that allows external clients (written in JavaScript) to run custom workflows on the platform.
Considering the client is communicating over our REST API using JSON, it seems a bit awkward to require our client devs to write their (rather simple) workflow in full blown BPMN XML notation.
I could not find an easy JSON based alternative to BPMN, only some backing up of my point in an older BPMN blog post at long-running.net.
I have found a promising looking JSON Converter in the Flowable sources, however, but could not find any examples yet or time to try it out, is this the one I am looking for, maybe?
What’s the official stance on this and what would be the best way to go about providing a more lightweight way for simple workflows, following the clain “constantly pushing the boundaries forward”?,-)
The web modeler also works with JSON and we transform it to BPMN XML with the flowable-json-converter. But this JSON format is definitely not easier than the BPMN XML format. Would you not use a web modeler tool or Eclipse Designer to model to process definitions instead of writing them by hand?
Thanks for the clarification @tijs I also saw this in the web modeler code and suspected that,-)
Valid point regarding using visual tooling, this is definitely planned for more complex applications, but we often have simple usecases / workflows with only 2-3 steps where we actually only trigger an external script and have input, output and maybe in-between forms. In this case it would still make sense to use Flowable imo because:
it provides a standardized easy way to define process variables using a standard notation, avoiding all the parsing and handling ourselves
it leaves enough room for extending the workflow if it gets more complex over time
we can use a unified workflow solution for simple and for more complex scenarios.
So, XML in this case looks a bit over-blown still, so I might even provide a simple translator service for REST clients to send us a simple JSON definition and the server programmatically creates a workflow out of it, but I’d rather have a standard format instead of rolling my own.
Ok understood. We have no plans yet to create a simplified JSON format. If you have ideas on the format then we can look if we can adopt it in the Flowable project as well.
thanks for the pointer @tijs, looks very interesting, here’s a link to the Netflix Conductor docs with more context regarding the definition and concepts of workflow, task, worker etc.
Coming from a strongly typed (Java) background, I always miss type information (e.g. for the “inputParameters”), but that’s a bit of a culture clash when going the JSON route, I guess, and there’s still no widely accepted collection of common types (although more recent serialization libraries like Apacha Avro or Protocol Buffers seem to have a common understanding here, though).
@tijs sadly my Christmas present was a heavy respiratory infection, so I’m only back now…
In the meantime, I also found out about AirBnb’s Airflow, which also provides a simple workflow definition, albeit in Python code form (“code as configuration”), and the entire framework is bound to Python.
I just list it here because it has really cool integrations / plugins, which could provide some inspiration for us…
So I think the JSON that Conductor uses is perfect for what I was aiming for in this thread, any chance to get this in 6.1?:=)
This leaves only one remaining issue: what about the data flow?
See also this blog post about dataflows being a bit neglected in workflow frameworks.
As far as I have gathered from the forum, passing variables around the workflow (between steps) is not quite so easy as I had hoped, what is the preferred way (if any) to do it in Flowable?
I’d expect something like a WorkflowContext where I can store, update and read process variables…?
The JSON definition of Conductor could work indeed. Is this something you want to contribute?
I’m not sure if I understand your question about passing variables. I think Flowable uses a very simple, but powerful approach for this. Variables can be set on and retrieved from the DelegateExecution instance that is passed to every service task (like in the JavaDelegate execute method). So there is a kind of process instance context that you can use to store, update and read process variables.
Sounds like a plan… we’ll have some prototyping and discussion in the team but I’d really love to contribute to this, even in my spare spare time…
Regarding variable passing, this sounds like all I need, will have to prototype and find out…
@tijs doing spec work for this now and we’re evaluating this approach and Flowable itself - what I still wonder is how Conductor defines the actual flow, e.g. connections/dependencies between Tasks (or workflow steps).
It seems they only do it indirectly by specifying input/output - would prefer to define task dependencies though.
And what about notifications, parallel flows, decision points etc. ?
while prototyping, digging deeper in the powerful concepts and features supported by BPMN2.0 and the Flowable API showed that it is not really feasible at this time to develop a JSON based workflow definition; also the XML produced by the Flowable modeler is really compact and readable, even with our workflow - what a positive surprise:)
We aim to please and surprise. Let us know as you make progress - it’s always good to hear what people have done with Flowable, helps motivate us and the community.
Let me think about this and prepare a proposal, hopefully as a Christmas present…,-)