Deploying BPEL processes in a High Available Application Cluster

Introduction
Oracle’s scalable application architecture in combination with the BPEL architecture combines the best elements to create a high available and high performance environment. This article describes a solution to deploy multiple BPEL processes into a high available application cluster.

Overview
In general the deployment of BPEL processes can be done as follows:

• Using the Oracle BPEL console.
• Using Oracle JDeveloper 10g.
• Using the obant tool.
• Copy files into the Domain’s deployment area on the BPEL server.

The first three deployment mechanisms are based on deploying a single process to the BPEL server. The last deployment mechanism can be used to deploy multiple files. While these solutions are working well for most common environments, it will be more complex when a clustered environment is in place. Most of the previous mentioned deployments must be executed multiple times, which can result into faults.

This article describes how to deploy BPEL processes to a clustered application server environment. In this scenario we will have three (3) instances of Oracle Application Server 10g. On each of the server an Oracle BPEL is installed. This is shown as example in the next diagram.



Each application server is added to a logical cluster. The cluster can be defined via Oracle Enterprise Manager 10g. This applies also for adding the application server instances to this cluster. It is assumed that the application servers are using the Oracle Database 10g for retrieving and storing their data. This database is made high available via Oracle Real Application Clusters.

Solution
Define a logical application cluster and add each application server to this cluster. This can be done via Oracle Enterprise Manager 10g.

• Create an application cluster, e.g. “BPEL_AS_CLUSTER”.
• Add each application server instance to this cluster.

After creating the cluster and assigning the application server instances, a cluster exists that contains three application instances. Create for this cluster an OC4J instance named, for example “OC4J_BPEL_DEPLOY”. This OC4J instance will marked as not started. Creating the OC4J instance is done via Oracle Enterprise Manager 10g.

After creating the OC4J instance, each application server will now have a local OC4J instance. The power of the OC4J instance, in other words a J2EE environment, is that it can deploy EAR and WAR files. Creating an EAR or WAR file and deploy this to the application server, results that this file will be unpacked in each OC4J instance.

Using this mechanism for BPEL processes, it confirms to the industry standard of J2EE deployment.

Create an EAR file that contains all the BPEL jar files that must be deployed. For example, create an EAR file with an application name “bpel_deploy” containing a web application named “files”. The names must be conforming to the EAR/WAR structure. In this example the EAR file contains a WAR file that contains the BPEL jar files.

bpel_deploy.ear
meta-inf/application.xml
files.war

files.war
web-inf/web.xml
bpel_ProcessTaks_1.0.jar
bpel_HelloWorld_1.0.jar
bpel_CreditRatingService_1.0.jar

Deploy the EAR file to the OC4J_BPEL_DEPLOY instance of the cluster. The trick is that the EAR file will be deployed to each OC4J instance on each application server! This results that all BPEL jar files are copied to all servers.

The deployment of the EAR file is done via Oracle Enterprise Manager 10g or via Oracle JDeveloper.
After this deployment the BPEL servers must me made aware that BPEL jar files have been deployed. Making the BPEL servers aware of these jar files is done once, only during the initial setup. This is done by replacing the temporary directory for BPEL processes on the server to point to the directory where the BPEL jar files are extracted from the EAR file.

This can be done as follows (UNIX example):

rm ${ORACLE_HOME}/integration/orabpel/domains/default/tmp

ln –s ${ORACLE_HOME}/j2ee/ OC4J_BPEL_DEPLOY /applications/bpel_deploy/files
${ORACLE_HOME}/integration/orabpel/domains/default/tmp

Each time a new EAR file is deployed, with all the BPEL jar files, the BPEL servers are aware that new BPEL processes are ready to apply in the BPEL server environment.

Conclusion
Using the EAR/WAR mechanism of J2EE for deployment of BPEL jar files, results in a more industry standard compliancy. The deployment is less complex to maintain in a high available environment. The risks of faults during deployment are reduced. Deploying the BPEL files is done in the same way as normal J2EE application. Deployment is done via HTTP or HTTPS protocol, making no need of special configuration in the network. Multiple BPEL processes are deployed at once.

BPEL Correlation
This usefull article is missing from Antony Reynolds'Blog. I have made an archive of it.

Where Did I Put That Process?

A BPEL process is initiated and makes a call to an ERP system to raise a purchase order, generating a purchase order number. Later that purchase order causes another system to raise an invoice and send the invoice to the BPEL process. How does the BPEL engine know which BPEL process should receive this invoice and process it. This is dealt with a thing called correlation.

From e-mails and phone calls that I receive it appears a lot of people struggle with BPEL correlation. It seems that the questions falls into two categories, why would I want it, and how do I do it?

What is Correlation?
Correlation is basicallly the process of matching an inbound message to the BPEL engine with a specific process. Normally this matching is hidden from us. Synchronous calls have no need of correlation because the conversation context is maintained on the stack or across a TCP connection. Consenting BPEL processes will usually correlate messages using WS-Addressing headers to pass around magic tokens that act like the session cookies in a web application.

Why Do I Need Worry About It?
Well most of the time you don't! As I mentioned before, calling another BPEL process or using a synchronous call will mean you don't have to think about it. You do need to worry about it in the following situations amongst others.

• When using an asynchronous service that doesn't support WS-Addressing
• When receiving unsolicited messages from another system
• When communicating via files

In these casess we need to be able to tell BPEL to look at some content of the message in order to select the correct process instance to receive the message.

How Do I Get the Right Process Instance?
BPEL provides a construct called a correlation set to allow for custom correlation. A correlation set is a collection of properties used by the BPEL engine to identify the correct process to receive a message. Each property in the correlation set may be mapped to an element in one or more message types through property aliases as shown below.




Things to Remember About Correlation
I see some common misunderstandings about custom correlation. So lets knock them off now.

• Only the process receiving the messsage needs to worry about correlation. As long as the sending service includes sufficient information in the message to be able to correlate it with previous activities there is no need for the sender to even be aware that correlation is occuring.
• Correlation properties must be unique for the duration of the life of the BPEL process that set them. Make sure that you can't have two processes working with the same correlation tokens, for example using social security numbers to correlate an expense claims process would be a bad idea if an individual could kick off two seperate instances of the process.
• Properties can be made up values or actual business identifiers such as purchase orders or numbers. They don't have to be strings, they can be any reasonable XML type.

A Quick Guide to Custom Correlation
Enough of the theory, how does it work in practice? Consider a process A that call a process B that calls a process C that calls a process A. This is one of the scenarios (113) in the BPEL samples distributed with Oracle BPEL PM.
So we have a cycle A->B->C->A. Three different asynch calls.

Note only process A needs correlation because only A receives more than one call. On the invoke from A to B we add a correlation in the correlation tab for the invoke using BPEL Designer. In here we will create the correlation set and create a property to correlate the exchange. We set this to initiate the correlation, meaning that it will associate this process with the given value.

On the receive from C to A we add the same correlation set with its property as we did for the invoke from A to B. However this time we mark the receive as not to initiate the correlation, meaning that the BPEL PM will use this to select the right process instance.

We now go to the BPEL structure diagram in the BEL Designer and add the property alias. We create two property aliases maping to appropriate elements in each message that will have the same value in message from A to B, as in the message from C to A. Note that the elements can be different names and in different structures in the two messages, but they must contain the same value if correlation is to work.

At this point BPEL designer has done almost everything. We need to manually edit the bpel.xml file and add the following XMl fragment to each partner link that will participate in the correlation.

Note that "correlationSet" is a fixed value. I have uploaded a sample of this process. Note deploying it may be tricky due to circular dependencies. How to deploy it is left as an exercise to the reader, but if the worst comes to the worst deploy an empty version of the process B, then deploy process A, then process C and then the real process B.

Useful References
Here are some useful references on correlation.

• Oracle BPEL PM Tutorial 13 : Using BPEL correlation sets – File Adapter mid-process receive
• Oracle BPEL PM Technical Note #006: Correlation of Adapter messages within BPEL Process
  
• IBMTutorial on BPEL4WS

Oracle BPEL and ESB

Hi,

The goal of the blog is to spread my personal view and knowledge about the Oracle product named Oracle BPEL Process Manager.

As I can see the many customers are moving to a Service Oriented Architecture (SOA), the BPEL product of Oracle is often a good fit. The upcoming release with Enterprise Service Bus (ESB), the product will be named Oracle SOA Suite and will cover the complete SOA functionality that customers are expecting.
Currently Oracle does not have a real ESB product. Oracle Interconnect can act as an ESB, but is not integrated with Oracle BPEL PM.

Regards,

Marc