Red Hat Training
A Red Hat training course is available for Red Hat Fuse
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
- Define your process using WS-BPEL within JBoss Developer Studio (with JBoss Integration and SOA Development tooling installed).
- Define a WSDL interface for the BPEL service.
- Define a Deployment Descriptor using the ODE Deployment Descriptor editor bundled with JBoss Tools.
- 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)"/> </sca:service> </sca:component>
The BPEL component contains a single
implementation.bpelelement 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>
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
<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>
usePeer2Peerproperty 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
<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>
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:copysection copies Greeting property value into the
ReplySayHelloVarvariable 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>
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.bpelfile, 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/resourcesfolder are structured differently. The
switchyard.xmlconfiguration 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