BPM continue processing after a Human Task

[jmorr003]

How does a BPM process instance continue processing after a Human Task is completed?

Looking at the helpdesk example, as I understand it the following set of steps happen:

1. Send a SOAP message to start the Helpdesk process
2. The Open Ticket service is called
3. The Review Ticket Human Task uses the SwitchYard CommandBasedWSHumanTaskHandler to send a Task to the Task Service (e.g. via the MinaTaskServer)
4. Once the Task has been sent to the Task Service the TaskClient connection is disconnected.

The Task can indpendently go through its own lifecycle, e.g. to completion, by interacting with the Task Service. However no events can be sent back to the original process (so it can continue) since it has closed the TaskClient connection.

The code below from the SwitchYard CommandBasedWSHumanTaskHandler, delegates the work of executing the Task to the jbpm CommandBasedWSHumanTaskHandler, which simple connects to the Task Service, registers for events (Completion, Failed, Skipped), adds the Task and returns. The code below then disconnects, which in turn calls dispose on the jbpm CommandBasedWSHumanTaskHandler that disconnects the TaskClient.

    /**
     * {@inheritDoc}
     */
    @Override
    public void executeTask(Task task, TaskManager taskManager) {
        connect();
        super.executeTask(task, taskManager);
        //  tasks get completed by humans!
        //taskManager.completeTask(task.getId(), task.getResults());
        disconnect();
    }

It would seem that the TaskClient connection would need to stay open so it could receive events from the Task Service about the Task it sent. Instead it closes, the original SOAP request to start the process returns, and the process does not complete processing.

Am I missing something?

[dward]

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.

[jmorr003]

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.

[dward]

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