I have a short (silly) question: Is it possible to restrict an engine instance to process only a sub-set of all deployed and instantiated process definitions?
Here is (our) rationale (because there could be another solution to our problem): We are currently using Activiti 5.14 (yeah, rather old but we were desperate to upgrade directly to 6 and then …) and we have one engine instance that serves all our process definitions. The code around that instance isolates the applications from the Activiti specifics and dependencies (we already migrated from another workflow engine to Activiti many years ago and that time we decided to decouple the business logic from the workflow engine implementation).
Now we want to refactor (re-organize) the code and to move the workflow definitions and Activiti delegates (implementations of org.activiti.engine.delegate.JavaDelegate) in the same application/project and (if possible) distribution package. For this purpose we decided that the easiest approach would be to create an engine in each application (still decoupling the business logic from the engine specifics). Now the problem is that each engine instance will try to process the definitions (currently) instantiated from all applications, but only the delegates for the specific application (running the engine instance) will be available in the class-path. This will lead to lot of exceptions and although they might be not fatal, they will fill the log with a senseless garbage and will turn the support into a nightmare.
That is why we need to separate the “visibility” of the process instances to the different engine instances. We would also like to avoid further migration efforts such as creation of additional DB users or dedicated engine tables.
Although we are using Activiti, I’m asking the question here because we are still waiting for 6.0 (New version - new name, what’s better? )
Interesting use case. Currently we don’t have support for this yet. But I do see the benefits of having this kind of functionality. What are your thoughts about how you would define which process definitions you want to execute on certain Engine instance? Would you define a list of process definition keys in the process engine configuration for example?
I think that providing a list of process definitions in the engine configuration will decrease its flexibility. In my opinion some “tag” or “filter” field in the process definition would be more appropriate because it will allow adding new process definitions to a working engine. Or at least will not require a new application build for changing the configuration. Of course that tag/filter should be again specified in the engine’s configuration.
OK, probably I should tell more about our way of using Activiti. Here it is: we have enterprise applications (EARs) that implement some (surprise!) business logic. Some of these applications are “extended” with workflow processes for added flexibility (example: the “classic” one with invoices handling - some customers might want to approve invoices only if their amount is above a certain limit, others want to have more than one approver for different limits, and so on - you can imagine further “specifics” - rejections, cycles, …). We create a process definition for each customer (of course we re-use them where it is possible ) and the development for a new customer often could mean just a creation of a process definition without changes in the business logic. Having this in mind we decided, back then, to provide (deploy) the process definitions separately from the EAR. Although the definitions have different names (we need to distinguish between them, right), they still belong to the same business domain (read - “related to the same application”). We developed a console-based (for security reasons) process definitions management application and we could add or update a definition at any time avoiding the need to stop the application.
As you can see from the example, we are using the process definitions more like orchestrating the business logic and we often reuse them for the different customers and we do not have a big number of them. That is why we consider the option to split them in different DB table sets or even multiple DB users an overkill.
Thanks for the additional background.
I agree that providing a list of process definition keys is a bit static.
Would you propose to use a BPMN extension to include the info?
Maybe having a prefix in the process definition id / key would be good as well.
So every process definition with key prefix customer1 will be executed on this engine for example.
That makes it less static and still makes it not too hard to implement in the Flowable Engine.
I think an extension will be the cleanest approach because it will not restrict the “alphabet” of the other fields.
If is hard or you prefer to avoid to extend the BPMN, some prefix or suffix to the process ID or process name could do the job but then the process definition designers should be aware of the special meaning of some symbols in the corresponding field. In addition, the process ID is used often and it would be better to keep it shorter.
It seems that the targetNamespace attribute of the definitions field is not used currently, but this also be an abuse and is probably not supported by the BPMN editor.
Yes an extension could work indeed. But what would be the value defined in this extension?
Would you have a certain identifier, that is defined in the process engine configuration as well as a supported process definition for that specific engine?
The target namespace is supported in the Eclipse Designer and web based modeler.
My idea is to match/define in the engine configuration only the extension value. This way the extension could serve as a grouping factor for a certain set of process definitions. On the engine configuration side there could be a list of such “tags”.
I could even imagine a possibility to define of list of exclusions in the engine configuration instead a list of inclusions: in some cases it could be easier to define “this engine should not serve [process definition] groups E and H” instead to define a list of 20 groups to include.
Although I do not see much of value in “a single engine per process definition” approach, the addition of a grouping extension does not exclude this use case: once the extension is on place, the process definition/name could be copied there.
)