JBossDeveloper

i agree with Rainer that API is the best way to go forward.

someting like a migrate method in the ProcessInstance class:

ProcessInstance migrate(ProcessDefinition newDefinition, Map nodeMapping);

the resulting process instance would be a new, cloned object structure with:
* a copy of the runtime structure
* a bidirectional link to the old process instance
* no shared objects to old process instance objects (meaning it must be a deep copy) so that the returned result can be saved by hibernate.

so the biggest challenge will be to extend jbpm with a generic mechanism for deep copies of the process instance data. probably that will imply an extension of the ModuleInstance interface (a module interface is an extension of a process instance for a perticular module)

regards, tom.

Hello All,

Any update on this? Is this new API/tool available for use now? Obviously, in most of the organisations process definitions change as business changes and so the need for migration.

In our particular case, we have implemented JBPM workflow for an order management system and since it is an e-business, business changes quite often and in this case it is very hard to say to management that "For all the existing 'orders' in the system we will use the OLD business process definition and for the new 'orders' the latest business process definition" and the nightmare would be when you have a bug in the existing process definition.

I appreciate your suggestions or information in this regard.

Thanks,
Arshad

Hi Arshad,

we have implemented some code that can do easy updates to new process definitions (in the case when the new process has the same node). That code can easly be enhanced to give some node-map as tom mentioned.

This code will get into a jbpm action soon, but sadly I havn't got time for it the last weeks...

The current code looks like this:

 jbpmContext = getJbpmContext();

 ProcessInstance pi = jbpmContext.getGraphSession().loadProcessInstance(processId);

 changeTokenVersion(jbpmContext, pi.getRootToken(), newVersion);

 ProcessDefinition oldDef = pi.getProcessDefinition();
 ProcessDefinition newDef = jbpmContext.getGraphSession().findProcessDefinition(oldDef.getName(), newVersion);

 logger.debug("changes process id " + pi.getId() + " from version " + pi.getProcessDefinition().getVersion() + " to new version " + newDef.getVersion());
 // you need tthe right or a patched version for this, see http://jira.jboss.com/jira/browse/JBPM-585
 pi.setProcessDefinition(newDef);

 logger.debug("process id " + pi.getId() + " changed to version " + pi.getProcessDefinition().getVersion());

 private void changeTokenVersion(JbpmContext jbpmContext, Token token, int newVersion) {
 Node oldNode = token.getNode();

 ProcessDefinition oldDef = token.getProcessInstance().getProcessDefinition();

 ProcessDefinition newDef = jbpmContext.getGraphSession().findProcessDefinition(oldDef.getName(), newVersion);
 Node newNode = newDef.findNode(oldNode.getName());

 if (newNode == null) {
 throw new ConfigurationException("node with name '" + oldNode.getName() + "' not found in new process definition");
 }

 logger.debug("change token id " + token.getId() + " from version " + oldDef.getVersion() + " to new version " + newDef.getVersion());

 token.setNode(newNode);

 // change tasks
 Iterator<TaskInstance> iter = getTasksForToken(token).iterator();
 while (iter.hasNext()) {
 TaskInstance ti = iter.next();

 Task oldTask = ti.getTask();
 // find new task
 Query q = jbpmContext.getSession().createQuery(HibernateQueries.findTaskForNode);
 q.setString("taskName", oldTask.getName());
 q.setLong("taskNodeId", newNode.getId());
 // TODO: q.setLong("processDefinitionId", newDef.getId());
 Task newTask = (Task) q.uniqueResult();

 if (newTask == null) {
 throw new ConfigurationException("node '" + newNode.getName() + "' has no Task configured! Check the new process definition");
 }

 ti.setTask(newTask);
 logger.debug("change dependent task-instance with id " + oldTask.getId());
 }

 // change childs recursive
 Iterator childIter = token.getChildren().values().iterator();
 while (childIter.hasNext()) {
 changeTokenVersion(jbpmContext, (Token) childIter.next(), newVersion);
 }
 }

I personally think it's probably a mistake to try and do too much auto-conversion. I think time would be better spent on an export-import feature.

You could then:
a.) export the running instance to say XML (which removes the instance from the database).
b.) edit (if necessary) the exported data to match the new process
c.) import the running instance against a different process version.

This has some advantages:
1.) it would allow batch processing of the upgrade
2.) strange migration rules could be implemented in something like XSLT
3.) you could choose which instances to migrate.

As long as you don't have any jBPM -> business table foreign keys it should work just fine.

"tom.baeyens@jboss.com" wrote:
you can update process definitions. (you have to evict the process definitions in hibernate's second level cache, though)

it is not encouraged, just as modifying java byte code in a running program is not encouraged. you can get into trouble real easy.

same goes for migrating process instances to a newer version. we plan to provide some support for it in the future, but it is easy to end up trouble.

regards, tom.

"jliptak" wrote:
I personally think it's probably a mistake to try and do too much auto-conversion. I think time would be better spent on an export-import feature.

You could then:
a.) export the running instance to say XML (which removes the instance from the database).
b.) edit (if necessary) the exported data to match the new process
c.) import the running instance against a different process version.

This has some advantages:
1.) it would allow batch processing of the upgrade
2.) strange migration rules could be implemented in something like XSLT
3.) you could choose which instances to migrate.

As long as you don't have any jBPM -> business table foreign keys it should work just fine.