Hi
I'm not an expert but i have thought about this problem and make some trying approaches yet. Please any real expert feel free to correct if i'm wrong.
Actually in JBPM 4 you may even have a version number within a process definition and deploy and undeploy dynamically multiple instances of the "same" process defintion with multiple versions. What hapens is that every "old version definition" process instance deployed jobs still run whithout change (because they are already into the JBPM database). This is even true if you restart JBPM (without clearing the JBPM database). Only newly started jobs take the new process definition. Therefore i think "in progress" job cannot be changed on the fly.
But it is only the technical part of the story. If you plan to dynamically deploy processes, that is that you plan to change processes according to the BPM theory as exposed by Tom: 1/ managers change workflows without concerns of "technical details" through JPDL or BPMN2 and 2/ software team implements those "technical details" among wich the business data and the user interface..
In my opinion, the very important thing when aiming to change a workflow "on the fly" is to insure that the business code nor the business database structure will not change. I bet this is generally not true because the business organization/rules changes accordingly. Therefore your post should raise the question of your business database migration and user interface reverse compatibility strategy.
I recommend you make sure that the code nor the data do not change for any kind of workflow change you are planning.
- If true (perhaps using scripting feature) you can use the process defintion versions knowing that inprogess job will not change on the fly.
- If not true you should think about restarting JBPM and in addition think about two possible approaches 1/ migrate the whole database(s) (including business and JBPM objects) or 2/ migrating database business part only and have your business java code and view java code attached to process definition version numbers insuring reverse compatibility. It seems a bit tricky but I cannot see any other way to maintain end user service while changing workflow and datastructure with reverse compatibilyty.
Maybe somebody have a better approach, i would be really interested into it too.
Best Regards
JeanNo