I deployed on my Spring Boot app, with Camunda integrated, a process, using the Camunda Modeler. I put as the endpoint
http://localhost:8080/camunda/rest/deployment/create
and it worked. But the problem is: where is the process? There’s no bpmn file on my HD, apart the one saved by Camunda Modeler, and processes.xml is empty.
I expected the REST API would copy the file to one of the paths declared in camunda.bpm.deployment-resource-pattern.
When you deploy a process to the engine it is stored in the engine’s DB.
This is to ensure that if you have a cluster of engines you could deploy to any one of them and all of them will then have access to the process.
Ok, so probably also the bpmn files that I put manually on the server are stored in the db.
But this is not a bit misleading? I mean, this way we can have processes or other objects that have a file stored in the classpath of the site AND in the db, and others that are only stored in the db.
This force me to use only the REST API. It’s better because you have not to restart the server. If I want the physical file, I can download from the webapp interface.
So why the support of the deployment via files on classpath? I suppose it’s more simple to use at the start, but it should be deprecated in favor of the REST API.
Good question and actually both are valid and will remain so. They simply depend on the choice of architecture.
If you’re using the External Task Pattern the idea is that there is no business logic artifacts contained on the node where the engine is running. Business logic is run by external tasks and models are deployed from a remote location via the rest API and stored in a shared DB.
If you’re calling local beans or local java classes for business logic like for-instance in a war file deployed to a server or as part of a spring boot application all of your business logic is contained on the node and deployment is done via the class path and should not be done via the rest api.
Mh, well, I think I have found the answer myself: files in the classpath can be stored in the repo…
No. The executable BPMN process is part of my application code. It is closely tight to my delegates, listeners, forms, … and tested before deployment. So everytime I deliver new Java code by restarting/deploying my app, I want the complete bundle (bpmn + code) to be deployed. That what the classpath scan of the engine does for me when I keep my bpmn files in src/main/resources.
Being able to deploy “quick fixes” via rest is a nice option, and also useful for the standalone engine Niall mentioned, but definitely not the way I build my software.
Well, if you read my previous comment, the sense is what you say 
The External task pattern is interesting, but maybe too much complicated, since it’s not supported by the Modeler GUI.