In Flowable/Activiti I lived happily without the Process Applications. It was a simple war application that you threw in Tomcat and it worked by itself without interaction with other webapps in the container. My web application with process engine embedded was able to deploy processes edited in an embedded web-based editor by calling repositoryService.
There was some logic in an event listener that was hooked to every task in the engine. I am porting my app to Camunda, and here we have the notion of Process Application, and the so called “catch all” event listeners have to be defined in the application.
I’d stick with java spring config and I managed to create a config file, but it configures the process engine, taken from a ManagedProcessEngineFactoryBean. The Process Application, as per the docs, is just a specially annotated class, extending SpringServletProcessApplication, and it’s also a bean in the spring config. No processes.xml, I’d wish to avoid that.
2 questions.
If I continue to deploy processes directly to the process engine, programmatically, from a @controller, will the Process Application methods (getTaskListener, notify) ever be called on my executions?
Shall I consider merging my current ServletContextListener with the @ProcessApplication? It loads a couple of AnnotationConfigWebApplicationContext s, one of which is a Process Engine config class, and do some other things.
(I understand that I have to just try, but its too much time for me to follow one route and then notice that it was wrong. Thus asking people who just know. Hope it wont take a lot of your valuable time)
You don’t need to use process applications in an embedded engine scenario. In this case, it works just the way you are used to. In order to create a global task/execution listener, you have two options:
Write a parse listener that registers the execution/task listener with every parsed activity
Do you know if there is some overhead in the camunda-bpm-reactor community extension, I mean, how fast is it working?
I have just thought, what if I take my existing ServletContextListener, annotate it as a ProcessApplication, add methods for task listener, stay in control how it checks event types etc., and it will magically work. But probably I am wrong so I will definitely look into the extension.
I haven’t got any experience with that, so if in doubt, you should make some measurements of your own. In general, the process engine’s performance limiting factor is database IO and in comparison to that any non-IO computing (like reactor’s event bus) is typically negligible. Maybe the maintainer @jangalinski can also provide some insights.
If you still want to go the process application route, extend the class EmbeddedProcessApplication. You must then override the method #createDeployment to programmatically add resources to the process application deployment. Then, call its #deploy method from your custom ServletContextListener. Making the deployment this way, the process engine is able to connect the process application to the deployment and resolve the global listeners. That said, if all you want to achieve is global listeners, then I think this approach is unnecessarily complex compared to the other variants.
The reactor extension uses the projectreactor eventbus which is highly efficient. It basically just manages a subscription map from topic to implementation and uses the eclipse (goldman) collection types to do so, which where implemented to be extremely performant. I do not have any benchmarks, but we use it in a 100k instances/per day scenario without even noticing it.
If you look at the implementation, you’ll see that it uses the ParseListener hook to register components, so it is basically the same as you achieve now with custom parse listeners, but in a more generic and plugable fashion.