1 Reply Latest reply on Aug 10, 2011 1:54 AM by tob1as

Deployment of process, creating KnowledgeBase

mariemm Aug 9, 2011 8:19 AM

For now we are not using Guvnor or anything special for deploying and storing process definitions, we just have files with definitions. Guvnor seems to be too big and complex for our needs.

We want to keep different versions of process definition. When new version is created, the processes which are running (in some wait state) still continue with old version (since there could be many errors when changing definition during run - eg. missing variables).

Is anyone using jBPM5 in this way? Could you share your experience?

We are considering saving definitions (all versions) in DB. When new process starts - it get the newest version, for the running it gets the version which process started with.

It is more less the same behaviour as it was in jBPM 4 - it was generating version number automatically.

http://docs.jboss.com/jbpm/v4/userguide/html_single/#deployingaprocess

Another question about preparing knowledge base: what is best practice to use it?

For running process it needs definitions for itself and also for all subprocesses. And also for subprocess run, it needs to know parents definition. I don't think it is smart to create knowledge base with all definitions - it takes long and I don't which definitions will be really used.

Thanks.

1. Re: Deployment of process, creating KnowledgeBase

tob1as Aug 10, 2011 1:54 AM (in response to mariemm)
I do not have any experience with this, but did you look at:
5.8.6. Updating processes and 5.8.6.1. Process instance migration

Whenever a process is updated, it is important to determine what should happen to the already running process instances. There are various strategies one could consider for each running instance:
Proceed: 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.
Abort (and restart): The already running instance is aborted. If necessary, the process instance can be restarted using the new process definition.
Transfer: The process instance is migrated to the new process definition, meaning that - once it has been migrated successfully - it will continue executing based on the updated process logic.
Regarding the knowledge base, should that not be instantiated only once at the very beginning? I think processes can be deployed to a running knowledge base.
Actions