There are a motive for not exist a exposed API for 'SetProcessDefinitionVersionCmd' ?

[wendelkerr]

I was  trying to update the version of ProcessDefinition in the ProcessInstance and I found the class "SetProcessDefinitionVersionCmd", but it is necessary to call it from a commandExecutor. In my application, i use WELD and i can do the necessary cast for catch the commandExecutor. So i wonder, why there is no such exposed method to do it?

Att,
Wendel Kerr

[frederikherema1]

The SetProcessDefinitionVersionCmd (as the javadoc hints to) is to be used with great care and won't work for any process-definition you throw at it. Because this "process migration" is not feature-complete, we don't expose it in our API as we're not comfortable with "supporting" it as an API-feature.

However, since it's present in the codebase and tested, you can off course use it if you keep you're head with it. You can get a command-executor from the ProcessEngineConfigurationImpl (indeed a cast needed).

[wendelkerr]

Thanks for your reply Frederik !!

What do you think about we expose in the API, and explain in the javadoc that this method need to be used very carefully(I think it is explained already, but we can explain more) , and the every application is responsible for treat the exceptions thrown. Since everybody knows there are no miracle in change the version of process definitions.

Att,
Wendel Kerr

[jbarrez]

Experience has learned us that people don't read javadoc. That's why we don't expose it.

[silvioneto]

frederik, what do you mean by "'process migration'" is not feature-complete?

We realize that if we try to migrate an instance which its current task doesn't exist in the the destination process, the method will throw an Exception. But, what's the matter with it? The SetProcessDefinitionVersionCmd may let the instance somehow inconsistent?

I've just read the the Activiti In Action's section Dealing with process versioning and didn't realized how do you really deal with the limitation "that the already-running process instances will keep running against the existing version of the process definition." It's very common issue for us…

[mikedias]

Hi everyone!

And if the API method was called "tryUpdateProcessDefinition"? The volatile of method would be more clear!

Something like: "No miracles here" 🙂

[frederikherema1]

LOL… Perhaps we an offer an easy way to execute a command trough the API, like: managementService.executeCommand(), however this opens up a lot of the internals and might not be such a good idea

[mikedias]

This is an option that solves the problem, but I think that is more dangerous that update process definition… @=

I don't know if a method with "try" in the name is a good idea, but your limitation becomes more clear!

As @silvioneto said, we don't understand why update process definition is so evil  ]:-> … If the current activity exists in the new process definition, update. Otherwise, don't update. No miracles, right? This is OK for us. There is another situation that migration is a problem?

[jbarrez]

Well, if the activity maps one on one, it's easy.

However, it can easily go wrong. What if you have a user task. Now, in the next version this user task is part of a fork/join ie it is in parallel. Wehn you now simply use the method …. your process will be wrong, because you actually need to create an execution tree that maps to the new parallel behavior.

And this is only a very simple example, and as such it's a 'dangerous' thing

[mikedias]

Wow, you opened my eyes! With complex process, many situations can be problematic. *shok*

So, I agree with @frederick said. Execute a command via API is certainly a better option. Can we send a pull request with this?

PS: In the amazing activiti-neo4j, this will not be a problem!