[jboss-dev-forums] [Design of JBoss ESB] - Re: Problems with transmitting content from ESB to jBPM via

Hi Kevin, thanks for coming in into this discussion! Let me first just briefly explain what I'm generally doing: I'm using the JBoss AS, ESB and jBPM. In the AS there are some EJBs sending messages into one central ESB gateway queue and retrieving messages from other JMS queues (not ESB aware). So the process is like that: a. the ESB retrieves a message that starts the jBPM process with the ESB action/property BpmProcessor/StartProcessInstanceCommand. Also I add here the esbToBpmVars b. In the jBPM process I jump back to the ESB with the ESBActionHandler. Here I need to specify the esbToBpmVars again as well as the bpmToEsbVars for transporting the changed variables into the ESB. c. Back in the ESB I'm sending a message to an "outside" ordinary JMS queue (i.e., not ESB aware). This is retrieved by one of the EJBs and at one later point in time (i.e, completely asynchronous) this EJB sends again a message to the ESB gateway, which now does of course not start again the jBPM process, but should be able to jump back to the still running process. In order to realize espcially c, I had to look for a method to jump back. For now we're still using ESB 4.4, but of course don't want to apply methods that won't be available in future. Since I read in the blog of Bernd that this is the case for the ESB action/command BpmProcessor/SignalCommand, I tried to use BpmCallback. It is true that the necessary process information to get back via BpmCallback is copied into the message header when leaving jBPM with the EsbActionHandler. But there are two problems with it: p1. The EsbActionHandler copies the necesary information into the replyTo-EPR of message.header.call, but BpmCallback expects this information at the to-EPR. I found this in the code of BpmCallback: | EPR toEpr = message.getHeader().getCall().getTo(); | e.g. at http://anonsvn.labs.jboss.com/labs/jbossesb/tags/JBESB_4_2_1_GA_CP_IR9/pr... or http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/services/jbpm/s... 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. 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. Also it is no real problem to go around p1 by copying the information to the expected destination, although it is a bit tricky to figure out ... 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, 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. But again, also this is not problematic as you know how to do it :-). 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 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. Hope, you understand my setting better and these explanations were not too exhaustive ... :-) Cheers, Andre View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4237807#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...