How install the BPEL features via Feature Manager

This blog post explains how to install BPEL specific features to WSO2 ESB.

Tested Environment

• WSO2 ESB 4.0.2 (Based on WSO2 Carbon 3.2.2 release)

Introduction

If you consider WSO2 products like WSO2 BPS, WSO2 ESB, WSO2 AS etc. all those products can be considered as a collection of solution specific features included on top of WSO2 Carbon platform. As an example, WSO2 BPS is a collection of features which facilitate BPEL process/instance management, BPEL process runtime management etc. included on top of some other features provided by WSO2 Carbon platform. So theoretically you can convert a WSO2 Carbon distribution to WSO2 BPS by including those BPEL specific features.

How to determine the correct BPEL version compliant with the target server

We can do this easily via the feature manager provided by WSO2 Carbon platform. Here, the tricky part is user have to specify the correct version of BPEL feature to be installed on target server. This is solely depend on the version of the WSO2 Carbon platform in which the target server was released. Let me elaborate this with an example. eg - To install BPEL features to WSO2 ESB 4.0.2, first find the related WSO2 Carbon platform version. This can be determined by the version of $ESB-HOME/repository/components/plugins/org.wso2.carbon.core-x.x.x.jar. So if WSO2 ESB 4.0.2 is the target server, then the version of org.wso2.carbon.core jar would be 3.2.2. So the relevant BPEL feature version is 3.2.2.

Step by step guide to install a feature via feature manager

Once we figure out the right BPEL feature version we can add it via the Feature Manager. Please refer the following documentation on how to install a feature via feature manager. Once all the BPEL 3.2.2 features are installed in WSO2 ESB 4.0.2 and once the server restarted, there’ll be a separate menu item is appeared for BPEL features as follows.

How to invoke a secured webservice through BPEL

Engaging Quality of Service(QoS) for a partner web service endpoint in WSO2 BPS is facilitated by Unified Endpoint(UEP) feature. Not only QoS, but also, protocol specific properties like setting “ReplyTo” header for the outgoing message can be configured via UEPs. To get some more idea on UEPs please refer this post.

This post describes how to invoke a secured web service through a BPEL process using an UEP.

Tested Environment

• WSO2 BPS 2.1.2 (based on WSO2 Carbon 3.2.0) release and WSO2 BPS release based on WSO2 Carbon 4.0.0

A sample of referring the security policy in the Unified-Endpoints can be found via this Unified Endpoint  in this sample BPEL Loan Process. 

This policy can be maintained outside from the BPEL artifact as well.

eg - Referring to a policy maintained in the file system - Use the absolute path for the policy in UEP.

eg - Referring to a policy maintained in the configuration registry - Use the registry specific path for the policy in Unified Endpoint.


Maintaining an policy outside from the BPEL artifact becomes very useful when governing policies which are used by multiple BPEL processes in multiple WSO2 BPS instances.

Unified endpoints for BPEL Processes

WSO2 Carbon platform supports unified-endpoints(UEPs) to configure partner endpoints which are used in the BPEL processes. In more general terms, UEPs facilitate for a generalized way of configuring endpoints taking quality of service in to the picture. So a particular UEP configuration can be used across the carbon platform to configure security in a partner endpoint in BPEL process and to configure WS-Addressing in a WSO2 ESB endpoint.

This post provides a guide on how to properly configure a partner endpoint in a BPEL process.
Tested Environment :

• WSO2 Carbon 4.0.0 based releases 

Please take a look at Async-Server sample which is a sample BPEL process which uses an UEP to configure the target endpoint of a partner service.


If you are interested in other supported constructs by UEPs, please refer this xml schema which provides the current supported functionality like setting “ReplyTo” header.

So where is this UEP configuration actually engaged to a partner endpoint?. This is configured at the deploy.xml which declares the particular partner service as follows. Please refer the same sample mentioned above.


If you look at the mentioned sample above, UEP configuration is located inside with the BPEL artifact.
But on the other hand, an UEP can be maintained outside from the BPEL artifact. So it can be located in the file system or registry. Maintaining an UEP outside from the BPEL artifact becomes very useful when governing endpoints which are used by multiple BPEL processes in multiple WSO2 BPS instances.

eg - If the UEP to be maintained in the file sytem - Use the absolute path for the UEP in deploy.xml


eg - If the UEP to be maintained in the registry - Use the registry specific path for the UEP in deploy.xml


Please refer this UEP on configuring security for a partner service via a UEP. More information on this can be found from this post as well.

Diving into the blue - Sri Lanka

I was diving in a 10-12 meters depth of down the ocean floor where roughly 1km away from Hikkaduwa coast line. My ultimate target was to capture some cool pics of coral reefs and fish. So I stopped for a while and took some and moved on. After a few seconds I got a bad leg cramp and I looked around for my buddy for the help. At that moment I just realized my buddy has already swam out of my visible range. It was also dangerous to swim to surface suddenly due to huge pressure difference. I waited for a while and little by little reached to the surface. I met my buddy there and he helped me to recover back.
That’s my most recent experience and a foolish mistake I made while diving.
Sometimes unexpected could happen anytime. On the same dive some thing that happened to me twice was, the camera in my hand was tangled with the air regulator without knowing and the regulator popped out from the mouth when I swung the hand :).
And here are some uncut clips from the dive.

Anyway there’s a whole new world under the ocean. But it’s something hard to predict from outside and feel it. You have to go underwater and see what’s out there.

Getting things ready

Horizontal Format Data Mining with Extended Bitmaps - Extended version

We (Buddhika De Alwis, Supun Malinga, Kathiravelu Pradeeban and I) published the extended version of our research paper titled “Horizontal Format Data Mining with Extended Bitmaps” at International Journal of Computer Information Systems and Industrial Management Applications.
You can find it from http://www.mirlabs.org/ijcisim/regular_papers_2012/Paper56.pdf .

Initial publication can be found from here and the presentation from here.

Related Posts : Horizontal Format Data Mining with Extended Bitmaps 

2012 has arrived

2012 has arrived. It’s quite late but a belated Happy new year everybody!. My 2012 started with my friends and some Kiribath.

Starting 2012 at WSO2 was also a decent gathering of all folks at WSO2 LK office. It’s more than one year since I joined WSO2 and I always freshen up by learning something new everyday.

Aha, One small good thing on the side about WSO2 is, it’s within walking distance to Lionel Wendt art theatre. No, not kidding. During last three days, I watched three plays by Jayalath Manorathne at Lionel Wendt. It helps me to see things that I don’t see or to remember things that I forgot.

Related post - Happy new year Sri Lanka-2010!

Enabling logging for various components in WSO2 BPS

This blog post explains how to log the messages come into and sent out from WSO2 BPS server.
This feature is extensively used in BPEL development to figure out the problems in the message sequences and in latency analysis during BPEL process invocations.

Tested Environment

     wso2bps-2.1.2

Instructions

1. Add the following entries to the $CARBON-HOME/lib/log4j.properties
       log4j.logger.org.apache.ode.bpel.messagetrace=TRACE
       log4j.logger.org.wso2.carbon.bpel.messagetrace=TRACE
2. Then the preferred log4j appender should be configured such that it has a threshold of TRACE level. If CARBON_LOGFILE is the log4j appender, it should be changed as follows. By default this is set to DEBUG.
       eg - log4j.appender.CARBON_LOGFILE.threshold=TRACE
3. Then re-start the WSO2 BPS server.
4. The log files can be found as $CARBON-HOME/repository/logs/wso2carbon.log 

Note - You can configure this via Management console as well.