More on BPEL

2

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.

Share.

About Author

2 Comments

  1. Another interesting option with the Oracle BPEL Engine seems to be that only does it allow you to call out from a BPEL process to Java based services, but also the other way round: through a Java API you can initiate processes in the BPEL engine, as well as check their progress. See for an example: Initiating a BPEL Business Process using a Java UI.

    The tutorial BPEL Tutorial Tutorial 7: Invoking BPEL Processes through SOAP and Java on OTN also demonstrates how you can invoke a process in the BPEL Engine from Java: Processes can be invoked programmatically via a Java API provided through a stateless session bean interface by the BPEL Process Manager. The API is slightly different depending on whether you are invoking a two-way operation (which has both input and output messages) or a one-way operation (which just has an input message and returns no result). Most examples assume that the Java code invoking the BPEL engine is run locally, in the same JVM as the BPEL engine. Then it states that such needs not be the case:

    Using the Java API from a Remote Client
    The code examples as described above are executed within the same application server container as the BPEL Process Manager is running in. These APIs are remotable, however, and can be used via RMI from a remote application server. We do not currently ship code examples for this use-case – in part because the RMI client code is different based on which application server the client is running in. You should work with your Oracle support representative regarding how to use the BPEL process Manager Java API over RMI for your specific client configuration/environment.

    Excellent contents can be found in the Preview from Business Process Execution Language for Web Services” by Packt Publishing., Chapter 4 Oracle BPEL Process Manager (62 pages),see also the website http://www.bpelbook.com/. This book illustrates all major components in Oracle BPEL Process Manager, including Design, Deployment, Administration, the Oracle BPEL enhancements over standard BPEL, the Email and the JMS adapter and the Java integration. It provides some clear examples.

    Until now we have discussed how to develop, deploy, and manage BPEL processes on the Oracle BPEL Process Manager. We have also discussed how to integrate BPEL with Java resources. In complex real-world scenarios we may also need to access the BPEL Server functionalities. For example, we might want to develop our own console through which users could monitor active processes, start new process instances, set the priorities, etc. We might also want to integrate user tasks with BPEL processes.
    To realize these requirements, BPEL Server provides access to its functionality through a set of APIs. As the Oracle BPEL Server has been developed in Java, these APIs are packages for use by developers. Using them we can develop our own applications that interact with the server and provide information about the state of the process instances, enable their management, and provide other useful information. Oracle provides Javadoc files to help learn how to use these APIs. The BPEL Console also uses these APIs and the source code is provided (a set of JSPs). Developers can use it to learn how to use the APIs.

  2. Pingback: » Publishing PL/SQL “Services” as WebService using Oracle BPEL