Camunda Engine Update Guide

When the engine version of camunda is increased we need to perform some manual migration tasks to ensure compatibility.

Product development

Check the official Camunda migration guide pages for all affected versions here
- https://docs.camunda.org/manual/latest/update/minor/
- Check especially for any breaking changes or maven dependency changes
- Check for new features / openapi-specification additions that might be useful to us and create tickets for implementation
Update dependencies on all affected WF projects and check for compile errors/test failures
Prepare, filter and test database migration scripts for project development
- if applicable merge multiple scripts into one file for convenience
- update omn release documentation with sql scripts and special camunda migration steps if needed
Update product dev and test systems and perform tests.
- Test AI-Workflows

Project development / DevOps

When updating the camunda version some migration steps must be performed manually in a certain order. This documentation might be adjusted by product development for a specific version but generally follows the same pattern.

There are two ways to approach this - depending on the requirements of the individual camunda usages:

1. Database purge and recreation

+ The most simple way to update camunda and the database structure is to purge the postgres database and let it recreate on container startup. This ensures up-to-date structures and indices and configuration.

+ Applicable if…

+ * No long running processes are executed on this instance in other words, all relevant processes can be finished before the migration steps are performed, because they will be deleted. * No process history is needed process history will be entirely deleted. Of course there can be made backups for analytic purposes beforehand, but they can not be restored to the migrated database again for productive usage. * BPMNs can be redeployed with reasonable effort Deployed workflows are deleted but can be recreated from bpmn files after the update. workflows provided by OMN product will be redeployed automatically on first startup (AI-Workflows)

+ Migration steps

Stop OMN and camunda docker containers
- camunda engine (omn/camunda)
- workflow component (omn/workflow-component)
- postgres (postgres:alpine)
Delete persistent postgres data
- in most cases this data is bind mounted to the host system. The path can be found in the docker-compose.yml in the 'volumes' section of the 'postgres' definition.
Pull and create new versions of the aforementioned docker continers
Start containers and check for successful launch

2. Database migration

+ Camunda provides sql scripts and migration guides to update and migrate existing installations to the next minor versions.

+ We will provide a pre-checked, filtered and merged script to execute, that covers all camunda version hops performed with a specific OMN update.