Older version process instance cannot find Java class?

We have had Camunda running for approximately one month.

After doing some refactoring and tidying in the project, we renamed the root package in the project from “cmp” to “workflow”.

This resulted in today the Camunda workflows not being able to progress, because the class path is using the old package.

com.foo.service.cmp.task.UpdateProcessStatusTask

The new one

com.foo.service.workflow.task.UpdateProcessStatusTask

For new instances with the newer version of the workflow, it is working ok.

However older versions are still referring to the older classpath and cannot progress, the server throws a 500 error.

The diagram has not changed apart from the service tasks paths.

How can we hack this to work again?

We tried adding back a package called cmp however because it is in a different root to spring-boot, the dependency injection will not work in that scope.

Is there a way to hack the instance in the database?

Hi @CamundaCommando,

no need to hack, just use the process instance migration: https://docs.camunda.org/manual/7.10/user-guide/process-engine/process-instance-migration/ to lift the instances to latest version of the process model.

Hope this helps, Ingo

Is there an easier way than this?

I had a look at the documentation and it requires that I:

  • specify the process instance definition id
  • specify target process definition id

I tried running this locally but because I dont have prod/ dev parity it blows up (I have different process definition Ids)

Is there not a way to hack it in SQL?

Which table specifies the version of the process instance?

Or can I hack the older version of the BPMN, is that stored somewhere?

I figured a way to do it, you have to find an replace the string inside the XML loaded into ACT_GE_BYTEARRAY

UPDATE ACT_GE_BYTEARRAY SET BYTES_ = REPLACE(BYTES_, ‘.cmp.’, ‘.workflow.’)
WHERE INSTR(BYTES_, ‘cmp’) > 0;