Kevin wrote : | Having the process instance inform a service would be a cleaner way of handling this scenario. | But how to implement this if you think of the use case that an external client asks for the status of the process instance? Kevin wrote : | It is certainly true that something needs to manage any correlation with the external services. | ... | The older signal functionality is broken and token id is not sufficient. There are very good reasons why we rewrote that functionality. | Bernd wrote : | You can set an "expected state" on the jbpm SignalCommand. And I think if you get some really external signal, you need he SignalCommand, or how do you want to get around this? | You skipped the second question in that sentence ;-) Let's say you handed over the token id as correlation identifier to a third party application. It calls back, e.g. via JMS, containing only the token id. Now you have to signal the process instance with that token id, right? Okay, I see your problems with the pure Signal. But otherwise correlation has to be solved correctly inside of the ESB, in this example the ESB needs to restore all these EPR data (token-id, node-id, counter, ...) from the token-id as correlation identifier. And currently this functionality is missing, so this is why I see the demand for the "old" SignalCommand. By the way, an often requested use case is to update the version of the ProcessDefinition of a special ProcessInstance (e.g. to apply a fix). This is possible with a Command in jbpm, even if it is marked as experimental, since it can cause some problems. One problem with the currrent implementation is, that node-id has changed, so the EPR isn't working. I added a note in the ChangeProcessInstanceVersionCommand but think we can ignore that for know. If people use that command, they should know what they are doing... Kevin wrote : | Why token id and not process instance id? | I always work with the token id, because it is unambigous if multiple tokens exist for the ProcessInstance. Kevin wrote : | These are all issues that we take into consideration with the current approach. | Basically I agree with it. I am not complaining about the solution as such, the problem is more the too complicated code and missing examples and the lack of an excellent tutorial for it. And some "details" are missing, like the correlation stuff. All of it "just" a matter of resources and time ;-) apestel wrote : | When the process finishes (signal returns after couple seconds), the web app extracts the loan result from the finished jBPM process and displays it in a web page to the user. | This is a common discussion. Basically you should not tightly couple the process with the user interface. As Kevin wrote, other things can happen in between that interrupt normal process flow. Another argument is, that you want to gain flexibility in changing your business processes. For example you change the loan application to include a human task in some cases. Now you have to change your web application too! But you shouldn't! Better is some kind of generic piece of software in the web application that somehow can handle the "result" of the signal (wait-state x, ended, ...) in a generic way... Cheers Bernd View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200079#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...