Dynamic redeployment within JBPM

[jharby]

We have some long running processes and wish to give the customer the capability to change the process while running. An example might be a part gets shipped to a destination, then received, then repaired and normally the process would complete but we want to enable our customers to put another step before the end when the process is the received task. We realize this can't be done at the process level but could we use subprocesses or possibly web services that are invoked by an action?

[camunda]

I think this is the wrong forum for you, should ask in the user forum!

Anyway: What do you exactly want to do?

Do you want to improve the process if that situation occurs and then change the process definition to support this new requirement in future? Then you can just deploy a new process definition. Changing the version of a running process instance to a new version is supported for basic cases by the ChangeProcessInstanceVersionCommand.

Or do you want some possibility for a Ad-Hoc change in this one and only process instance? This is currently not supported by jBPM as far as I know, then we are maybe right in this forum again, because it would be a very interessting feature!

Regards
Bernd

[jharby]

Thanks for the response Bernd. We want to do the dynamic case as you mentioned secondly. But we don't necessarily need to change the process definition itself. It would be ok if we could change some code an action was calling (maybe via a web service??). It would be cool if dynamically changing the process definition were supported in the future. I think when you get into the really long running processes the requirement becomes more visible.

[camunda]

I agree. But I think is what exactly to support. Some "wild jumping" to existing states? Or introduce states "on-the-fly"? What is your vision on that?

But I think it is not easy to implement and not to high prirized in the Roadmap (but this, Tom can answer better).

[jharby]

Suppose I could clone a process with state, logging, etc. Then make my modifications and start the clone putting it into the identical state as its predecessor. The predecessor could be terminated and I could work on the clone. The issue we run into is that they can't go back and repeat the prior tasks.

[tom.baeyens]

basically, if you have a mapping between old states and new states, you could convert a process instance from one process definition to the next version

the old logs should be kept in the old process instance, the new logs in the new process instance. there should be a bidirectional reference between the old process and the new process instance

but that still needs to be implemented.

[brittm]

jharby,

jBPM 3.2 supports "late binding" of subprocess. This means that if you design your process in pieces (one master process containing chained together sub-processes), a long running master process can always pick up the latest sub-process version when the time comes to invoke that sub-process.

This is just one feature that that can be used to help jBPM effectively manage long running process.

-Britt

[jharby]

Thanks Britt, this is a huge help!