at the beginning of our project, the use of the flowable-all-in-one-apps was pretty nice - having a neat frontend to see what is happening on the engine.
As we are using an event handler (e.g. to handle Kafka messages) to connect our existing system with our process engine, we implemented several service tasks to interact the other way around.
Later, we introduced an timer catch event and wondered why it didn’t work the way we expected. Everything was set correctly in database, but the job simply disappeared as soon as it was expired.
As it turned out, another process engine took the job (seen in the flowable-all-in-one-logfile) and couldn’t handle it properly because of missing service task beans.
So, can we achieve somehow that there is only one active process engine, in fact, our? I’ve seen that it is possible to disable the async job executor. This might solve our particular problem, but are there more obstacles or side effects when having multipe engines?
Is it possible to share our engine with the all-in-one-apps?
As I understood, there are 2 engines pointing to the same DB. Each engine has its own set of available beans. Process engine can share process instances, but they are not able to execute them because of missing beans used in process definition. It can cause failures not only in async job execution, but also in sync process execution.
I would recommend to separate databases (use configuration to configure datasource) or use multi tenancy.
you are right, but in general it is desired that they point to the same DB.
We would like the use the (e.g.) flowable-admin just as a viewer to the DB, instead of an active process engine. We use it for deployment of processes and to see and inspect running/historic instances with the side effect that an additional process engine is used for that.
The active part (execute timer jobs, trigger waiting activities, handling external events …) should be done by the process engine that we started actively.
Furthermore, we could provide the all-in-one-apps with our own classes (primarily service task implementations). Nevertheless, it would be vague which engine would be in charge, logs are cluttered, and so on - we will avoid this.
Re: one admin app to view whole DB state: flowable-admin uses flowable-task to access engines. When flowable-admin + task point to the shared DB you should be able to view shared DB state. (you should disable async job executor to do not make any changes.
But when there are 2 engines with 2 bean sets (which differ), you can use multi tenancy to distinguish between them. https://blog.flowable.org/2018/09/11/multitenancy-in-flowable/