Process Version

[amin-mc]

Hi

I have the a process definition with an id of "process-A" and a version of 1.  I have process instances which refer to the process definition.  I then create a new process definition which is a new version of process-A and give it the id of 'process-A' and version 2.  Should the old process instances use the old version and new process instances should use the new version?  This does not seem to be the case.  It seems as though my old process instance is using the new version and the knowlegdebase hasn't registered the old version of the process definition even though I have specified this. Am i missing something?  Do you need a new process id for the updated process definition?  Surely I would expect to be able to load 2 bpmn process definition with the same id but different versions and the process instance should use the approriate definition....

Any help on this would be appreciated.

Thanks

[amin-mc]

Hi

Can anyone advise on this? 

Thanks

[eaa]

As far as I remember, 'version' attribute is not being used by jBPM core. If you want to have a new version of a process, it must have a different id.

jBPM5 supports 3 different ways to handle new "versions" of a process definition:

1. New version is only applied to new instances: in this case, the old instances continue using the old definition and new instances use the new one. Here, the whole responsibility is thrown upon client (API user) shoulders: you must assure that both versions are in the kbase and that whenever you start a new process you are using the correct (newest) id.
2. Process instance migration: jBPM5 has some API that allows you to migrate running instances of your processes to a newer version. Again, newer means different id. Once all your instances are migrated you no longer need the old definition of the process in your kbase. Process instance migration is now always a trivial process and in many cases is not possible to do it.
3. The third approach can only be aplied to certain processes and consists in abort all the existing process instances and then start them again with the new definition (again, different id).

For more information please read this section of jBPM5 documentation: http://docs.jboss.org/jbpm/v5.1/userguide/ch05.html#d0e1768

[amin-mc]

Thanks for your reply.  Is there a way to extend jbpm5 to support version?  We want the ability to deploy different versions of the same process definition id.  I would've thought that the process instance should have the appropriate process definition attached to it but this doesn't seem to be the case.  It works in some cases where you can define new ids but in our usecase we have up stream systems that fire requests to start a process and asking them to update the process id everytime the process defintion changes (even adding a new node) doesn't seem to be feasible at the time.  I am happy to extend jBPM  5 but it would be great if i could get some pointers on what i need to do so version number can be supported.

[amin-mc]

I noticed this:

"The running process instance proceeds as normal, following the process (definition) as it was defined when the process instance was started. As a result, the already running instance will proceed as if the process was never updated. New instances can be started using the updated process."

does this mean if my process instance is persisted and then i signal to it again it will follow the new definition?  I am slightly confused by this. to me the process instance should use the process definition it started with unless i explicity try to migrate it. 

[eaa]

One of the good things about open-source projects is that! Of course you can improve it. If you want to extend jBPM5 first take a look at its code here: https://github.com/droolsjbpm/jbpm

Then you can join IRC channel #jbpm in irc.codehaus.org server. There you can find krisv, which is the lead developer of jBPM5 and tsurdilo, "the tooling" guy. So feel free to enter the channel and start asking.

[eaa]

The sentence you have pasted is saying what you are expecting: old instances (even if persisted) will continue using the old definition.

[amin-mc]

Unfortunately this doesn't work.  I have tested this.  I created a process instance with version 1.0 and then persisted it.  I then loaded a new definition with the same id and version 1.2.  When i signal to the old process instance it uses 1.2 instead of 1.0.  The  knowledgebase returns the process definition of 1.2

[eaa]

But you are changing the definition. As I mentioned before, "version" attribute means nothing to jBPM5. So, if you put a new process definition with the same id that an already existing process, all the persisted process instances will use it (the new one). The "version" attribute doesn't matter.

The problem is what the documentation refers as "updated process" or "new version". In reality there is no update, it is just a complete different process what you have , even if one is based on the other.

Summarizing:

• 1 id -> 1 process definition. THE VERSION DOESN'T MATTER.
• When a process instance is loaded from the DB, a process definition with the same id as the id referenced by the process instance is taken from the kbase. If you have change the definition, then the process will use it. If you didn't migrate it using the API provided by jBPM, errors could occur.
• You can "logically" update a definition y adding a new process with a new id and:
  • Migrating all existent process instances to e this new process id
  • Letting the existing process instances to continue with the old definition (old id) and start the new processes using the new version new id)
  • Abort all the existing process instances and re-start them using the new version (new id).

[amin-mc]

Thanks for your reply.  Is there anything on the roadmap to support versioning?  If there isn't then we may have to implement something that can support it.

[krisverlaenen]

Amin,

The solution we usually recommend is the name as the process as a unique identifier and as id take something like processname.version.  Instead of starting a process by id, you could then use a helper method that starts a process by name.  This will look up the latest version of the process definition with that name, and then start the process with the id that was found.  This would allow you to start processes the same way (for example when processing streams), regardless the exact version.  Would this solve your use case?

This is currently not implemented as part of the code base, but if you would be interested in adding a startProcessByName method, we would definitely be interested in adding this.

Note that the approach that you tested, where you change the process definition while a process instance is already running (in this case you loaded a newer version of the process definition with the same id), is technically possible, but not recommended.  The reason is that jBPM uses id as a unique identifier (so two process definitions with the same id cannot coexist) and that this ignores process instance migration (as you just update the process definition without the engine knowing, if you do this, you're responsible for making sure everything still works).

Kris