Best Practice migrating from 5.15 to 6.5

Flowable Engine
1

Hi @joram @martin.grofcik

Basically we are migrating from activiti 5.15 to 6.5 - and all looked fine - flowable did on the fly migration of schema and everything worked like charm until recently we started seeing errors where its trying to migrate again and failed complaining about duplicate tables(as the tables are already created with first run).

Looking into ACT_ID_PROPERTY table - schema.version is already 6.5.0.6. But when the code goes to org.flowable.engine.impl.db.ProcessDbSchemaManager#schemaUpdate class finds a 6.1 version and starts migrating again.

Looks like some reason the ACT_GE_PROPERTY table is not updated properly - not sure how a partial update has happened here…

On alternative instance we are seeing ACT_GE_PROPERTY is properly updated but still it tries to insert record into ACT_GE_PROPERTY and fails with duplicate rows.

Couple of questions.
1)Should the migration be done running the sql scripts manually or leave it to flowable to take care of it.
2)Why would flowable try to insert record again - where does it check the schema is all good and not to perform any alter and insert sql. One check it does is looking at ACT_GE_PROPERTY but seems there could be other flow too…

Thanks!

2

+@filiphr

So the real problem stems from the fact its not able to migrate ACT_RU_JOB - Not sure there is a better way to migrate JOBS to deadletter table ? or maybe some sequence of migration is going wrong - executions are not migrated ahead?

(Once I cleaned-up my ACT_RU_JOB before flowable auto-migration just to see it works - everything works perfectly fine)

[2020-06-04 16:32:32.166] ERROR main org.flowable.engine.impl.db.ProcessDbSchemaManager problem during schema upgrade, statement alter table ACT_RU_JOB
add constraint ACT_FK_JOB_EXECUTION
foreign key (EXECUTION_ID_)
references ACT_RU_EXECUTION (ID_) java.sql.SQLIntegrityConstraintViolationException: ORA-02298: cannot validate (ACTIVITI.ACT_FK_JOB_EXECUTION) - parent keys not found

3

Closing this issue - problem was some reason there were dangling rows in ACT_RU_JOB which did not exists in ACT_RU_EXECUTION and hence failed creating those constraints. Dropping those rows seemed fixed the problem.

4

That’s great to hear.
I do wonder how these jobs got there - typically each job coming from a process should have an executionId/processInstanceId.

5

We are still investigating the same but we had lot of legacy data in our repo which we were trying to migrate. All of these failed jobs with no parent keys are ones which failed with errors like when a primary process definition was initiated and it had a subsequent callactivitiy/subprocess which was not deployed yet - we see dangling records for such data.