nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Proposal: RuntimeService.setProcessDefinitionVersion(pi, pd)

falko_menge

We at camunda would like to introduce a method, which changes the process definition version of an existing process instance, to the runtime service.
This method will not perform any migration magic and simply set the process definition version in the database, assuming that the user knows, what he or she is doing.
Of course, this will be carefully documented so that the users know the risks of the operation.

Do you guys have any concerns with such a feature or can we continue with providing an implementation for you to review?

Find more posts tagged with

Comments

trademak

Hi,

This would only be useful for simple migrations right? The new process definition must have the exact same activity id to make it still run.
In addition, if there are still process instances running a transaction, what would you do with those process instances?

Best regards,

bernd_ruecker

Hi Tijs.

What do you mean with "running a transaction"? Currently some active thread is working? Then this would be a case for optimistic locking, meaning either the version update or the "real work" wins. Like any other race condition we could have (with e.g. canceling a process instance).

Yeah, this is about a simple upgrade, we need exactly the same activity ids. Maybe at least a consistence check would be a nice feature, but no special magic planned for e.g. activity migration (like we had it in jBPM 3).

Currently the decision is either to implement it in our own monitoring tool or to add it to the Activiti codebase. There I still see 2 possibilites: "Just" implement a Command without exposing it in the public API or even exposing it.

Personally I am fine with all options 🙂

Cheers
Bernd

trademak

Hi Bernd,

Right. I would go for the "Just" implement a command without exposing it in the public API approach.

Best regards,

meyerd

If there is "just" such a command, we should make sure that there is a testcase to ensure that it will be not broken by internal refactoring without someone noticing immediately.

falko_menge

If there is "just" such a command, we should make sure that there is a testcase to ensure that it will be not broken by internal refactoring without someone noticing immediately.

Of course, the command will be developed test-driven.

falko_menge

I added a first version of the command in http://fisheye.codehaus.org/changelog/activiti/?cs=3079
Currently, it needs a process definition id. Next, I'm going to make it work with only a version number.

falko_menge

Next, I'm going to make it work with only a version number.

Committed in: http://fisheye.codehaus.org/changelog/activiti/?cs=3080

rvi

Hi,

Is it possible to make this service public ? ( of course with warnings on the limitations of the migration : same activity ids/type, same branches..)

Simple process migration is one of our needs. We plan to use Activiti for service/message orchestration, with camel integration. and it seems easier to keep processes "migratable" than to handle several process versions with the same java/camel code, since it's not possible to have two versions of code running for each process version.

thanks
Richard

falko_menge

Hi Richard,

Is it possible to make this service public ? ( of course with warnings on the limitations of the migration : same activity ids/type, same branches..)

We don't want to expose this feature in the public API, because we want to ensure that the people, who use it, know what they are doing.
However, you can still start the command like this:

<br>((ProcessEngineImpl) processEngine).getProcessEngineConfiguration().getCommandExecutorTxRequired().execute(new SetProcessDefinitionVersionCmd(&hellip;))<br>

But let me quote the warning from the documentation of the command:

Warning:
This Command will NOT perform any migration magic and simply set the process definition version in the database, assuming that the user knows, what he or she is doing.

This is only useful for simple migrations. The new process definition MUST have the exact same activity id to make it still run.

Furthermore, activities referenced by sub-executions and jobs that belong to the process instance MUST exist in the new process definition version.

If the process instance is not currently waiting but actively running, then this would be a case for optimistic locking, meaning either the version update or the "real work" wins, i.e., this is a race condition.

[…]it's not possible to have two versions of code running for each process version.

One approach, you can also think about, is to use an environment with strong class loader isolation, e.g., an application server or OSGi container, and add a version number to the process definition key. This way you can run multiple versions of a process definition and the code that belongs to it in parallel. The camunda fox Community Edition allows that, too.

Cheers,
Falko

rvi

Thanks for reply, I understand your point for keeping it private. I just want to make sure it stays stable and won't be removed or changed without notice.

[…]it's not possible to have two versions of code running for each process version.
One approach, you can also think about, is to use an environment with strong class loader isolation, e.g., an application server or OSGi container, and add a version number to the process definition key. This way you can run multiple versions of a process definition and the code that belongs to it in parallel. The camunda fox Community Edition allows that, too.

yes, i've thought about versioning process definition key for process changes that don't support simple migration.
but I don't see exactly how strong class loader isolation can solve the problem for class version: you would need one activiti engine per process version (in the same classloader as process code) ? what about persistence, would you also need one database per engine ?

thanks
Richard