More on BPEL

The last couple of weeks we’ve been playing around with the BPEL Designer plugin for JDeveloper 10.1.2. As BPEL is mostly used to integrate existing webservices, that’s what we started with.

To call an existing service, you need to use a partnerlink. Using the BPEL designer tool, you specify the WSDL file of the webservice to be called. This can be done using the url to the WSDL file online, but it’s better to download a copy of the WSDL and store it locally, since everytime the tool needs some information form the WSDL, the tool becomes unresponse; it seems to go online and parse the file every time. Using a local copy of the WDSL keeps the tools response snappy.

Most webservices I’ve tried to use do not provide any partnerlink information in their WSDL descriptions, which is required to make any calls using BPEL. Fortunately the tool caters for this and creates the required information in an extra file that imports the original WSDL of the webservice.

The next step is to use an invoke activity, this basically is an invocation of the webservice. For the invoke activity you specify the partnerlink to be used, and the BPEL variables that act as input for and output from the webservice. The variables can be simple types or structured pieces of xml, whichever the service defines.

Now to really integrate 2 services, you need to get information from the first service and feed some or all of it to the next service. This means you’ll need to extract data from the response and include it in the input for the second service. This is done using an assign activity, in which you define copy rules. A copy rule simply states where to get the data from and where to copy it to.

In our example, we’re getting the temperature for an airport from the first service, and call another service to convert the temperature from degrees Fahrenheit to Celsius. Nothing fancy but it’s just a way to call 2 services and pass data from one to the other. The first services returns a string containing the temperature, so we’ll somehow have to extract the numbers of degrees from the string, because the second service requires a number as input. This is achieved by using a copy rule, where we don’t copy directly from a variable but use an expression containing xpath functions to get to the variable data and strip the temperature from it:

substring-before(substring-after(bpws:getVariableData('getTemp_out','return'),' is '), ' F')

The temperature, along with 2 other input params, is copied to the input for the second service does the conversion.

WSIF binding

One of the other things we were interested in is how to call java code as part of a BPEL process. There are 2 ways to do this locally, and another way is to wrap the javacode using a webservice and call that from the BPEL process. But doing so, you get all the incurred overhead. So as far as we’re concerned, the most interesting option is to use a WSIF binding. This means that you have to create a WSDL file that acts as a wrapper for the java calls containing the code you want to call. Unfortunately, this needs to be done by hand, and as Andrej stated some time ago, the easiest way to do so is to use an existing example. Still you need to take great care when editing the file, and some knowledge about WSDL is no luxury at all.

A detailed example on how to call java using a WSIF binding can be found here. One of the things that strikes me though is the fact that the java class to be called needs to be put in a system directory on the BPEL server. This seems to imply that all classes for several BPEL processes end up in the same directory…

The third option to call java is to use it embedded in the BPEL process, which means that a java codesnippet is included in the BPEL file. However, we weren’t able to get this working. Maybe it’s the beta software, I haven’t checked this yet with the Eclipse plugin.