Result automigrate Camunda schema after upgrade 12.6 to 13.4.1 unclear

We’re in the middle of upgrading our BrXM platform from 12.6 to 13.4.1. The Database is Postgres 9.5.19. The Projects feature is enabled in our BrXM platform. We’ve carefully gone through the upgrade instructions about upgrading the Camunda schema to the newest version through the (hopefully) enabled Flyway Library. As we understand correctly, if automigrate is available the migration of the schema should go from:

7.8 to 7.9
7.9 to 7.11

And it should update migration progress in the flyway_schema_history table.

On development environment we went from BrXM version 12.6. straight to 13.4.1 expecting the Camunda mirgration to 7.11 to happen automatically. The environment is running on 13.4.1 without any problems so far, and the projects feature is available as well. The only thing that makes it unclear if the migration was successful is that the flyway_schema_history does not report any script that were run to get to version 7.11. Instead, the baseline version has gone straight to 7.11 and not reporting any previous versions. It does say it was successful though.

# | version |      description      |   type   |        script         | execution_time | success 
--+---------+-----------------------+----------+-----------------------+----------------+---------
1 | 7.11    | << Flyway Baseline >> | BASELINE | << Flyway Baseline >> |              0 | t

How can we properly verify if migration went according to plan?

Turns out that the Projects feature actually doesn’t work properly. Approving and Reviewing results in stack traces in the logs. It looks like the automigrate of Camunda didn’t work properly. (see: https://documentation.bloomreach.com/13/library/upgrade-minor-versions/upgrade-13.0.0-to-13.1.0.html)

As mentioned, we’re running on an Postgres database instead of H2. We will be turning off automigration and running the manual upgrade scrips from the hippo-addon-wpm-camunda-engine-13.4.1.jar ourselves to see if this fixes our problem.

In the mean time, if anyone has more information about this Flyway automigration, feel free to comment.

We’ve managed to fix our problems by disabling the automigrate throught with the extra VM argument -Dbpm.autoMigrateSchema=false and manually upgrading the database by running these incremental update scripts found in the hippo-addon-wpm-camunda-engine-13.4.1.jar:

  • V7.9__postgres_7.8_to_7.9.sql
  • V7.10__postgres_7.9_to_7.10.sql
  • V7.11__postgres_7.10_to_7.11.sql

After restarting our Tomcat the projects and campaigns started working again.

Note to anyone running into problems with the automigration of Camunda: If the updated steps are not listed in the flyway_schema_history table, the migration didn’t take place. Manual upgrade is then necessary.

When running the projects feature on a non upgraded installation, we did find these log messages indicating issues with missing tables:

23.01.2020 13:31:40 [http-nio-8080-exec-26] ERROR 
[com.onehippo.cms7.services.wpm.project.jaxrs.WpmExceptionHandlerImpl.handle():89] Internal 
Server Error : message = ### Error updating database.  Cause: org.postgresql.util.PSQLException: 
ERROR: column "root_proc_inst_id_" of relation "act_hi_varinst" does not exist