Migrate to Camunda 8 (Parent Issue).

[kaladay]

This is to be used as a parent issue for one ore more sub-issues focusing on individual research/task issues.

Based on the investigation from: #209 , upgrading from Camunda 7 into Camunda 8 is the preferred direction.

Steps to take:

• Need to upgrade Camunda without modifying mod-workflow, unless mod-workflow has camunda-specific code that should be removed.
• The workflows need to be rewritten, see migration guides https://camunda.com/platform-7/migrate/ and https://docs.camunda.io/docs/guides/migrating-from-camunda-7/ .
• Consider UI and templates from "SPIKE: Create a basic "Hello World" Stripes UI-Module: ui-workflow" note / draft on this project board (may be converted to an issue at some point).
• This may affect the Switch from Nashhorn issue: Switch from Nashorn to GraalVM for javascript execution fw-registry#302 .
• Still need to make sure the password privacy is working as expected to fix issue 209.
• Consider the community migrator: https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/backend-diagram-converter
• Consider the adapter to keep running Camunda 7 stuff until able to convert to Camunda 8 stuff: https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/camunda-7-adapter
• Need to reseach and understand Zeebe (https://docs.camunda.io/docs/components/zeebe/zeebe-overview/ and https://docs.camunda.io/docs/components/zeebe/technical-concepts/architecture/ ). This may affect the Nashorn and similar functionality.
• Look into their Camunda 8 Docker and Kubernetes support.
• There may need to be changes to fw-registry, investigation is needed.
• Looks like the "zeebee" has something that could replace the fw-registry project: https://docs.camunda.io/docs/apis-tools/cli-client/ and https://docs.camunda.io/docs/apis-tools/java-client/. These are of course Camunda specific and so we may still need / want fw-generate to support for non-Camunda based use cases.
• Existing Camunda connectors: https://docs.camunda.io/docs/components/connectors/out-of-the-box-connectors/available-connectors-overview/
• BPMN support is documented here: https://docs.camunda.io/docs/components/modeler/bpmn/bpmn-coverage/
• License changes: https://camunda.com/blog/2022/05/how-open-is-camunda-platform-8/ and https://camunda.com/legal/terms/cloud-terms-and-conditions/zeebe-license-overview-and-faq/ .
• REST for Camunda 8 (Camunda 8 is using gRPC rather than REST): https://docs.camunda.io/optimize/self-managed/optimize-deployment/plugins/engine-rest-filter-plugin/ , https://docs.camunda.io/docs/components/connectors/protocol/rest/ , andhttps://korthout.github.io/camunda-platform-rest-api/ .
• Look into Quarkus for GraalVM support or functionality https://docs.camunda.org/manual/7.19/user-guide/quarkus-integration/ .

Other potentially useful links:

• https://blog.viadee.de/en/camunda-8-camunda-7-differences
• https://camunda.com/blog/2023/05/start-camunda-8-process-rest-webhooks/
• https://www.altkomsoftware.com/blog/technologies-blog/camunda-8-vs-camunda-7-challenges/

[wwelling]

The workflows need to be rewritten, see migration guides https://camunda.com/platform-7/migrate/ and https://docs.camunda.io/docs/guides/migrating-from-camunda-7/ .

Why do we need to rewrite our workflows? They are an abstraction defined in mod-workflow in which sends its domain representation to mod-camunda for generation of the BPMN workflow compatible with Camunda. The purpose of mod-workflow is to define an interface specification to avoid exactly what this need is describing. If there is a domain incompatibility between mod-workflow and mod-camunda, we need to document such and determine what is required to be refactored. I suspect mod-camunda will require modification in how it transforms mod-workflow domain representation into BPMN compatible with Camunda 8. Did Camunda 8 has somehow changed the BPMN specification?

https://github.com/TAMULib/mod-camunda/blob/main/src/main/java/org/folio/rest/service/BpmnModelFactory.java#L82