Deploying BPEL Process to multiple environments using Ant

Ramkumar Menon
Director, Product Strategy

Deploying BPEL Processes to multiple environments


Oracle BPEL PM 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.

<!---- START ant-orabpel.properties ->


# 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

<!-- END ant-orabpel.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.

<project name="bpel.deploy" default="deploy" basedir=".">


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


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

<target name="process-deploy"

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


Customizing PartnerlinkBindings for each Target Environment

The problem

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'?>


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


<partnerLinkBinding name="ServerProcess">

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

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




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 solution

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.

The approach

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




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

# custom tokens




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">



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



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

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


Change it to have your templatized partnerlinkBindings.

<target name="compile">



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



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

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


<partnerLinkBinding name="ServerProcess">

<property name="wsdlLocation">






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 -->

<property file="${bpel.home}/utilities/ant-orabpel.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"/>


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.


Join the discussion

Comments ( 21 )
  • Ravi Kumar Monday, July 30, 2007
    Hi Ram,
    Thanks a lot and ti worked out for me with the steps given above.
  • Ravi Kumar Monday, July 30, 2007
    nice blog....
  • Anil Tuesday, July 31, 2007
    Thanks for shring the information.
    Any idea how to manage the wsdl url for the partners links that are defined in the seperate WSDL files? I have a wsdl generated for the non-bpel service partner link and want to override this in BPELC. The compiler looks for the parnerlinktype defined in this WSDL and fails as it has been overridden.
  • Ben Soedjono Tuesday, August 7, 2007
    What happens to the outer compile task? Is it ever invoked? Can it be removed?
  • Ben Soedjono Tuesday, August 7, 2007
  • Ramkumar Menon Tuesday, August 7, 2007
    You could keep the top level compile or remote it. But it would not be used in this case.
  • Sonya Wednesday, March 26, 2008
    Can this be made to work independent of a JDeveloper or SOA Suite installation?
  • Ramkumar Menon Thursday, March 27, 2008
    Yes, you do not require the installation per-se, but you would certainly require the libraries for the tasks - orabpel-ant.jar and orabpel.jar are required for the tasks to function.
  • harry Tuesday, May 27, 2008
    Hi Ram,
    I did try to set up the kind of environment as detailed by you,
    But for some reason, the
    ant-orabpel_dev.properties file is not being picked up, instead ant-orabpel.properties is being read by ant script. I did everything but couldn't trace the problem.
    Somehow, below line in my build.xml is not being read it seems (i hardcoded ${env} with 'dev' to check)
    <property file="${bpel.home}/utilities/ant-orabpel_dev.properties"/>
    where <property name="bpel.home" value="${env.ORACLE_HOME}/bpel"/>
    Any guesses / pointers will help me a lot !!
  • Ramkumar Menon Tuesday, May 27, 2008
    Please ensure that you dont have a build.properties in the directory containing your build.xml. That could also cause an issue. Either remove it, or comment out the uncommented lines in the build.properties file
  • UserR Thursday, July 31, 2008
    i too have the same prob, its getting deployed to the default host
    the respective _dev, _test and _prod are not getting picked
    removed the build.prop file
    tried using the follwing commands however no change
    ant -Denv=test
    ant -propertyfile ant-orabpel_test.properties
    do we need to capture the input somewhere ?? (i.e env variable)
  • UserR Sunday, August 3, 2008
    i too have the same prob, its getting deployed to the default host
    the respective _dev, _test and _prod are not getting picked
    removed the build.prop file
    tried using the follwing commands however no change
    ant -Denv=test
    ant -propertyfile ant-orabpel_test.properties
    do we need to capture the input somewhere ?? (i.e env variable)
  • Saravana Sunday, December 7, 2008
    Hi Ram,
    Since we are using BPEL Version, how can we deploy the BPEL Process using an ANT script?
  • Andy Tuesday, June 23, 2009
    Thank you for the information. It is very helpful.
    We also use schemas where schemaLocation is an absolute URL and the schema is not imported into the project. What would be the approach to replace the hostname and port for schemaLocation when migrating from Dev to Int.
  • Lara Fernandes Monday, October 12, 2009
    Do you have any idea why it returns the following error?
    [attachplan] attachPlan: Started for jar file = C:\jdevstudio10134\jdev\mywork\TESTES\BPELProcess/ou
    tput/bpel_BPELProcess_1.0.jar using deploy plan = ${planfile}
    [attachplan] Load deployment plan file ${planfile}
    [attachplan] java.io.IOException: Cannot read deployment plan file ${planfile}
    [attachplan] at com.collaxa.cube.lang.compiler.bpel.deploy.DeployManager.loadModel(DeployManager.
    [attachplan] at com.collaxa.cube.lang.compiler.bpel.deploy.DeployManager.attachPlan(DeployManager
    [attachplan] at com.collaxa.cube.lang.compiler.bpel.deploy.task.attachPlan.execute(attachPlan.jav
    [attachplan] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
    [attachplan] at org.apache.tools.ant.Task.perform(Task.java:364)
    [attachplan] at org.apache.tools.ant.Target.execute(Target.java:341)
    [attachplan] at org.apache.tools.ant.Target.performTasks(Target.java:369)
    [attachplan] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)
    [attachplan] at org.apache.tools.ant.Project.executeTarget(Project.java:1185)
    [attachplan] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:4
    [attachplan] at org.apache.tools.ant.Project.executeTargets(Project.java:1068)
    [attachplan] at org.apache.tools.ant.Main.runBuild(Main.java:668)
    [attachplan] at org.apache.tools.ant.Main.startAnt(Main.java:187)
    [attachplan] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246)
    [attachplan] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67)
    C:\jdevstudio10134\jdev\mywork\TESTES\BPELProcess\build.xml:94: java.io.IOException: Cannot read dep
    loyment plan file ${planfile}
    I did everything like you said and the planfile.xml is in $processdir
    Thank you!
  • Live Webcam Girls Monday, October 25, 2010
    whenever I'm bored, come and read the topics on this site
  • Air Jordan 13 Tuesday, April 26, 2011
    hey, this power be bit offtopic, but i am hosting my locality on hostgator and they wishes suspend my hosting in 4days, so i would like to beseech you which hosting do you purpose or recommend?
  • Authentic Coach Handbags Wednesday, April 27, 2011
    Sorry for the huge review, but I'm really loving the new Zune, and hope this, as well as the excellent reviews some other people have written, will help you decide if it's the right choice for you.
  • prestiti inpdap Wednesday, April 27, 2011
    I have to show some thanks to you for bailing me out of this incident. Just after browsing through the the web and getting methods which were not pleasant, I assumed my entire life was gone. Living without the answers to the difficulties you have fixed by way of this post is a critical case, as well as those which might have in a wrong way damaged my career if I had not encountered your web site. Your good natural talent and kindness in controlling all the things was invaluable. I'm not sure what I would've done if I hadn't discovered such a solution like this. I can also at this moment relish my future. Thanks so much for this reliable and effective guide. I will not hesitate to propose your web page to anyone who desires counselling about this area.
  • dog boutique Wednesday, April 27, 2011
    The theme in question is certain to be a problem for quite a few. Greatful I found certain sensible information on exactly the same.
  • Sherwood Gural Wednesday, April 27, 2011
    I got what you intend, thankyou for posting .Woh I am thankful to find this website through google.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.