"andreskusa" wrote : p1. The EsbActionHandler copies the necesary information into the replyTo-EPR of message.header.call, but BpmCallback expects this information at the to-EPR. This is correct. The invocations from EsbActionHandler are sending messages to a target service (the To EPR) and also including the necessary information for replying (the ReplyTo EPR). "andreskusa" wrote : So, even if you stay inside jBPM/ESB (i.e., if jBPM starts a service that immediately calls the BpmCallback action) you need to copy the replyTo-EPR to the To-EPR. But jBPM should not be invoking the reply service, it should be invoking another service which then sends its reply to the callback service. The processing of a RequestResponse mep in the pipeline will send a response to the ReplyTo EPR and, in this way, we are no different from specs such as WS-Addressing. "andreskusa" wrote : p2. This is not really a problem, but merely the fact that if you "leave" the ESB as I described in a. to c. above, you need to get the process information from the message leaving the ESB and set it into the new message (at Header.Call.setTo of course) entering again the ESB and attempting to call back the running jBPM problem. That is why I need to create an EPR. But this works without problems. Okay, that explains things. It is the correlation between the internal EPR and external services that we are currently missing. "andreskusa" wrote : Regarding the variable mappings it is like that I know now that these are also to be copied with the other process information (like tokenId etc.). But I need also specify it at all the places I described above (a-c). From your post I understand that you think that it is sufficient to define both mappings (esbToBpmVars and bpmToEsbVars) only at the start of the jBPM process, but this is definitely not the case No, they need to be specified on every node that communicates with the ESB. They define the variables which are specific to that invocation and are not specified globally on the process. "andreskusa" wrote : I just tested it again. Both mappings need to be specified in all jBPM nodes that leave jBPM into the ESB. If I leave out the bpmToEsb mapping, the changes done inside jPBM are not transimitted to the ESB and if I leave out the esbToBpmVars mapping at this place, the changes in the data done in the ESB are not transferred back to jBPM. This is correct. "andreskusa" wrote : So, the only things I would recommend are to document BpmCallback a bit better if this is really the preferred way for combining jBPM and the ESB. And maybe to get the information from replyTo, where it is already copied to. Then BpmCallback would be more intuitive to use. One thing that would also help would be to remove the variable mapping and scope from the EPR as there is no real need for this to be included in the information sent back to the callback service. They can be retrieved automatically from the process definition. "andreskusa" wrote : One additional thing: I figured out that if you immediately call back the jBPM process after leaving it, (or if you start several times the same process) you need to have a short stop time in between (e.g., Thread.sleep(10) is enough) in order to have jBPM up and ready. If the calls are too fast, the token is still locked. Maybe such a small pause could be included into the call back. This is strange, the messages should be covered by a transaction and sent on the transaction boundary. Can you send me an example of this? "andreskusa" wrote : Hope, you understand my setting better and these explanations were not too exhaustive ... :-) I have a much better understanding, thanks for this. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237822#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...