Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

8.3. BPEL

8.3.1. BPEL Component
Copy link

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
Copy link

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
Copy link

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>
Copy to Clipboard Toggle word wrap
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>
Copy to Clipboard Toggle word wrap

8.3.4. Consuming a Service from a BPEL Process
Copy link

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>
Copy to Clipboard Toggle word wrap
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>
Copy to Clipboard Toggle word wrap

8.3.5. Property Injection into a BPEL Process
Copy link

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>
Copy to Clipboard Toggle word wrap
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
Copy link

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
Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat