Required SQL-Scripts for Activiti to Camunda migration

Camunda 7 Topics Discussion & Questions
1

Hey,
I’m a little bit confused how to migrate from Activiti to Camunda. Our current database is on Activiti version 5.14. I wrote a rollbackscript to 5.11 to be able to update from Activiti 5.11 straight to camunda 7.0.0 as described in Official Activiti migration guide.

It says Camunda 7.0.0 is basically Activiti 5.11 and the database should be identicial. However in this Camunda blog I have to execute additional scripts (6.2 to 7.0) and on github (camunda 7.0.0-Final tag) are some other scripts as well (6.0->6.1, 6.1->6.2, 6.2->7.0).

Can someone tell me which scripts I have to execute and why?

Thanks!

2

Hi @Chr3is
This blog post was published a long while ago - but actually i think it still have a lot useful info. Might help you understand how to proceed.

3

Hey @Niall,
first of all thanks for the response! The question refereces to this blog article and I don’t unterstand why the blog post tells me that I have to execute the 6.2 → 7.0 script and the official documention does not mention this script. That’s the confusing I’m facing.

4

So the blog post was created when myself and @BerndRuecker decided to spend an hour or two doing a migration from activitiy a few years ago… so i don’t remember why that happened exactly… but i’d tend to go with what the docs suggest

5

Hey @Chr3is - these are two different migration scenarios. The docs describe a migration from Actitivi to Camunda basically when we forked. So this is based on a relatively old Activiti version (5.11).

The blog post looked at an Activiti version later in time (when a lot of other people migrated as the remaining Activiti developers left that project) (5.21).

So if you want to migrate you should at least decide for one of the approaches - it is not additional. In your case, as you are on a version in the middle, you have two options:

  • roll back to Activiti 5.11 and follow the docs
  • upgrade to Activiti 5.21 and follow the blog post

Hope that helps?

6

Hey,
in my case I had to rollback to 5.11 and execute the 6.2 to 7.0 script before executing the other official migration scripts from 7.0 to 7.14. In the 6.2 to 7.0 script I had to remove following statement because the column already existed:

/** add SUSPENSION_STATE_ column to task table */
alter table ACT_RU_TASK
    add SUSPENSION_STATE_ integer;

I performed the migration via liquibase and generated the changes with a script I wrote. I’ve ignored following patches:

[
            'engine_7.1_patch_7.1.9_to_7.1.10.sql',
            'engine_7.2_patch_7.2.6_to_7.2.7.sql',
            'engine_7.3_patch_7.3.5_to_7.3.6_2.sql',
            'engine_7.3_patch_7.3.5_to_7.3.6_1.sql',
            'engine_7.7_patch_7.7.5_to_7.7.6.sql',
            'engine_7.7_patch_7.7.8_to_7.7.9_1.sql',
            'engine_7.7_patch_7.7.8_to_7.7.9_2.sql',
            'engine_7.8_patch_7.8.7_to_7.8.8.sql',
            'engine_7.8_patch_7.8.8_to_7.8.9.sql',
            'engine_7.8_patch_7.8.11_to_7.8.12.sql',
            'engine_7.8_patch_7.8.12_to_7.8.13_1.sql',
            'engine_7.8_patch_7.8.12_to_7.8.13_2.sql',
            'engine_7.9_patch_7.9.11_to_7.9.12.sql',
            'engine_7.10_patch_7.10.6_to_7.10.7.sql',
            'engine_7.10_patch_7.10.13_to_7.10.14.sql',
            'engine_7.11_patch_7.11.7_to_7.11.8.sql',
            'engine_7.11_patch_7.11.18_to_7.11.19.sql',
            'engine_7.12_patch_7.12.10_to_7.12.11.sql',
            'engine_7.12_patch_7.12.11_to_7.12.12.sql'
    ]

After the official scripts I had to drop some columns which do not exist in the plain camunda 7.14 schema and fixed some constrains & indexes. But now the migrated schema and the plain camunda 7.14 are identicial (except the column order in the tables).

I haven’t check if the migrated data will work with the new engine. But I’m going to provide some feedback if everything was tested.

Note: If I perform the migration with the official docs (not executing the 6.2 → 7.0 script) the migration does not work for me.

7

Hey @BerndRuecker @Niall
I have a question about jpa-entities. I’ve migrated from activiti (5.14 → 5.12) → camunda (7.15) and now process instance queries which searched instances containing a process variable (jpa object) do not return any result for old processes. In activiti the column type_ in the *_variable table was filled with the value ‘jpa-entity’ (org.activiti.engine.impl.variable.JPAEntityVariableType.TYPE_NAME).

Camunda uses 'jpa' as value (org.camunda.bpm.engine.impl.variable.serializer.jpa.JPAVariableSerializer.NAME) which do not match now. Is something like this

UPDATE act_ru_variable
SET type_='jpa'
WHERE type_='jpa-entity';

UPDATE act_hi_varinst
SET var_type_='jpa'
WHERE var_type_='jpa-entity';

missing in the activiti → camunda migration scripts?

Greetings,
Christoph

8

Hi Chris.

I don’t recall this out of the top of my head. Haven’t seen too many usage of the JPA entities as process variables. Customer storing entities alongside the process most often only store a key and do the resolving themselves - as it is much more flexible and under your control.

That’s said: if it is working with this change for you I think this could/should be added to the migration scripts. But you should double-check the implementation is really the same first.

Hope that helps? Best
Bernd

9