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”:
That task would need to:
- 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?