Oracle BPEL/ESB Automated Build using Ant

In this post, we will see how to use Apache Ant effectively in compiling & deploying Oracle BPEL/ESB projects. In any SDLC, we come across situations where it becomes very hard to detect the integrity of builds at earlier stages which leads to eleventh hour hiccups.
Ant build scripts comes to the rescue, providing custom tasks for compiling & deploying the Oracle BPEL & ESB projects in the OAS (We will see remote server deployments in subsequent posts).
Think of a script which runs at regular time intervals; say 2300 hrs every day and reports if there are any issues during compilation/deployment time. Wouldn't that be great to see the reports at your sight before getting along with development activities everyday. We made use of an open-source utility called "CruiseControl" for automating the Ant build scripts which we will see how to orchestrate.
Pre-Requisites:

• Oracle SOA suite 10.1.3.3 installed and configured
• Apache Ant 1.7.0
• jaxb 2.0.0
• commons-httpclient-3.0.1.jar

Identification of BPEL & ESB processes:
Before preparing the Ant build scripts, it is very essential to identify the Oracle BPEL & ESB candidates that would be subject to continuous integration. Also, it is important to capture the order of deployments of these processes.
Wrapper Ant build script:
We can write a wrapper Ant build script which will call the "automatically created" Ant build scripts while creation of BPEL processes & we will leverage the Ant task described in the next section to register ESB projects wherever required.
Compiling & Deploying Oracle BPEL processes:
By default, whenever an Oracle BPEL process is created in JDeveloper, an ant build script will be created which takes care of compiling and deploying that particular BPEL. For orchestrating the automated builds, we will take advantage of these build scripts to continuously integrate the BPEL processes.
Following piece of code shows the process of triggering the process-deploy Ant task available within the BPEL_Process1 BPEL project from the wrapper Ant script.
<target name="BPEL_Process1" description="run BPEL_Process1">
<property name="BPEL_Process1.file.path" value="#Location of BPEL_Process1"/>
<xmlproperty file="${BPEL_Process1.file.path}/bpel/bpel.xml"/>
<echo>Building BPEL_Process1...</echo>
<ant antfile="${BPEL_Process1.file.path}/build.xml" target="process-deploy">
<property name="basedir" value="${process.dir}/${BPEL_Process1.file.path}" />
<property name="process.name" value="BPEL_Process1"/>
</ant>
</target>
Registration of ESB Projects:
Ant comes up with a specialized task for registering the Oracle ESB projects into the SOA server.
1. Extract ESBMetadataMigration.jar from $SOA_Home\Integration\esb\deployment\documentation.zip
2. Modify the following properties in the ESBMetadataMigrationTaskdefs.xml

<project name="ESBMetadataMigrationTaskdefs">
<property name="commons.httpclient.home" value="#commons-httpclient jar location"/>
<property name="jaxb.v2.0.2.home" value="#jaxb jar location"/>
<property name="soa.suite.home" value="#Oracle_SOA_Home"/>
<property name="esb.home" value="#ESBMetadataMigration.jar location"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Custom ant task definitions, to enable import. - This section should be treated as immutable upon installation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<dirname property="imported.basedir" file="${ant.file.ESBMetadataMigrationTaskdefs}"/>
<taskdef resource="oracle/tip/esb/client/anttasks/antlib.xml">
<classpath>
<pathelement location="${esb.home}/ESBMetadataMigration.jar"/>
<pathelement location="${commons.httpclient.home}/commons-httpclient-3.0.1.jar"/>
<pathelement location="${soa.suite.home}/lib/xmlparserv2.jar"/>
<pathelement location="${soa.suite.home}/integration/esb/lib/commons-logging.jar"/>
<pathelement location="${soa.suite.home}/integration/esb/lib/commons-codec-1.3.jar"/>
<pathelement location="${soa.suite.home}/integration/esb/lib/oraesb.jar"/>
<pathelement location="${jaxb.v2.0.2.home}/lib/activation.jar"/>
<pathelement location="${jaxb.v2.0.2.home}/lib/jaxb-api.jar"/>
<pathelement location="${jaxb.v2.0.2.home}/lib/jsr173_1.0_api.jar"/>
<pathelement location="${jaxb.v2.0.2.home}/lib/jaxb-impl.jar"/>
</classpath>
</taskdef>
</project>
3. Import the following config files in your ant build script
<import file="${bpel.home}/utilities/ant-orabpel.xml"/>
<import file="${ESBMetaDataLoc}/ESBMetadataMigrationTaskdefs.xml"/>
4. Final step to register the ESB projects;
<target name="ESB_1" description="run ESB_1">
<echo>Registering ESB_1...</echo>
<deployESBProjects esbMetadataServerHostname="${http.hostname}"
esbMetadataServerPort="${http.port}"
userName="${admin.user}"
password="${admin.password}">
<esbProject directory="${ESB_1.file.path}"/>
</deployESBProjects>
</target>
Configuring CruiseControl:
Now that we have written the wrapper Ant build script to orchestrate the Oracle BPEL/ESB deployments, we can make use of the <target> task to call each of the other targets in the necessary sequence using the 'depends' attribute.
This Ant script can now be made available in the CruiseControl tool which will take care of executing this build script at specified time intervals. config.xml is the CruiseControl configuration file available within the CruiseControl installation directory where we can configure various settings like time of build, mail triggers, reports etc...
A little deep dive into the CruiseControl configurations will allow you to configure css settings, mail templates etc...
Please post your comments if you need clarifications/help which I will try to resolve ASAP.

Oracle BPEL console throws 'No domains accessible to the user logged in.'

A common issue that is faced in Oracle BPEL development phase by a developer is "No domains accessible to the user logged in." This might be due to several reasons which I will try to elaborate in this blog based on my past experience in resolving this issue.

Check 1:
First checkpoint where we can identify the detail of error description is checking the following log files;
Domain Log: $SOA_Home\bpel\domains\default\logs\domain.log ('default' is the default domain name)
- This log file will be created everytime the SOA service is started and will log any domain level startup issues
OPMN Log: $SOA_Home\opmn\logs\OC4J~oc4j_soa~default_group~1.log
- This log file will log all the BPEL process specific logs (creation/termination)
System Log: $SOA_Home\bpel\system\logs\orabpel.log
- System level logging is provided for infrastructure, AXIS, and WSIF issues

All these log files should give a clear picture about the error which might be causing this issue, based on which you can take necessary actions.

Check 2:
Check whether the database on top of which Oracle SOA suite was installed is up & running. If not, ensure the RDBMS listener is running & restart SOA service.

Check 3:
The Oracle SOA suite will be installed on top of a database (Oracle Lite/external Oracle DB), where three schemas would have been created during installation namely Orabpel, Oraesb, Orawsm. These schemas might have got corrupted (or) their passwords might have got changed which throws "No domains accessible to the user logged in." error in Oracle BPEL console. Ensure all 3 schemas are present in the database and their passwords are intact as specified in the datasources.xml/during installation and restart SOA service after corrections.

Check 4:
If any class files have been added in the SOA suite, ensure they are properly compiled and deployed @ $SOA_Home\bpel\system\classes.

Check 5:
If you have added any custom xpath functions for use in the BPEL process, you might have added entries in the $SOA_Home/bpel/system/config/xpath-functions.xml. Ensure that this file is well formed.

Check 6:
If you have deployed any BPEL process recently after which the Oracle BPEL console throws this error, there might be high chance for issues in the deployed BPEL process.
All deployed BPEL processes will be picked up from the following location. Take backup of the existing processes, delete all entries and then restart SOA service.
$SOA_Home\bpel\domains\default\tmp ('default' is the default domain name)

One or more of the above described checks should resolve this issue.