Hello,
In the past, we had 4 successful deployments of camunda workflows. A decision was made to merge these deployments into a single schema. When I first tried merging the schemas I faced a host of issues from entries in the act deployment table, proc_def etc. Is there a systematic way to merge such schemas without disrupting workflows?
Thank you
@zamobo Of course yes. You can migrate the processes from previous deployments to latest deployment.
Migration consists of two parts:
Read more on the docs for process-instance-migration.
And some interesting blogs found here:
https://blog.camunda.com/post/2015/08/migrate-process-versions/
https://blog.camunda.com/post/2017/05/camunda-bpm-migration/
Built-in rest api’s for process migration:
POST /migration/generate
POST /migration/validate
POST /migration/execute
Execute Migration Plan (Async - Batch)
POST /migration/executeAsync
Not sure if the above applies to us. We have 4 platforms with camunda-activiti workflow deployments. We now want to merge the 4 schemas used into a single one. How do I deal with foreign keys refererring to each schema s act_re_deployment act_ru_execution and the rest of the tables?
yes we are. The reason being these were completely seprate platforms but a business decision was made to merge all DB schemas into one. We have 4 schemas that handle workflows and those the ones Im struggling to merge.
@zamobo, it will be difficult one. What’s your approach on migration?
Just for heads-up:
Disable the foreign key constraints check in the target database.
Use FOREIGN_KEY_CHECKS
SET FOREIGN_KEY_CHECKS=0;
Enable the constraint checks after migration:
SET FOREIGN_KEY_CHECKS=1;
(or) Disable keys at table level:
ALTER TABLE table_name DISABLE KEYS;
ALTER TABLE table_name ENABLE KEYS;
But I hope still you face the issues in migrating the ACT_RE_DEPLOYMENT table.
Note that processes deployed in different schemas will have different deployment id, process definition id and versions. If you migrate those inconsistency will cause. It won’t work for merging the processes from different data sources/schemas.
Well, initially I did mapping tables and ported every row across. Then I realised this is not going to work since workflow need to have consistent state.
Im now getting
ENGINE-01011 Cannot deploy process definition ‘/home/user/xxx.bpmn’: there already is a message event subscription for the message with name ‘xxx’.
yeah so I thought it will be a headache.
Note that processes deployed in different schemas will have different deployment id, process definition id and versions. If you migrate those process instances into one datasource/schema then inconsistency will cause. It won’t work for merging the processes from different data sources/schemas.
Are those the only foreign keys I need to worry about? ( deployment id, process definition id and versions)
The good news I suppose is that the deployments follow the same pattern/templates so I know it will be difficult but the merging will follow a pattern.
Any ideas about
ENGINE-01011 Cannot deploy process definition ‘/home/user/xxx.bpmn’: there already is a message event subscription for the message with name ‘xxx’.?
@zamobo i have tried this scenario already by merging the processes from mysql to postgres. It won’t work in that way due to primary keys mismatch. Even if you disable the key checks also, engine won’t recognize the copied data and inconsistency will cause.
@zamobo Interesting plan you have there. I’d like to hear about the outcome.
I think it should be possible, if you used uuid-id-generator on the original schemas. Then there should be no conflicts during merge. You “only” need to insert the rows in the correct order, to ensure constraints are valid, or disable the checks (which personally I don’t like).
Regarding the error: That seems to be not directly related to the db merge. But I could imagine that multiple of the proc defs use the same start message name ‘xxx’. That is not allowed, as the engine cannot know which process to start. If that’s the case, you need to change the proc defs in the old schemas before merging.
Sorry wrong post
@aravindhrs, I am currently planning to auto migrate process instance during deployment to the latest version. for to do this i am following below sample,
However, auto deployment process not being executed. Please assist if you have any idea on this.