Resume BPM process after server restart

[calvinchu101]

I am using SwitchYard 0.6 Final in JBoss AS 7, I defined my bpm process as a component in Switchyard which calling bean services. There are logic in my jBPM process to wait for signal (JMS message from camel:binding.jms) and HumanTask (org.switchyard.component.bpm.task.work.jbpm.JBPMHumanTaskHandler).

I have enabled persistent="true" in my bpm component definition and I found records stored in PROCESSINSTANCEINFO, SESSIONINFO (and other jBPM tables) correctly. I found that if the process is in wait state (waiting for signal or Human Task completion) and if the server is restarted, the process would not resume even the signal was received or human task is completed. The process remains in the state before the server restart.

I did tested human task in jBPM 5.3.0.Final under a pure jBPM environment (use jbpm-gwt-console) and the process was able to resume when the human task created before server restart was completed. However, if the BPM process is managed by SwitchYard, the process is not resumed after that human task completion, I verified that the human task server is workfing fine as the STATUS in TASK table is marked as "Completed" after human task completion.

Does anyone using SwitchYard + BPM with signal/human task able to resume the process after server restart ? Is there any specific configuration in switchyard.xml or it is limitation of switchyard? Please advice and thank you very much !

[dward]

Calvin. Thanks for bringing this to our attention. We've been a bit "heads-down" working on 0.7, but I should be able to look at this tomorrow.  Thanks again!

[dward]

Calvin, to re-associate with a previously persisted session, you will have to somehow pass in the sessionId the stateful session was originally persisted with.

In 0.6, the sessionId should be populated in the response header per the variable: {urn:switchyard-component-bpm:process:1.0}sessionId.  If using the soap binding, this will show up in the soap headers section of the response.  (In 0.7, it will be {urn:switchyard-component-bpm:bpm:1.0}sessionId.)

In subsequent requests, you should pass in this same sessionId to make sure you are using the same persisted session.  If using the soap binding, this would go in the soap headers section of the request.

There is also a sessionId attribute on the <implementation.bpm> component configuration, but this is of limited use, obviously, as that would be a static definition for a dynamic variable.

Let me know if this works for you.  If not, I will have to dig in deeper.  Just so you're aware, however, all of Red Hat (except for our paid-support crew, of course)  is on vacation next week, so I might not be able to respond right away.

Happy holidays!

David

[dward]

(Also don't forget to pass in processInstanceId in addition to sessionId.)

[calvinchu101]

Hi David,

With {urn:switchyard-component-bpm:process:1.0}sessionId in the message header, I am able to resume the process after restart by JMS signal. Thanks!

But I am not able to do the same thing in Human Task, I use <bpm:taskHandler name="Human Task" class="org.switchyard.component.bpm.task.work.jbpm.JBPMHumanTaskHandler" /> in my bpm component configuration and I didn't find the method to set the previous sessionId. I also tried to set sessionId="1" in bpm:implementation.bpm such that the sessionId is fixed after restart. But it still not able to resume the processes upon Human Task completion. Can you please advice how to resume bpm process which pending on Human Task before the restart ?

Thank you very much !

[dward]

Calvin, we've started going through testing of 0.7.0.Final today.  I will include this in my list of manual things to test, and get back to you.  Hopefully it won't take too long.

[calvinchu101]

Hi David,

May I know if there are any update on resuming the process from Human Task ?

Also, with more testing, I found that if I specify sessionId="1" in bpm:implementation.bpm, it will raise exception and fail to create jBPM session (Session ID 1 not found!) when the SESSIONINFO table is empty. However, this scenario do exists during 1st time deployment. As it is not supposed to create the SESSIONINFO entry manually, is there any way SwitchYard could create the session if the specified session Id does not exists ? Thanks again!

[calvinchu101]

The human task issue is related to the JIRA case of jBPM https://issues.jboss.org/browse/JBPM-3673, as the MinaHTWorkItemHandler do not connect task server until the 1st request is received.

After restart, if a new process is started and creates a human task first. The previous processes before the restart would be resumed after the corresponding human tasks was completed.

With SY 0.7, as native WorkItemHandler from jBPM is allowed, it is much easier now to override the MinaHTWorkItemHandler and connect the task server upon initialization.

And I think SY should address the "Session ID not found" issue if sessionId is specified while deployed with an empty SESSIONINFO table (during 1st deployment).

[dward]

Hi Calvin, thanks for your continued effort on this, and I apologize in my delayed response.  I just finished up a chunk of other work I needed to get done, so I'll be getting back to this.  Sorry for the delay!  If a JIRA ends up being created from this, I will link it to this forum thread so you can follow it.