A draft to show how to migrate version with call activities (until the Operate migration tool allows it)
ℹ️ In case the process instance is active on call activities, the tool will add a "migrate" catch event right after the "start event". This migrate catch event is associated with a [worker]((src/main/java/org/example/camunda/worker/MigrationWorker.java) that will restore sub process in the desired state.
ℹ️ This project is kind of "naive" and it may be more difficult in real life, especially if your process instances use parallel expanded subprocesses.
This repository contains a Java application for Camunda Platform 8 using Spring Boot and a docker-compose.yaml file for local development. For production setups we recommend to use our helm charts.
- Documentation
- Camunda Platform SaaS
- Getting Started Guide
- Releases
- Helm Charts
- Zeebe Workflow Engine
- Contact
The Spring Boot Java application includes an Angular front-end. Run make buildfront from the project root, start the Spring Boot app (make run or mvnw spring-boot:run), and then browse to http://localhost:8080.
If needed, you can also run the Angular front-end independent of the spring boot app. To do so, run npm run start to start a nodejs server serving over port 4200. You can also use the make runfront
The application requires 2 running clusters, a source and a target. You can run Zeebe locally using the instructions below for Docker Compose or have a look at our recommended deployment options for Camunda Platform.
Before starting the app go to http://localhost:8084/applications/
and create application of type M2M with read/write access to Operate
and set operate.selfmanaged.clientId and operate.selfmanaged.clientSecret in application.yaml.
Run the application via
./mvnw spring-boot:run
UI http://localhost:8080/ Swagger UI: http://localhost:8080/swagger-ui.html