Deploying BPEL Process to multiple environments using Ant

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 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 looks like.

<!---- START ->


# 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.home}/samples/tutorials/102.InvokingProcesses/rmi/

<!-- END -->

You could override these properties by altering the default 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 namely, and 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

# custom tokens



whereas the following tokens could be added to the

# 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 ${}, 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 ${}, 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 [or specific properties files that are imported into the build.xml]

Note that you could define your own or 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, whereas while deploying to "test", you might want to refer to 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/"/>

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 are picked up for token resolution, and appropriate replacements are made from the same.

Follow the same steps for other environments.



Hi Ram, Thanks a lot and ti worked out for me with the steps given above. Regards, Ravi

Posted by Ravi Kumar on July 30, 2007 at 07:13 AM PDT #

nice blog....

Posted by Ravi Kumar on July 30, 2007 at 07:22 AM PDT #

Ram, 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. Thanks, Anil

Posted by Anil on July 31, 2007 at 07:44 AM PDT #

What happens to the outer compile task? Is it ever invoked? Can it be removed?

Posted by Ben Soedjono on August 07, 2007 at 03:00 AM PDT #

Thanks, Ben

Posted by Ben Soedjono on August 07, 2007 at 03:01 AM PDT #

You could keep the top level compile or remote it. But it would not be used in this case.

Posted by Ramkumar Menon on August 07, 2007 at 06:11 AM PDT #

Can this be made to work independent of a JDeveloper or SOA Suite installation?

Posted by Sonya on March 26, 2008 at 07:20 AM PDT #

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.

Posted by Ramkumar Menon on March 27, 2008 at 08:25 AM PDT #

Hi Ram, I did try to set up the kind of environment as detailed by you, But for some reason, the file is not being picked up, instead 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/"/> where <property name="bpel.home" value="${env.ORACLE_HOME}/bpel"/> Any guesses / pointers will help me a lot !! -Harry

Posted by harry on May 27, 2008 at 02:26 AM PDT #

Harry, Please ensure that you dont have a in the directory containing your build.xml. That could also cause an issue. Either remove it, or comment out the uncommented lines in the file

Posted by Ramkumar Menon on May 27, 2008 at 04:46 AM PDT #

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 and ant -propertyfile do we need to capture the input somewhere ?? (i.e env variable)

Posted by UserR on July 30, 2008 at 10:11 PM PDT #

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 and ant -propertyfile do we need to capture the input somewhere ?? (i.e env variable)

Posted by UserR on August 03, 2008 at 02:32 PM PDT #

Hi Ram, Since we are using BPEL Version, how can we deploy the BPEL Process using an ANT script? Thanks, Saravana

Posted by Saravana on December 07, 2008 at 02:41 PM PST #

Ram, 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. Thanks, Andy

Posted by Andy on June 23, 2009 at 12:07 AM PDT #

Do you have any idea why it returns the following error? attach_plan: [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] Cannot read deployment plan file ${planfile} [attachplan] at com.collaxa.cube.lang.compiler.bpel.deploy.DeployManager.loadModel(DeployManager. java:821) [attachplan] at com.collaxa.cube.lang.compiler.bpel.deploy.DeployManager.attachPlan(DeployManager .java:149) [attachplan] at com.collaxa.cube.lang.compiler.bpel.deploy.task.attachPlan.execute(attachPlan.jav a:22) [attachplan] at [attachplan] at [attachplan] at [attachplan] at [attachplan] at [attachplan] at [attachplan] at 0) [attachplan] at [attachplan] at [attachplan] at [attachplan] at [attachplan] at BUILD FAILED C:\jdevstudio10134\jdev\mywork\TESTES\BPELProcess\build.xml:94: Cannot read dep loyment plan file ${planfile} I did everything like you said and the planfile.xml is in $processdir Thank you!

Posted by Lara Fernandes on October 12, 2009 at 12:50 AM PDT #

whenever I'm bored, come and read the topics on this site

Posted by Live Webcam Girls on October 24, 2010 at 08:27 PM PDT #

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?

Posted by Air Jordan 13 on April 26, 2011 at 11:57 AM PDT #

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.

Posted by Authentic Coach Handbags on April 26, 2011 at 07:24 PM PDT #

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.

Posted by prestiti inpdap on April 27, 2011 at 07:48 AM PDT #

The theme in question is certain to be a problem for quite a few. Greatful I found certain sensible information on exactly the same.

Posted by dog boutique on April 27, 2011 at 09:54 AM PDT #

I got what you intend, thankyou for posting .Woh I am thankful to find this website through google.

Posted by Sherwood Gural on April 27, 2011 at 03:37 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

Principal Product Manager


« July 2016