We are currently using Camunda 7.4.5, running on a shared Tomcat. One Java project for each process-definition and integrated with Spring.
Now we would like to upgrade to the soon-to-be-released Camudna 7.9, but might want to rethink our project/server setup.
There is no doubt Spring Boot is the “future” and many of the examples I find are also Spring Boot based.
Is it recommended to have:
Multiple processes in one Spring Boot project with embedded Tomcat?
One process per project, meaning multiple Tomcat instances? (We’re not keen on this)
Packaging Spring-Boot projects (one process per project) as WAR and deploy it in a shared Tomcat server
Don’t use Spring-Boot, keeping it roughly the way we do today?
Other ideas? I see service workers are being used. Today we have traditional Java Delegates.
the main question you should ask yourself is the amount of depedencies vs. indepencency you want to have in your projects in the future and how important a central tasklist or cockpit is for you.
If you go for spring-boot with one container per process, you will get a lot of flexibility and easy rollout. But: how much of your code is used by all processes?
Introducing a central tasklist in spring-boot needs the careful usage of async-before and async-after checkpoints to avoid class-not-found-execptions.
I don’t see benefits using sping boot and deploy them on a tomcat afterwards. I think it’s easier to develop process applications and deploy them on a tomcat with a container managed engine.
Thank you for your reply.
You say “central tasklist in spring-boot needs the careful usage…” but one would face the same challenge with multiple WARs (a process per WAR) on a shared container server as well?
A benefit that I see using spring-boot with embedded Tomcat during deployment, but deployed as WAR in test environment is ease of development. It is quick to start and easier to set up debugging etc.
No, all forms are served from the same URL and all classes for java delegates are available in the classloader.
In a central tasklist with spring-boot you switch between servers. The tasklist tomcat does’t have the forms and the classes, they are in the project spring-boot-servers. And the project didn’t have the tasklist. This has to be managed with a ZUUL proxy for the forms and async-before and async-after for delegate execution.
Yes, the project startup is very quick, but as you develop a longer time, this speed count even less in the development cycle. You can integrate the shared tomcat server easy in eclipse to have a fast development cycle for forms: debugging - How can I debug Camunda webapps in eclipse? - Stack Overflow
As I said before, the choice should not be done on a technical level. Consider the overall architecture of your system (or systems) and how it/they may develop over the next years.