Start a second process (Fire and forget)..

[garyp]

Maybe I'm thinking of this the wrong way.. But I have the following requirement..   trigger a business process via web service..  handle a few steps then fire a second process and return immediately...  IE: I don't want the client of the first process to wait for the second process to finish..   To accomplish this I had first created a custom action to send a JMS message to trigger the second process instance..   But since there was a sub process task in the jBPM I figured I'd use that instead..  save me the hassle of creating an esb entry to front the second process in the ESB..   But this doesn't seem to do a fire and forget (I had thought sync="true" would do this but the process still waits.)

So do you think I should use a JMS message or is there a way to accomplish with built in jBPM actions? 

thanks!

Gary

..  

[krisverlaenen]

In jBPM5, you can set the waitForCompletion attribute of the call activity (aka subprocess) node to false, in which case it won't wait for the triggered process to complete before continuing.

Kris

[garyp]

thanks.. but I forgot to mention (other than a "tag") that I'm using jBPM3..   Running in SOA-P 5 so I'm going to continue with jBPM3 till SOA-P supports the new version..    I'll stash this answer though till then..

thanks!

Gary

[mohreece]

Hi Gary,

I think your problem may be coming from the fact that 'normally' processes run synchronous, and that the JobExecutor (which is used to run asynchronous portions) is configured to use only one thread.

Therefore, even though you're using the 'async=true' attribute there will be one thread continuing the execution until it returns. Before the async part starts, the calling thread was used to execute the (first) process; the JobExecutor then takes over to execute the asyn Action (in your first process) and calls the second process, which starts to execute in that same thread - so the first process can do nothing but wait until that thread becomes available again before it can complete.

The solution lies in making (part of) the second process async; that gives the first process the opportunity to gain control again (the async executions are simply actions on a timer stack) before the second process is picked up again to continue.

Hope this helps a bit...

Regards,

Maurice