I would like to add a BPM engine (say: Flowable, jBPM, Activiti, Camunda, or such) to a Spring (Boot), JPA-based Kotlin project.
My main worry is that most of those engines seem to be based on a loose, dynamically typed process definition and an even looser coupling between the process definition and the service layer (meaning the actual classes and methods that do stuff.)
Let me explain.
Suppose you have a process with an automated task called “Send Invoice”:
.
retrieve the invoice ID (or order ID, or whatever other piece of data) from the properties of the current process instance on which it is executing;
invoke a given Spring service method, passing that data as argument(s);
receive the result from the service method invocation, which may include a boolean flag, a new ID or another piece of data;
store the resulting data in appropriate propert(ies) of the current process instance, so that subsequent “arrows” in the process definition can make choices based on the result of this task.
Correct me if I’m wrong, but it seems to me that all of those engines use dynamic reflection and untyped maps (JSON-style) to store instance properties, call service methods, and pass data around. I don’t need to explain to Kotlin programmers why that’s bad!
Going the other way around, that is, starting / stopping / querying / controlling the process instances from within Java/Kotlin code, also seems to be based on dynamic typing: a process is identified by a string containing its name; the properties of an instance are an untyped JSON-style map; and so on.
Have I missed a key feature in one of those projects, that would allow for compile-time static typing of the “business process layer” (for lack of a better term) against the service layer, and therefore against the rest of the code base?
Are there other BPM management engines that do offer such coupling?
@tobia Business process management systems are designed to kind of sit on top of your programs (that implement separate services). Primarily invocation would be of web services (mostly focussed on SOAP rather than REST). A good engine should support verification of an invocation against the corresponding IDL. All of this happens at process engine and process definition layers rather than at the programming language layer.
One way of thinking of a BPM system is to draw a parallel to a DBMS system. Where a database stores data, a BPM system coordinates (sometimes long-running - as in weeks or months) processes. Instance data is often incomplete and some data is stored externally where the engine needs to only have visibility of those data elements that are relevant to the control flow.
As the main focus of these systems is on service coordination (including worklist services that allow activities performed by humans) they work at that level. Any type definitions would likely be WSDL or some JSON schema. Validation should happen on the process (by the process editor).
You are correct that process engines have very loose coupling with services. This is by design, the idea being that the processes need to be flexible as well as glue various systems in the entire enterprise together (independent of vendor,…)
Right now I’m leaning towards embedding the BPM engine into my J2EE app, as most of them support such usage through their Spring plugins. This is so that the BPM could access the app’s service layer directly, to perform those tasks that are internal to the system (which would be the majority); and vice versa, the app could use the engine’s native Java API to expose custom interfaces to monitor and control processes, as well as to allow users to access their worklist tasks from within the main app.
My worry is what will happen to the process definitions when the app’s service API routinely evolves (such as changes in the Spring bean names, method names, argument names and types.) I was hoping to find a way to detect such “type” issues in the compilation phase, rather than unit testing or (save me!) integration testing.
But I’ll look into the SOAP and WSDL support they offer, to see if I can get more guarantees if I use the engines that way.
While WSDL support isn’t compiled it should be possible to validate a proces model (which is also not normally compiled) against it ahead of time (at an update of either).
