MASTERTHEBOSS.COM

BPM promotes a model-based approach to task definitions: it encourages a top-down approach to service orchestration and requirements. Since the process are defined by the businessmen this should ensure that they drive the business the way they want. In this article we'll see how SOA and BPM are the perfect combination to model your business. 

One of the key aspects of SOA is Service Orchestration : that is the arrangement of business processes. In this article we'll see how we can achieve this with the combination of JBPM and ESB technologies.

JBPM and JBoss ESB can work with each other on both sides: as a matter of fact you can make calls to JBPM environment from the JBoss ESB. You can as well invoke the JBoss ESB services from JBPM: this is what is called service orchestration. Let's see the first communication: 

JBoss ESB calling JBPM

JBossESB can make calls into jBPM using the BpmProcessor class from jboss-esb.xml. The properties
passed to the class are the different commands sent to jBPM. Available options are:

NewProcessInstanceCommand - Start a new ProcessInstance

StartProcessInstanceCommand - Start a new ProcessInstance and moves it to the first Node

CancelProcessInstanceCommand - Cancel a ProcessInstance.


Picture 1: JBoss ESB invoking JBPM process

Here's an example:

<jbossesb>
    ....
    <action name="create_new_process_instance"  class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">

        <property name="command" value="StartProcessInstanceCommand" />

        <property name="process-definition-name"

value="simpleProcess"/>

        <property name="actor" value="Username"/>

        <property name="esbToBpmVars">

            <mapping esb="eVar1" bpm="counter" default="45" />

            <mapping esb="BODY_CONTENT" bpm="theBody" />

        </property>

    </action>

</jbossesb>

Notice the optional property "actor" which is used to inject the actor id into JBPM.
On the other hand the property "esbToBPMVars" defines a list of variables that need to be extracted from the EsbMessage and set into jBPM context for the particular process instance.

JBPM invoking ESB services

This is the most interesting part, also known as Service orchestration.
You can invoke ESB services embedding some special actions inside your process definition.
You can communicate with ESB in a few ways:

1) one-way call

This way we send information from JBPM to the ESB. How can we do this ? we invoke an action named EsbNotifier when there's a transition from one node to another.
Since it's a one-way call we can only pass information from JBPM to ESB. For this purpose we use
the bpmToEsbVars.

 
Picture 2: One way call to JBoss on Transition from one node.

<process-definition name="bpm_orchestration">
...
<node name="ShipIt">

<transition name="ProcessingComplete" to="end">

<action name="Action1" class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbNotifier">

<esbCategoryName>BPM_Orchestration</esbCategoryName>

<esbServiceName>Service1</esbServiceName> 

<bpmToEsbVars>

<mapping bpm="entireCustomerAsObject" esb="customer" />

<mapping bpm="entireOrderAsObject" esb="orderHeader" />

<mapping bpm="entireOrderAsXML" esb="entireOrderAsXML" />

</bpmToEsbVars>

</action>

</transition>

</node>

2) Two way communication

If you need to return information to your process, then you can use the  EsbActionHandler.

The EsbActionHandler is attached to the node (and not to the transition!). When this node is entered this action will be called. The EsbActionHandler executes and leaves the node waiting for a transition signal. The signal can come from any other thread of execution, but under normal processing the signal will be send by the JBossESB callback Service

Picture 3: Two way call from JBPM Node to JBoss ESB.  

<process-definition name="bpm_orchestration">
...
<node name="Intake Order"> 

<action name="Action1" class=

"org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">

<esbCategoryName>BPM_Orchestration</esbCategoryName>

<esbServiceName>CallBackService</esbServiceName> 

<bpmToEsbVars>
        <mapping bpm="theBody" esb="BODY_CONTENT" />
</bpmToEsbVars>

<esbToBpmVars>
        <mapping esb="BODY_CONTENT" bpm="theBody"/>
</esbToBpmVars>

</action>

<transition name="" to="Review Order"></transition>

</node>

Notice here that since the communication is two way there's a mapping of variables on each side:
The JBPM variable theBody enters into the ESB as body of the Message.
The same variable is used to return information to jBPM after the Service has been invoked.

3) Two way communication with timeout

When using the EsbActionHandler action it maybe that you want to limit how long you want to wait for. For this scenario you can add a timer to the node. The timer can be set to a certain due date. In this case it is set to 10 seconds. In this scenario if the Service takes over 10 seconds then a transition to the "ExceptionHandling" node takes place. As a matter of fact this is a good practice when something undefined goes wrong (for example the Service is waiting to connect to a remote resource )

<node name="Service1" async="true">
    <action class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
        <esbCategoryName>MockCategory</esbCategoryName>
        <esbServiceName>MockService</esbServiceName>
    </action>
    <timer name='timeout' duedate='10 seconds'  transition='time-out-transition'/>
    <transition name="ok" to="Service2"></transition>
    <transition name="time-out-transition" to="ExceptionHandling"/>
</node>

How do you deal with ESB exceptions ?

You can handle exceptions in two ways: the first one is done using the exceptionTransition, the latter with a decision node which checks for error code in JBPM execution context.

Scenario 1 : Exception Transition

<node name="Service1">
    <action class= "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
        <esbCategoryName>ESBCategory</esbCategoryName>
        <esbServiceName>ESBService1</esbServiceName>
        <exceptionTransition>exception</exceptionTransition>
    </action>
    <transition name="ok" to="Service2"></transition>
    <transition name="exception" to="ExceptionHandling"/>
</node>

Here the ESB Service was reached, but something goes wrong during processing. The exception is reported to JBPM which drives the process to the transition named "exception".

Only if the call was made from the EsbActionHandler it makes sense to report back the exception to jBPM. If the call was made from the EsbNotifier jBPM processing has already moved on, and it is of little value to notify the process instance of the exception. This is why the exception-transition can only be specified for  EsbAction-Handler.

Scenario 2: Exception Decision

This other way is JBPM oriented solution: as a matter of fact the ESB simply returns a variable to JBPM named error code in this sample. Then JBPM checks in a decision node against the value of this variable. As a matter of fact evaluating error codes in Decision nodes is itself a good practice also when using JBPM standalone.

<node name="Service3" async="true">
  <action class=
  "org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
     <esbCategoryName>MockCategory</esbCategoryName>
     <esbServiceName>MockService</esbServiceName>
     <esbToBpmVars>
        <mapping esb="SomeExceptionCode" bpm="errorCode"/>
     </esbToBpmVars>
  </action>
  <transition name="ok" to="exceptionDecision"></transition>
</node>
   
<decision name="exceptionDecision">
   <transition name="ok" to="end"></transition>
   <transition name="exceptionCondition" to="ExceptionHandling">
      <condition>#{ errorCode!=void }</condition>
   </transition>
</decision>

Picture 4: Possible Exception handling scenarios

Conclusion:

One of the most import features of Service Oriented Architecture is the agility: that is the ability to react more quickly to changes in the way IT systems need to be deployed and used, as well as being able to leverage existing IT investments. However SOA is not tied to a particular technology nor it belongs to a group of people (like the developer). SOA belongs to the business as a whole. Since your process are modelled by the business area as we said (and created by the developers), that's the reason why SOA and BPM are a perfect combination.

{fcomment}