this is a question about the JbpmCallback action provided by the jBPM version that is shipped with the JBoss ESB (in these tests I'm using ESB 4.4 and the contained jBPM 3.2.2 in a JBoss AS 4.2.3). I'm applying this action in order to get back from the ESB to a running process instance in jBPM. In ESB 4.4 I could also have applied the BpmProcessor service with the "SignalCommand" property for this purpose, but since this is not supported anymore in ESB 4.5 (and presumably in future version) I was looking for something general that hopefully stays.
To get back and forth between jBPM and ESB via JbpmCallback works fine (after one finds out that the necessary process information is expected in the message at Message.getHeader().getCall().getTo(), instead of getRepyTo() ...), but what did not work for me yet is to bring new data with the message into the process.
Specifically, I start the process (named "AccountingStandardProcess") from within the ESB like that (in the jboss-esb.xml):
<action name="startProcessInstance" class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor"> <property name="command" value="StartProcessInstanceCommand" /> <property name="process-definition-name" value="AccountingStandardProcess"/> <property name="esbToBpmVars"> <mapping esb="messageContent" bpm="bpmMessageContent" /> <mapping esb="settingsESB" bpm="bpmSettingsESB" /> </property> </action>So, there are two parts of the message body, messageContent and settingsESB, which are mapped into the jBPM context. This works fine, the bpm-Objects are existing within jBPM, can be modified there and are correctly returned if I call the ESB again via the ESBActionHandler (processdefintion.xml):
<node name="Call AccountingDelegateService in ESB" async="true"> <action class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> <esbCategoryName>Accounting</esbCategoryName> <esbServiceName>AccountingDelegateService</esbServiceName> <bpmToEsbVars> <mapping bpm="bpmMessageContent" esb="messageContent" /> <mapping bpm="bpmSettingsESB" esb="settingsESB" /> </bpmToEsbVars> <!-- <esbToBpmVars> <mapping esb="messageContent" bpm="bpmMessageContent" /> <mapping esb="settingsESB" bpm="bpmSettingsESB" /> </esbToBpmVars> --> </action> </node>As you can see, a part of this is commented. For just getting back to the ESB, the bpmToEsbVars mapping is enough. When I leave jBPM, the token stays at this node shown here, and gets back to it after calling JbpmCallback in jboss-esb.xml:
<action name="prepareCallbackMessage" class="com.wincornixdorf.icash.datasupplier.esb.actions.PrepareMessageForCallback"/> <action name="jbpmCallback" class="org.jboss.soa.esb.services.jbpm.actions.JBpmCallback"> <property name="esbToBpmVars"> <mapping esb="messageContent" bpm="bpmMessageContent" /> <mapping esb="settingsESB" bpm="bpmSettingsESB" /> </property> </action>
First, my action PrepareMessageForCallback just copies the "replyTo" object of the header into the "To" object (as described above). Then JbpmCallback jumps back and the process runs to its end without problems.
The data in messageContent has been changed meanwhile (in the ESB) and I need it also in the process. If I do it like that, even if I also have such a mapping in the ESBActionHandler (commented lines above), the new content is not copied into the process.
I tried also to give the jbpm variables new names when calling JbpmCallback, e.g.:
<property name="esbToBpmVars"> <mapping esb="messageContent" bpm="bpmMessageContent2" /> <mapping esb="settingsESB" bpm="bpmSettingsESB2" /> </property>
in order to access the changend content at a new name in jBPM, but this resulted in a runtime error which sounded somehow like that he was not able to create these variables at this stage.
So I guess, context variables in jBPM are only created at the start of the process, not when getting back to a running instance. This would make sense, but why can't I transmit changed message data when re-entering? Did I miss something or isn't this possible in principle? If not, this would be a hard restriction for using a combination of jBPM and the ESB.
Looking forward to your help,
Andre Skusa, Wincor Nixdorf, Germany