Ramkumar Menon's Blog

Oracle BPEL PM 10.1.3.1 provides utility ant scripts that aid in deploying your BPEL Processes to remote BPEL Servers. This allows you the flexibility of automating bulk deployment of a set of BPEL processes to a target environment. The ant scripts work off a properties file that provide the details of the target system.

The Product install comes with a default ant-orabpel.properties that exists in your $ORACLE_HOME/bpel/utilities directory. This file contains default deployment tokens that are used by the ant script for deployment.

Here is how the default ant-orabpel.properties looks like.

############################################

# Use this file to OVERRIDE default properties when deploying this project

# using "ant" from Developer Prompt or "ant" on project's build.xml in Jdev

# These properties do not get used when deploying from Jdev project -> Deploy

###########################################

# AppServer platform: currently supported values are ias_10g, oc4j_10g

#platform = ias_10g

# Change below if deploying in domain other than "default"

#domain = default

# Change below if deploying with process revision other than 1.0

#rev = 1.0

# Make sure admin.user, admin.password is correct for appserver

#admin.user = oc4jadmin

#admin.password =

# http.hostname and http.port should point to BPEL Server's host and http port

#http.hostname = localhost

#http.port = 9700

# For BPEL in cluster environemnt, j2ee.hostname may not be same as

# http.hostname, where j2ee.hostname will be local hostname,

# while http.hostname will be virtual hostname

# For deployment of applications in oc4j cluster, set cluster = true

# and oc4jinstancename to opmn cluster group it belongs to such as default_group

#cluster = false

#j2ee.hostname = localhost

# rmi.port or opmn.requestport is used in jndi.url/deployment-url in

# standalone or midtier installation respectively.

# rmi.port value below is default value as in BPEL standalone-developer install.

# If you rely on this value, make sure it's correct for your installation

# as from command "opmnctl status -l" output in midtier/SOA install.

#rmi.port = 23791

#opmn.requestport = 6003

#oc4jinstancename = home

#asinstancename =

# Set verbose to true if you want to see verbose output from deployment tasks

#verbose = false

# Following properties are used by bpelTest.

bpeltest.callHandler =

bpel.context.properties = ${bpel.home}/samples/tutorials/102.InvokingProcesses/rmi/context.properties

You could override these properties by altering the default build.properties that exist in your Project directory.

The deployment is driven off a build.xml that exists in each BPEL Project. The build file defines ant targets for compilation, task validation, deployment etc.

<!--=============================-->

<!-- default "deploy" target -->

<!--=============================-->

<target name="deploy" depends="pre-build, process-deploy, post-build" />

<target name="process-deploy"

depends="validateTask, compile, deployProcess, deployTaskForm, deployDecisionServices" />

The bpel.xml artifact is a serialized deployment descriptor for each of your BPEL processes. It provides handles to the partners with which your BPEL process interacts with, as well as provides information about deployment specific configurations and preferences for your BPEL Process

In the event that your BPEL process invokes another one, and you wish to refer to the WSDL of the latter directly, as opposed to copying its WSDL locally within your project, the partnerlinkBindings within your bpel.xml would contian hardcoded WSDL URLs that contain the host, port, domain and revision of your BPEL Process

for e.g.

<?xml version = '1.0' encoding = 'UTF-8'?>

<BPELSuitcase>

<BPELProcess id="ClientProcess" src="ClientProcess.bpel">

<partnerLinkBindings>

<partnerLinkBinding name="ServerProcess">

<property name="wsdlLocation">http://localhost:8888/orabpel/default/1.0/ServerProcess?wsdl</property>

<property name="validateXML">true</property>

</partnerLinkBinding>

</BPELProcess>

</BPELSuitcase>

This poses a problem when you wish to deploy the client and server processes described above into different environments, since the wsdlLocation of the serverProcess differs for each target environment. The brute force way to handle this would be to change the deployment descriptor while performing deployment to each target environment. Alternatively, you could have a separate bpel.xml for each environment. This is cumbersome and error-prone.

The preferred option would be to have a single deployment descriptor and a single templatized build script that can be executed for each target environment. The product supports this notion through a <customize> ant task, that allows you to customize deployment descriptor properties like partnerlinkBindings.

Follow the steps mentioned below, in order.

a) Navigate to the $ORACLE_HOME/bpel/utilities directory.

b) Create copies of ant-orabpel.properties namely ant-orabpel_dev.properties, ant-orabpel_test.properties and ant-orabpel_prod.properties. These names are arbitrarily chosen to reflect properties for dev, test and prod environments.

You could specify the names you wish.

c) Specify the host, port, domain and default revision parameters in each of the three [or n] new properties file.

for e.g. the following tokens could be added to the ant-orabpel_dev.properties

# custom tokens

host_name=devserver.yourcompany.com

port_number=8888

domain_name=default

whereas the following tokens could be added to the ant-orabpel_test.properties.

# custom tokens

host_name=testserver.yourcompany.com

port_number=7777

domain_name=loanRequest

Similary, specify the tokens for each environment where you wish to deploy to, in the appropriate ant_orabpel_<env>.properties.

d) Now go to each of your BPEL Projects.

e) Copy and paste the build.xml in your project directory into the bpel subdirectory.

f) Navigate to the bpel subdirectory, and open up the new build.xml and perform the following changes.

i) Navigate to the <compile> target.

The compile target should look like

<target name="compile">

<echo>

--------------------------------------------------------------

| Compiling bpel process ${process.name}, revision ${rev}

--------------------------------------------------------------

</echo>

<bpelc input="${process.dir}/bpel/bpel.xml" out="${process.dir}/output"

rev="${rev}" home="${bpel.home}"/>

</target>

Change it to have your templatized partnerlinkBindings.

<target name="compile">

<echo>

--------------------------------------------------------------

| Compiling bpel process ${process.name}, revision ${rev}

--------------------------------------------------------------

</echo>

<bpelc input="${process.dir}/bpel/bpel.xml" out="${process.dir}/output"

rev="${rev}" home="${bpel.home}">

</bpelc>

</target>

This customize ensures two things at compile-time.

1) Overrides the specific partnerlinkBindings mentioned in the deployment descriptor.

2) Performs token replacements in the partnerlinkBindings based on token values defined in the ant-orabpel.properties. [or specific properties files that are imported into the build.xml]

Note that you could define your own build.properties or ant-orabpel.properties anywhere in your file system. You would just need to import them in yout build.xml. If two properties file define the same token,

the one that is defined first in document order takes precedence.

g) While deploying to the "dev" environment, you might want to refer to the ant-orabpel_dev.properties, whereas while deploying to "test", you might want to refer to ant-orabpel_test.properties. to ensure that you can specify these dynamically from command line, while running the ant task, perform the following step.

Navgiate to the following line in the build.xml.

<!-- Use deployment related default properties -->

Change it to the following.

<!-- Use deployment related default properties -->

<property file="${bpel.home}/utilities/ant-orabpel_${env}.properties"/>

h) Now navigate to the parent directory and open up the build.xml in the current directory.

i) Modify it so that it calls the compile target in the bpel subdirectory, as opposed to the default compile target in the same build.xml.

For this, follow the steps mentioned below.

1) create a new compile target that redirects execution to the target wirthin the build file within the bpel subdirectory.

<target name="compileEnv">

<ant dir="${process.dir}/bpel"/>

</target>

2) Modify the process-deploy target to invoke this new compile target. i.e. change the following snippet

<target name="process-deploy"

depends="validateTask, compile, deployProcess, deployTaskForm, deployDecisionServices" />

so as to point to the new compile target.

<target name="process-deploy"

depends="validateTask, compileEnv, deployProcess, deployTaskForm, deployDecisionServices" />

j) Thats all! Now you need to invoke the deployment for each environment by going to the developer prompt, navigating to the project directory, and typing in the following

D:BPELBPELProcess1> ant -Denv=dev

This will ensure that the ant-orabpel_dev.properties are picked up for token resolution, and appropriate replacements are made from the same.

Follow the same steps for other environments.