Disable auto-creation of tables during bootstrap (org.camunda.bpm.engine.ProcessEngineException: ENGINE-03056)

Hi,
I use Camunda 7.21 with Spring Boot 3.2 and want to embed the Camunda engine in my Spring Boot application.
Since I want to disable the auto-creation of the engines database tables I followed the hints of this post: Process engine database auto-creation disabling to create the database using the provided SQL scripts.
I downloaded the SQL file and stored them into src/main/resources folder:

  • engine_7.21.0.sql and
  • identity_7.21.0.sql
    Also I provided the following entries in yaml file
    camunda:
    bpm:
    database:
    type: h2
    schema-name: camunda
    table-prefix: camunda.
    schema-update: false
    jpa:
    enabled: false

But, during bootstrapping my application, I get the following exception:
ENGINE-16004 Exception while closing command context: ENGINE-03056 Tables are missing for the following components: [
engine
history
identity
case.engine
decision.engine
]

org.camunda.bpm.engine.ProcessEngineException: ENGINE-03056 Tables are missing for the following components: [
engine
history
identity
case.engine
decision.engine
]

Can you show me, how to fix this issue?
Thanks in advance, Roland

Hello @Roland ,

as you disable table creation, how will your tables be created?

Jonathan

I disabled the Camunda build-in auto-creation. Instead I use the provided SQL-Files which will be run during bootstrapping of Spring Boot.

Hi @Roland,

If you disable auto creation feture then, you should run create scripts manually.

Hi, yes I run the scripts manually. The scripts are provided by Camunda and I downloaded them and copied them to src/main/resources folder (this is described in the link above).
When I execute the Spring Boot project, the scripts are only successfully executed when I set the parameter camunda.bpm.jpa.enabled to drop-create.
But as far as I understand this will delete/cre-create all camunda tables and all my process-informations gets lost. That’s why I put the parameter camunda.bpm.jpa.enabled to false. But than I get the exception as described above.
Maybe I have to set other parameters?

Here is the latest status:
I have a Spring Boot 3.2 application in which I want to use Camunda 7.2. I have disabled Camunda’s automatic table generation and instead downloaded the SQL files provided by Camunda and used them in my Spring Boot project (a description can be found here Process engine database auto-creation disabling).

In the application.yaml I use the following parameters
camunda:
bpm:
database:
type: h2
schema-name: camunda
table-prefix: camunda.
schema-update: false

I am using H2 and have placed both H2 SQL files “identity_7.21.0.sql” and “engine_7.21.0.sql” in the src/main/resources. This contains the corresponding CREATE TABLE statements. These scripts are also executed when the Spring Boot application is started (this can be seen in the Eclipse/STS console), e.g.
DefaultSqlScriptExecutor CREATE TABLE IF NOT EXISTS ACT_ID_USER (
ID_ varchar(64),
REV_ integer,
FIRST_ varchar(255),
LAST_ varchar(255),
EMAIL_ varchar(255),
PWD_ varchar(255),
SALT_ varchar(255),
LOCK_EXP_TIME_ timestamp,
ATTEMPTS_ integer,
PICTURE_ID_ varchar(64),
primary key (ID_)
)

However, the following message appears at some point:
org.camunda.bpm.engine.context ENGINE-16004 Exception while closing command context: ENGINE-03056 Tables are missing for the following components: [
engine
Engine history
Identity
case.engine
decision.engine
]

There was already a thread about this in the forum (sh Tables are missing for the following components: [ identity ]) but unfortunately no solution/answer.

Do I have to download and execute any other SQL files apart from the ones mentioned above? Or do I have to make any other configuration settings?

Like @hassang mentioned, you problem should be fixed with:

spring.jpa.hibernate.ddl-auto=NONE

or any other valid option that does not tries to create the tables in your db.

But i would recommend you to use liquibase, you can embed the camunda liquibase script into your own liquibase script, by using the liquibase script you are able to upgrade the camunda engine without always having the need to compare what changend in the database and what migration scripts you need to run yourself.

Hi [gianluca1606]
Setting spring.jpa.hibernate.ddl-auto=NONE will change the JPA behaviour generally, right? This is not what I want to achieve.

I debugged the application and played around with the configuration. It seems that there is a problem when you use H2 with the provided H2-scripts and set the database schema to false to manually run the H2-scripts.
The scripts are executed successfully as the console shows
image

But when the internal check from Camunda-class “DbSqlSession” drops in the class throws exception
image

This is the position where the check s done
image

This is caused by
image

So it seems that during bootstrapping the class can’t find the specified tables since it is searching on the wrong schema or whatever.

But, I found a solution that works for me: I setup the application for POSTGRES (even if I use H2) like this:

  • download the SQL scripts provided by Camunda (see link above)
  • For H2 and Postgres: Use provided SQL files for Postgres and add them to src/main/resources folder (I put them to /migration subfolder)
  • For H2:
    – Open application.properties/yaml and set the following parameters
    spring.datasource.url = jdbc:h2:file:~/;;DATABASE_TO_LOWER=TRUE;MODE=PostgreSQL
    spring.flyway.locations = classpath:migration/camunda-postgres
    spring.flyway.schemas = camunda
    – Add
    camunda.bpm.database.type = postgres
    camunda.bpm.database.schema-name = camunda
    camunda.bpm.database.table-prefix = camunda.
    camunda.bpm.database.schema-update: false

Hint: I doublechecked the behaviour and switched back above configuration settings in bold using H2 and corresponding H2-scripts. Than the bootstrapping failed again. Since I use H2 only for fast prototyping the workaround using PG-settings is ok for me.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.