Sunday, February 22, 2009

Load XSL at runtime on the fly

While working for a project objective, we had lots of stylesheet (XSLT) files in the BPEL processes, which underwent frequent modifications. The XSL files were created and stored under a common folder inside the BPEL process, which required deployment of the BPEL process everytime we made changes to the stylesheets.

This seemed very bad and time consuming, as we were compiling and deploying the entire BPEL process even for the smallest change in the stylesheet. Then I found a solution where the BPEL process would be made to pick up / load the stylesheet during runtime which will be stored at some physical location under the $SOA_Home accessible via a http URL.

By dynamically constructing the http URL in the BPEL process, the BPEL process was able to load the stylesheets dynamically thereby eliminating the tight coupling between the stylesheet configuration & BPEL process.

# Create a folder called "xsl" (user-defined) under the following location;
$SOA_Home\bpel\system\xmllib

# Place all your XSLT files under the xsl folder

# Construct the dynamic HTTP URL as shown below for this folder location in your BPEL process

1. Create a copy operation under the Assign activity which will construct and store the http URL for the xsl folder, and assign the value to a variable; say xsl_variable
concat(substring-before(ora:getProcessURL(),ora:getDomainId()),'xmllib/xsl/',bpws:getVariableData('stylesheet1'))
2. Pass this variable (In this example xsl_variable) as the first parameter to the ora:processXSLT() function

After the above said modifications are performed, the stylesheets can be modified and copied into the xsl folder which will be loaded & transformed by the BPEL processes on the fly.

Sunday, February 8, 2009

Oracle BPEL HTTP Server Down after applying patch 10.1.3.3

We have encountered few issues while starting the oracle SOA suite after applying SOA patch 10.1.3.3. The HTTP server was still down after the SOA suite restart.

On analyzing the HTTP_Server~1.log file available under $SOA_Home\opmn\logs, the following error was logged.

Syntax error on line 278 of $SOA_Home/apache/apache/conf/httpd.conf:Cannot load $SOA_Home/apache/apache/modules/apachemoduleossl.dll into server: (127) The specified procedure could not be found

This issue might occur if there are few DLL files pertaining to SSL missing or unavailable for the HTTP server start. If you are not using the SSL advantage, then the quick fix is to comment out the following sections of httpd.conf file (Key in # infront of the line to comment).

<ifdefine>
LoadModule ossl_module modules/ApacheModuleOSSL.DLL
</ifdefine>


# Include the SSL definitions and Virtual Host container

include "D:\product\10.1.3.1\OracleAS_1\Apache\Apache\conf\ssl.conf"

Now, restart the Oracle SOA instance & the Http Server should run.

Tuesday, February 3, 2009

Oracle BPEL Remote Deployment using Ant

In the last post, we have seen how to compile & deploy the Oracle BPEL & ESB processes in the local OAS (Oracle Application Server on SOA Suite 10.1.3.3) using automated Ant build scripts. In this blog, I will try to explain the remote server deployment of Oracle BPEL processes.

This essentially means that we will be able to run the Ant build script on local machine & deploy the compiled code on to remotely located servers on the network. To explain this with a practical scenario, we can have a build server which has the completed build setup with 2 build scripts - One which will run at regular time intervals (Daily) to check for the integrity of builds & another which can be triggered at desired time to deploy on to test environments.

The following segment of code must be added on to the build script which does the remote server deployments.

Step 1:
Download the classes here and place them in the following location;

$Oracle_SOA_Home\bpel\system\classes\com\collaxa\cube\ant\taskdefs

Step 2:
Add the following task definition to your Ant build script.

<taskdef classname="com.collaxa.cube.ant.taskdefs.RemoteDeployOverHttp"
name="deploySuitcase">


Step 3:

Compile all the required BPEL processes, so that the corresponding jar files are generated in the output folders.

Step 4:

Add a target element in the Ant build script as shown below, which takes care of deploying the compiled BPEL processes to the remote Oracle SOA @ the domain specified.

<target name="deploy">
<deploySuitcase host="$host_ip" port="$SOA_port"
domain="default" password="$SOA_pwd">
<fileset dir="${basedir}">
<include name="bpel_Process1_1.0.jar"/>
</fileset>
</deploySuitcase>
</target>

The host_ip, SOA_port, SOA_pwd are parameters that will be extracted from the external properties file during run-time.

The <deploySuitcase> is the custom Ant task which takes care of deploying the jar files of compiles BPEL processes defined within the <fileset> element. You can included any number of BPEL jars that will be deployed to the remote server specified.

Courtesy: Clemen's SOA Blog

Monday, January 12, 2009

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.

Thursday, January 1, 2009

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.

Monday, December 29, 2008

Dealing Transaction time-out(s) in Oracle BPEL & ESB processes

This post would cover the various transaction timeout properties & configurations of Oracle BPEL/ESB projects that can be of great help mitigating timeout issues during runtime arising due to several performance issues.

We had a synchronous BPEL process which would calculate, extract and generate generic XML content for use by other child BPEL processes, which were designated for various operations. The synchronous BPEL process would be called by main BPEL process which will manage the entire workflow. We had no issues in this process until the XML content generated by the synchronous process was fast & within the transaction time-out limits.

For transactions involving complex logic calculations & huge data extractions, the synchronous BPEL process took plenty of time to respond which resulted in transaction time-outs and the BPEL processes never proceeded to completeness.


To overcome this issue, we increased the transaction time-out parameters which can be configured in the Oracle SOA suite. Please note that the following settings are applicable for Oracle SOA suite 10.1.3.3 advanced installation.....
Config 1:
While introducing receive activity in a BPEL process anticipating a response from an Asynchronous BPEL process after an invoke, if the transaction times out; configure the following setting in the BPEL console which will increase the time-out duration.

This is the maximum time the process receiver will wait for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously via a receiver that will wait for a result from the container.
  • Login to BPEL Console
  • Click on Manage BPEL Domain
  • Update the syncMaxWaitTime property to an increased value (Default is 45 sec) depending on the requirement
Config 2:
Modify the transaction-timeout property in the orion-ejb-jar.xml file available under the following location;
$SOA_Home\j2ee\oc4j_soa\application-deployments\orabpel\ejb_ob_engine\orion-ejb-jar.xml

There will be several session beans available in this config file - all of which should be configured with the same value for the transaction-timeout.
Config 3:

Modify the transaction-timeout property in the transaction-manager.xml file available under the following location;
$SOA_Home\j2ee\oc4j_soa\config\transaction-manager.xml

Please note that this timeout value should be greater than the values configured in Config 1 & 2. In essence this value should be larger than syncMaxWaitTime & transaction-timeout configured in orion-ejb-jar.xml file [Config 2].

Config 4:
While using Oracle Enterprise Service Bus (ESB), there can be transcation timeouts while transacting with other BPEL processes or during deployment of ESB projects via Oracle JDeveloper. For the former, Config 3 would suffice & for the latter, configure the xa_timeout parameter in esb_config.ini located in SOA suite at the following location;
$SOA_Home\integration\esb\esb_config.ini

Note that whenever an ESB initiates a transaction, timeout specified in the esb_config.ini will take precedence.
The above specs are gathered from the following resources;http://download.oracle.com/docs/cd/B31018_01/relnotes.1013/relnotes/esb.htm
http://download-west.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/app_trblshoot.htm#sthref3957

Wednesday, December 24, 2008

Storing CLOB data in DB - Oracle BPEL

While working at the clients' place an year ago, being newly exposed to Oracle SOA & BPEL, we had a requirement to store large objects which were purely XML content in database tables. Hence, I created a column in the oracle database of CLOB datatype which can fit data upto 4GB and a DB Adapter in my BPEL process which will execute a query to insert data into the database column with CLOB datatype. So far so good.

This seemed to work fine for quite some time until the data was not more than 32766 bytes, which triggered my mind that there ought to be some issue with the Oracle SOA settings, as I was able to insert very large payloads (Obviously more than 32766 bytes) using the same sql query executed via SQL developer. The Oracle BPEL PM also threw the following exception when the BPEL process tried to invoke the DB adapter for large payloads;

java.sql.SQLException: setString can only process strings of less than 32766 chararacters

Internal Exception: java.sql.SQLException: setString can only process strings of less than 32766 chararacters

Error Code: 17157 when trying to insert record in clob type of size more then 32766 characters

After googling around for solutions, finally found the following solution (couldn't recall the thankful resource) which needs to be configured in the Oracle SOA suite for the CLOB data insertion.

With Oracle SOA Suite 10.1.3.3 advanced installation, I tried the following settings which resolved the issue;
Step 1:
Add/Append the following properties under the following file: $Oracle_Home\j2ee\oc4j_soa\connectors\DbAdapter\META-INF\ra.xml

<config-property>
<config-property-name>usesStreamsForBinding</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>true</config-property-value>
</config-property>

<config-property>
<config-property-name>usesStringBinding</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>true</config-property-value>
</config-property>


Step 2:
Configure the above properties in the connector-factory of the DB Adapter and ensure that "usesStreamsForBinding" and "usesStringBinding" are set to true;
$Oracle_Home\j2ee\oc4j_soa\application-deployments\default\DbAdapter\oc4j-ra.xml


<connector-factory location="eis/DB/DBConnection" name="Database Adapter">
<config-property value="jdbc/DBConnection" name="xADataSourceName">
<config-property value="" name="dataSourceName">
<config-property value="oracle.toplink.platform.database.Oracle9Platform" name="platformClassName">
<config-property value="true" name="usesNativeSequencing">
<config-property value="50" name="sequencePreallocationSize">
<config-property value="false" name="defaultNChar">
<config-property value="true" name="usesBatchWriting">
<config-property value="true" name="usesStreamsForBinding">
<config-property value="true" name="usesStringBinding">
<connection-pooling use="none"></connection-pooling>
<security-config use="none"></security-config>
</connector-factory>


Step 3:
Restart Oracle SOA Suite for all configurations to take effect and the BPEL process should work fine even with very large payloads.

Meet you in my next post with a possible solution for a new SOA challenge.....