So I can create a workflow programmatically on the fly. However as I know, may be wrong, I have to stop JBPM and deploy the workflow.
That is not true for either jBPM3 or jBPM4. You can deploy new process definitions at any time without reloading jBPM.
And jBPM5 for that matter
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.
We had the same kind of requirement that an admin in system can update the workflow at any time.
The solution we provided was as we know jBPM supports the version number for process definitions and whenever an admin makes updates to the workflow, the updated workflow will be saved with new version number. Admin has to choose whether the system should go with the executions of older version which is already created for the users or should go with the new version. If it is with new version, admin user has to force close all the executions for the old version and then allow the system to create the new instances for workflow with latest version, for all the users.
This is the workaround we provided in our system for client requirement.
Applying workflow updates on the fly to the running executions(process instances) is not supported by jBPM.