Hi there!
Thanks for your prompt reply.
We are building a Spring Boot application with Camunda embedded into it and the Camunda part of the application.yml file is as follows:
Blockquote
camunda:
bpm:
application:
delete-upon-undeploy: false
scan-for-process-definitions: false
deploy-changed-only: true
resume-previous-versions: true
job-execution:
enabled: true
metrics:
enabled: false
db-reporter-activate: false
auto-deployment-enabled: true
(Sorry for the formatting, leading spaces seem to be removed automatically)
Do you see anything out of order?
There is also a custom dataSource part in the application.yml file and we use a custom class with @Configuration to instantiate the camundaBpmDataSource. I can see from the logs (and using breakpoints) that the camundaBpmDataSource bean is instantiated before the database is cleared (unintentionally).
We use Postgres as RDBMS and I can see that before the application is run, the tables from the previous run are present, but somewhere in the process, they are cleared. This happens right around when the RepositoryService and RuntimeServices are instantiated in our application.
Here are the relevant logs that clear the database:
Blockquote
2018-09-21 08:52:03.108 INFO 23437 — [ main] org.camunda.bpm.engine.cfg : ENGINE-12003 Plugin ‘CompositeProcessEnginePlugin[genericPropertiesConfiguration, camundaProcessEngineConfiguration, camundaDatasourceConfiguration, camundaJobConfiguration, camundaHistoryConfiguration, camundaMetricsConfiguration, camundaAuthorizationConfiguration, failedJobConfiguration, disableDeploymentResourcePattern]’ activated on process engine ‘default’
2018-09-21 08:52:03.111 INFO 23437 — [ main] org.camunda.bpm.spring.boot : STARTER-SB020 ProcessApplication enabled: autoDeployment via springConfiguration#deploymentResourcePattern is disabled
2018-09-21 08:52:06.218 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘engine’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.engine.sql’
2018-09-21 08:52:06.389 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘history’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.history.sql’
2018-09-21 08:52:06.432 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘identity’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.identity.sql’
2018-09-21 08:52:06.481 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘case.engine’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.case.engine.sql’
2018-09-21 08:52:06.506 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘case.history’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.case.history.sql’
2018-09-21 08:52:06.523 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘decision.engine’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.decision.engine.sql’
2018-09-21 08:52:06.563 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03016 Performing database operation ‘create’ on component ‘decision.history’ with resource ‘org/camunda/bpm/engine/db/create/activiti.postgres.create.decision.history.sql’
2018-09-21 08:52:06.584 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03067 No history level property found in database
2018-09-21 08:52:06.584 INFO 23437 — [ main] org.camunda.bpm.engine.persistence : ENGINE-03065 Creating historyLevel property in database for level: HistoryLevelFull(name=full, id=3)
2018-09-21 08:52:06.601 INFO 23437 — [ main] org.camunda.bpm.engine : ENGINE-00001 Process Engine default created.
We also have another Postgres database that we use for other purposes (with a different port) and it is configured with a different bean name. It has @Primary though, could that be an issue? Maybe Camunda sees that the @Primary dataSource doesn’t contain any tables and for some reason then clears the camundaBpmDataSource? Seems far fetched though…
Thanks in advance!
Best regards,
Erik