-
1. Re: BPM continue processing after a Human Task
dward Jan 26, 2012 8:59 AM (in response to jmorr003)Nope. This is a bug in 0.3, but it's fixed in source for 0.4. The associated jira is here:
https://issues.jboss.org/browse/SWITCHYARD-559
Please see my comment on 12/Jan/12.
-
2. Re: BPM continue processing after a Human Task
jmorr003 Jan 26, 2012 10:31 AM (in response to dward)I had looked at the ticket, but missed the changes you made to the CommandBasedWSHumanTaskHandler, pushing a lot of the work into WSHumanTaskHandler and removing the explicity disconnect inside the executeTask method.
It looks like now the eventual closing of the TaskClient has been pushed up to the DroolsBPMExchangeHandler.stop(...) method, which if I understand correctly occurs once the Task is sent to the Task Service, and the we are done executing the incoming SOAP message through the ExchangeHandler.
Does the Service being executed live longer than just the one message call, perhaps thats where I am confused now. If so the DroolsBPMExchangeHandler.stop(...) wouldn't get called until the SwitchYard Service is shutdown, and the TaskClient would live for the life of the SwitchYard Service. Then the only problem comes about when the SwitchYard Service is shutdown, and the Task completion event is fired. There would need to be some sort of recovery check, to see if a Task was completed/failed etc. I guess that's where the jBPM process persistence comes into the picture.
Which leads me to another question, in the DroolsBPMExchangeHandler on line 129 I noticed you add but commented out the entity manager factory environment variable, is this a yet to be added feature, jBPM process persistence in SwitchYard?
Thanks.
-
3. Re: BPM continue processing after a Human Task
dward Jan 26, 2012 2:44 PM (in response to jmorr003)It looks like now the eventual closing of the TaskClient has been pushed up to the DroolsBPMExchangeHandler.stop(...) method, which if I understand correctly occurs once the Task is sent to the Task Service, and the we are done executing the incoming SOAP message through the ExchangeHandler.
Nope; the DroolsBPMExchangeHandler.stop(...) method is called as part of the entire deployment's lifecycle. It is not tied to the processing of individual incoming messages.
Does the Service being executed live longer than just the one message call, perhaps thats where I am confused now. If so the DroolsBPMExchangeHandler.stop(...) wouldn't get called until the SwitchYard Service is shutdown, and the TaskClient would live for the life of the SwitchYard Service. Then the only problem comes about when the SwitchYard Service is shutdown, and the Task completion event is fired. There would need to be some sort of recovery check, to see if a Task was completed/failed etc. I guess that's where the jBPM process persistence comes into the picture.
Correct; the task client lives for the life of the switchyard service. And yes, that means a recovery check would be needed if tasks get completed during the time the switchyard service is not active. I have had that in the back of my mind, but haven't created a jira for it yet. Thanks for the poke.
Which leads me to another question, in the DroolsBPMExchangeHandler on line 129 I noticed you add but commented out the entity manager factory environment variable, is this a yet to be added feature, jBPM process persistence in SwitchYard?
In my testing thus far, those environment variables have not been necessary for process persistence. I was playing with the use of environment and property overrides, but opted to comment out those lines instead of delete them for when I wanted to return to it. Again, good eyes.
Thanks.
Thank you Joshua for looking into this and sharing! It's very much appreciated.
David