We are developing a spring boot application(generated with jhipster, with oauth) and we want to use camunda.
The camunda spring boot starter(with the process engine only) worked, however the we had problems with the other two starters(rest, web) in our current setup(although they work with a simple project like in the camunda examples).
We actually prefer using the embedded process engine like this, however, we would like the operational advantages of the camunda webapps.
The preferred solution we thought about was to connect to the same database another process engine(camunda standalone or springboot app with camunda web starter). This seems to be working in our tests.
The other solution would be to use camunda standalone and communicate via rest api, and subscribe to topics for service tasks.
My question is, do you see any problems with the preferred solution? Which solution do you think is better, and why?
Yes I did. Does not work out of the box with our project. It probably needs some custom spring configuration. But using just the process engine works. So the question is, if we connect another camunda process engine to the same database, for operational purposes(cockpit, admin), will there be any problems?
the camunda webapp comes with configurations for the paths /api and /app. This will conflict with any custom controllers/ui you have under the same path.
I am not aware of an “out-of-the-box” solution, you can either use a different entry point for your custom app or “somehow” (not an expert) reconfigure the WebServletConfigurations that come with the webapp starter.
You could also run a second serbive against the same DB, but you will need all processes+code deployed on that node as well if you want to use state-changing commands in the cockpit (restart after incident, …). Making the nodes deployment-aware might also help.
You need to follow heterogeneous cluster setup. The process engine which is intend only for operational purposes means, then disable Jobexecutor to avoid runtime errors unless you have deployed same delegates+listeners in all the nodes.