The BPEL process acts as an orchestration component of SOA. One of its fundamental abilities is to invoke web services. This recipe describes how to invoke the synchronous web service.
Before we start with the recipe, we need access to the synchronous web service. We will use the weather service from the Invoking the RESTful web services recipe.
The following steps describe the actions necessary in order to design the BPEL process for invoking the synchronous web service:
- We start the recipe by modeling the SOA composite. We add the web service to the SOA composite, and it should look like the following screenshot:
- In the BPEL process, we first assign the parameters for the web service. Next, we invoke the web service with the
<invoke>activity as follows:<invoke name = "CallWeather" partnerLink = "WeatherSvcs" portType = "ns2:WeatherPT" operation = "QueryWeather" inputVariable = "CallWeather_QueryWeather_InputVariable" bpelx:invokeAsDetail="no" outputVariable = "CallWeather_QueryWeather_OutputVariable"/>
- We finish modeling by assigning the web service results to the BPEL process output variable. Now, we are ready to deploy the BPEL process and test it inside the Oracle Enterprise Management Console. In the excerpt of Audit Trail, we see that the web service was invoked in a synchronous way as shown in the following screenshot:
We know that the SOAP over HTTP web service is exposed via the WSDL document. The synchronous and asynchronous web services are distinguished by the port type definition. Usually, we can distinguish the asynchronous web service from the synchronous web service in a way that the asynchronous web service has only the input message defined in the port type definition. Also the asynchronous web service has a callback port type defined. For our weather service, the port type definition is as follows:
<portType name = "WeatherPT">
<operation name = "QueryWeather">
<input message = "tns:GetWeather"/>
<output message = "tns:GetWeatherResponse"/>
</operation>
</portType>We can see that for the QueryWeather operation, the input and output variables are defined. For the synchronous web service, we use the request-response type of operations in the communication between the client and web service. This means that the client is operating in the blocking mode. The client invokes the web service and provides the input message and waits until the web service finishes and provides the output message. Note, the synchronous web service invocation is not a recommended approach to use in the long-running business processes. We introduce a web service in the BPEL process via partnerLink. When partnerLink is defined, we can call the web services with the <invoke> activity. The most common format of the <invoke> activity is as follows:
<invoke partnerLink = "NCName" portType = "QName"? operation = "NCName" inputVariable = "BPELVariableName"? outputVariable = "BPELVariableName"?> </invoke>
We have to define the partnerLink name, portType, and operation. If the web service also expects the parameters or the return values, we also need to declare the input and output variables.
We can also declare the fault in the synchronous web service port type. The faults are used when the web service cannot complete its operation successfully. The port type definition then states as follows:
<portType name = "WeatherPT">
<operation name = "QueryWeather">
<input message = "tns:GetWeather"/>
<output message = "tns:GetWeatherResponse"/>
<fault message = "tns:weatherStationUnreachable"/>
</operation>
</portType>The fault in the BPEL process can then be caught inline in the BPEL process <invoke> activity, or by the <catch> activity by the fault handler as follows:
<invoke partnerLink = "NCName"
portType = "QName"?
operation = "NCName"
inputVariable = "BPELVariableName"?
outputVariable = "BPELVariableName"?>
<catchfaultName = "FaultVariable"></catch>
</invoke>