8.3. BPEL

The BPEL Component is a pluggable container in SwitchYard that allows you to expose a WS-BPEL business process as a service through an interface defined using WSDL.

Here is an example of the component section of the SwitchYard configuration:

 <sca:component name="SayHelloService">
        <bpel:implementation.bpel process="sh:SayHello"/>
        <sca:service name="SayHelloService">
          <sca:interface.wsdl interface="SayHelloArtifacts.wsdl#wsdl.porttype(SayHello)"/>
        </sca:service>
  </sca:component>

The BPEL component contains a single implementation.bpel element that identifies the fully qualified name of the BPEL process. This component may also contain one or more service elements defining the WSDL port types through which the BPEL process can be accessed.

In the packaged Switchyard application, ensure that the BPEL process associated with this fully qualified name must be present within the root folder of the distribution, along with the deployment descriptor (deploy.xml). Here is an example of the deployment descriptor for the BPEL process referenced above:

    <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
     xmlns:examples="http://www.jboss.org/bpel/examples">

    <process name="examples:SayHello">
     <active>true</active>
      <retired>false</retired>
      <process-events generate="all"/>
        <provide partnerLink="client">
          <service name="examples:SayHelloService" port="SayHelloPort"/>
      </provide>
    </process>
    </deploy>

To enable a BPEL process to invoke other services, you need to define the WSDL interface representing the service to be consumed, using an invoke element within the deployment descriptor. For example, in the deploy.xml file:

  <process name="ls:loanApprovalProcess">
      <active>true</active>
      <process-events generate="all"/>
      <provide partnerLink="customer">
        <service name="ls:loanService" port="loanService_Port"/> 
      </provide> 
      <invoke partnerLink="assessor" usePeer2Peer="false"> 
        <service name="ra:riskAssessor" port="riskAssessor_Port"/> 
      </invoke> 
  </process>

Here, the usePeer2Peer property informs the BPEL engine not to use internal communications for sending messages between BPEL processes that may be executing within the same engine, and instead pass messages through the SwitchYard infrastructure.

For each consumed service, you can then create a reference element within the SwitchYard configuration to locate the WSDL file and identify the port type associated with the required WSDL service or port, as shown in the switchyard.xml file below:

  <sca:component name="loanService">
      <bpel:implementation.bpel process="ls:loanApprovalProcess" />
      <sca:service name="loanService">
        <sca:interface.wsdl interface="loanServicePT.wsdl#wsdl.porttype(loanServicePT)"/> 
      </sca:service> 
      <sca:reference name="riskAssessor"> 
        <sca:interface.wsdl interface="riskAssessmentPT.wsdl#wsdl.porttype(riskAssessmentPT)"/> 
      </sca:reference> 
  </sca:component>

You can inject properties into your BPEL process definition by using the SwitchYardPropertyFunction.resolveProperty() XPath custom function. The bpel:copy section copies Greeting property value into the ReplySayHelloVar variable in example shown below:

  <bpel:copy>    
    <bpel:from xmlns:property="java:org.switchyard.component.bpel.riftsaw.SwitchYardPropertyFunction"
      expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0">
       <![CDATA[concat(property:resolveProperty('Greeting'), $ReceiveSayHelloVar.parameters/tns:input)]]>
    </bpel:from>
    <bpel:to part="parameters" variable="ReplySayHelloVar">
      <bpel:query queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath1.0"><![CDATA[tns:result]]></bpel:query>
    </bpel:to>
  </bpel:copy>  

You can use the BPEL processes to implement long lasting stateful business processes. However the BPEL process may need to change, over the course of its lifetime, to accommodate new requirements. This introduces the problem of how to deal with the existing active instances of the BPEL process that may not complete for weeks, months or even years. To deal with multiple version of a BPEL process and to enable new requirements to be introduced (while still preserving the original process definitions associated with existing active process instances), you can associate a version number with the BPEL process by adding it as a suffix to the BPEL file name.

For example, if your BPEL process is located in the HelloWorld.bpel file, then you can simply add a hyphen followed by the version number, such as HelloWorld-32.bpel. This indicates that this is the thirty second version of this BPEL process. Whenever you define a new version of the BPEL process, package it in the SwitchYard application along side the previous versions of the BPEL process. It is important that the older version of the BPEL process remain in the SwitchYard application until there are no longer any active process instances associated with that version. You need to then re-deploy the SwitchYard application, without undeploying the previous version. If you undeploy the previous version of the SwitchYard application, the BPEL engine deletes all outstanding active instances associated with the deleted process definitions.

You can version the BPEL process but not the WSDL interfaces. So you must ensure that any changes made to the WSDL interfaces are backward compatible, so that both the new and older versions of the BPEL (that still have active process instances) are not affected by the changes.

For SwitchYard BPEL applications, the artifacts within the src/main/resources folder are structured differently. The switchyard.xml configuration file is located in the META-INF folder. However, the BPEL deployment descriptor (deploy.xml), and the BPEL process definition are located in the root folder. You can locate the WSDL interface definitions, and any accompanying XSD schemas in the sub-folders. You must ensure that the BPEL process and SwitchYard BPEL component configuration define the correct relative path for the artifacts.

Here is an example that shows the structure of the say_hello SwitchYard BPEL quickstart:

say_hello
    src/main/java
    src/main/resources
         META-INF
          switchyard.xml
       deploy.xml
       SayHello.bpel
       SayHelloArtifacts.wsdl
    JRE System Library [JavaSE-1.6]
    src
    pom.xml