Red Hat Training

A Red Hat training course is available for Red Hat Fuse

8.3. BPEL

8.3.1. BPEL Component

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.

8.3.2. Providing a Service with the BPEL Component

Procedure 8.8. 

  1. Define your process using WS-BPEL within JBoss Developer Studio (with JBoss Integration and SOA Development tooling installed).
  2. Define a WSDL interface for the BPEL service.
  3. Define a Deployment Descriptor using the ODE Deployment Descriptor editor bundled with JBoss Tools.
  4. Add the component containing the implementation and service interface to the SwitchYard configuration.

8.3.3. Example of BPEL Component Configuration

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)"/>
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=""

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

8.3.4. Consuming a Service from a BPEL Process

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">
      <process-events generate="all"/>
      <provide partnerLink="customer">
        <service name="ls:loanService" port="loanService_Port"/> 
      <invoke partnerLink="assessor" usePeer2Peer="false"> 
        <service name="ra:riskAssessor" port="riskAssessor_Port"/> 
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:reference name="riskAssessor"> 
        <sca:interface.wsdl interface="riskAssessmentPT.wsdl#wsdl.porttype(riskAssessmentPT)"/> 

8.3.5. Property Injection into a BPEL Process

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

8.3.6. Maintaining Multiple Versions of a BPEL Process

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.

8.3.7. Structure of a SwitchYard BPEL Application

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:
    JRE System Library [JavaSE-1.6]