The addon allows you to describe business process steps right in the application using the integrated BPMN 2.0 modeler. Being a part of the application, it enables seamless integration with the runtime application parts and visual process customizing. For example, to specify which service method should be invoked at a particular process step, you just need to select a Spring bean name and a method from a dropdown list.
Users may interact with running process instances using process forms. For simple cases, you can declare input dialogs right in the modeler. Also, you can use screens based on CUBA Generic UI to create process forms of any complexity.
Features:
The embedded light-weight Flowable runtime engine. You are free to use the Flowable API directly, or you may use an API layer provided by the BProc addon.
Integrated BPMN 2.0 visual designer based on bpmn.io framework.
Integrated DMN 1.1 decision table designer for complex decision logic.
Two types of process forms:
Input dialogs that can be created at runtime in the process modeler
Design-time defined CUBA screens
Administrative screens for managing running processes provide a ready solution to:
view all running process instances
reassign user tasks
modify process variables’ values
investigate failed jobs
analyze processes execution history, etc.
API for working with business processes from the code.
Installation instructions can be found on add-on page at CUBA marketplace: BProc – CUBA Platform
That’s a good question. We had undertaken research before decided to move with Flowable. The main reason is the core team in Flowable are just the same people who developed Activiti (which was forked by the Camunda team a while ago). Staying with the core team makes Flowable a better choice, as we can be sure that they can support and improve their own BMP engine better. Camunda, form our perspective, is not improving the engine itself (at least times less), but doing a lot of tooling and features around it, which sometimes are much nicer than what offered by Flowable. You also can find more reasons here.
For the moment we decided to build BProc over Flowable. However, BProc was deliberately designed in a way to make it possible to move to Camunda with minimal pain. We keep a finger on the pulse of both frameworks and will see who will finally win the battle .
Thank you, Aleksey, for such detailed explanation. I suppose supporting both frameworks (even if they are using same engine) is rather costly, maybe community (Cuba or Camunda) helps with adopting.
You’re right. It seems that message throwing event is not supported by flowable. Only message catching event is supported. We’ll hide it in the modeler. Thanks for pointing out the problem.
Basically, instead of messages one can use signals, but with specific scope extension: <signal id="alertSignal" name="alert" flowable:scope="processInstance"/>
Signal with processInstance scope behaves similarly as a message does. For more sophisticated correlation a client can use Flowable API.
.