How to migrate a BpmProcessor action using "SignalCommand" command from SOA-P 4.x to 5.x
Environment
- JBoss Enterprise SOA Platform
- 4.x (migrated from)
- 5.x (migrated to)
Issue
- We are migrating our SOA-P 4.2 (ESB 4.2.1) to SOA-P 5.2 (ESB 4.10). Since ESB 4.5 the command
SignalCommandis no longer available, we need to change our services which are using the command, e.g.:
<service category="xxxxx" name="xxxxx" description="xxxxx">
<listeners>
<jms-listener busidref="xxxxx" name="xxxxx" maxThreads="100" />
</listeners>
<actions mep="RequestResponse">
...
<action name="signal_process" class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
<property name="command" value="SignalCommand" />
<property name="esbToBpmVars">
<mapping bpm="xxxxx" esb="BODY_CONTENT" />
</property>
</action>
...
</actions>
</service>
- It seems we can use the JbpmCallback instead of the BpmProscessor to substitute the command
SignalCommand, am I right? If so, how can we set the variables mappingesbToBpmVars?
Resolution
To migrate the SignalCommand BpmProcessor action, flip the invocation ESB -> jBPM to jBPM -> ESB using EsbActionHandler. EsbActionHandler has the esbToBpmVars property.
For reference, see also the bpm_orchestrationX quickstarts.
Root Cause
The reason why the SignalCommand command was removed from BpmProcessor since ESB 4.5 (SOA-P 5.0) was discussed in JBESB-2315 and Community Forum (1), (2).
From (1) https://community.jboss.org/thread/144559:
The SignalCommand is no longer available, [...] because it is not safe to use it without additional information. Any service invocation from jBPM to ESB and back stores the appropriate information within the EPR and is automatically handled. All the ESB service has to do is respond to the correct EPR.
And from (2) https://community.jboss.org/thread/153723:
direct use of the signal command within jBPM 3 will fail very quickly once you move away from the simple scenarios, which is why we jump through those hoops. [...] The present integration focusses on interactions between ESB services and jBPM, forcing a 'one time only' execution of the signal. The EPR contains additional information necessary to enforce that guarantee, i.e. one request and one response.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
