Customizing BPEL Process Instance Titles

When there were several BPEL process instances getting created in the BPEL console, it often really becomes hard to identify a instance for tracking/debugging purposes. Since, all the BPEL process instances use a generic naming convention consisting of an unique instance id (sequence generated within Oracle BPEL PM) and the BPEL process name; all instances would hold the same name except for the change in instance id.

In order to give a valid instance name for the BPEL processes, you can make use of the setTitle(String str1); method inside a Java Embedding activity inside the BPEL process, which will ensure that the 'str1' parameter is set as the instance title for all instances created for this BPEL process. You can pass dynamic run-time parameters and customize the BPEL instance titles, so that the BPEL instances can be identified more uniquely in a business sense. This also enables easy & effective instance tracking from the BPEL console.

Pass Variables between Java & BPEL Process

When using Java embedding activity in a BPEL process for processing BPEL variables , it will be required to pass the variables between Java and the BPEL process. In such cases, you can use
the following methods to get/set the variables;

getVariableData(bpelVariable); method will fetch that variable value to be used inside the Java embedding activity

setVariableData(bpelVariable, Value); method sets the Value (processed in the Java embedding activity) to the bpelVariable, which can be used in the BPEL process for further processing.

However, the variable datatype conversions should be properly handled in BPEL process and Java embedding activity.

Lost BPEL Instances? - Use Force Dehydration

There will be many instances when it will be really puzzling to find out whether the BPEL instance was triggered or not, where we often say that the "BPEL instance is lost". Actually, in reality, the BPEL process could have resulted in some kind of exception during the process which gets suppressed completely by the BPEL PM and the instance neither gets persisted or dehydrated in the orabpel schema nor shown up in BPELConsole.

This will be really troublesome, as we will not be able to identify whether the problem lies in the external system driving the BPEL instance or within the BPEL process itself after consumption of data. In such cases, you can use the checkpoint(); Java method inside a Java embedding activity to force the instance to be dehydrated as soon as the instance gets triggered in BPEL. This will ensure that the BPEL instance is shown up in the BPEL console if it is instantiated. You can use the following piece of code in your BPEL process to force dehydration.

<bpelx:exec name="CheckPointOne" language="java" version="1.5">
<![CDATA[checkpoint();]]>
</bpelx:exec>

Now, all your BPEL instances will be available in the BPELConsole for debugging issues that are not actually propagated/thrown to BPELConsole by the OPMN.

However, there are certain drawbacks while using the force dehydration mechanism, as this will cause drop in performance of the BPEL process during run-time due to the additional overhead of persisting the instance whenever this method is called. So please make justified use of this method before using this.

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.

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.

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

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.