Popular Posts

Friday, January 25, 2013

By default, WSO2 ESB establishes HTTP Keep-Alive connection with the back-end web service. However, in some cases, we want to close connections just after using them specially when back-end server does not properly support Keep-Alive connections .
At individual proxy service or sequence level, you can add NO_KEEPALIVE property to disable Keep-Alive connection between ESB and backend web services.

<property name="NO_KEEPALIVE" value="true"
scope="axis2"/>

However, if you want to disable Keep-Alive connections globally for all message mediations, the above property will not be the solution.

In such cases, you can add the following parameter to ESB_HOME/repository/conf/nhttp.properties file.

Saturday, January 12, 2013

JSON is a lightweight data exchange format used in many web applications. WSO2 ESB supports sending and receiving JSON messages out-of-the-box. Exposing a SOAP web service over JSON is explained under sample 440 in WSO2 ESB official documentation. This post is to summarize steps of invoking a pass-through proxy service which accepts JSON request, forwards it to a RESTful service and reply back with JSON response (JSON-in, JSON-out).

Pre-requisite:

I will use WSO2 Application Server-5.0.1 to deploy RESTful backend web service. You can use any server as the backend. However, in order to follow the steps mentioned in this post, you should use WSO2 Application server.

Step 1:

First, we need to setup the backend web service. We will deploy a JAX-RS based restful service which consumes and produces JSON messages. You can download this RESTful web service(jaxrs_basic.war) from here.

Step 2:

Start WSO2 Application Server, log in to management console and navigate to Manage --> Applications --> List.
You will notice the web applications which are deployed by default in WSO2 Application Server. Since we already have a JAX-RS web app with the name jaxrs_basic, delete the default jaxrs_basic web application.

Now, we can deploy our jaxrs_basic web application (Note that, jaxrs_basic is a modified version of default sample jax-rs web application which has been customized to consume and produce JSON messages).

Go to Manage --> Applications -->Add --> JAX-WS/JAX-RS.Upload JAX-WS/JAX-RS Applications page will be shown. Browse the downloaded jaxrs_basic.war and click on upload. New JAX-RS web service will be deployed in WSO2 Application Server.

Step 3:

The auto-generated WADL of the RESTful web service can be obtained by accessing http://<wso2_application_server_hostname>:<wso2_application_server_port>/jaxrs_basic/services/customers?_wadl
From there, you will identify the POST URL of 'customer' resource;

Either using Pass Through Proxy template in WSO2 ESB management console or using file system, deploy the above proxy service.

Step 5:

Let's send a JSON request to our proxy service. I will use soapUI as usual since it is the best tool out there to invoke web services.

Open soapUI project and add a HTTP request test step to any existing test suite. Change the default method as POST. Enter the proxy service endpoint URL (http://<esb_host_name>:8280/services/jsonproxy) as the Request URL.
Set the media type as application/json and add the following JSON request to POST body text area.

{
"Customer": { "name": "charitha" }
}

Finally, your soapUI request editor will look like the following.

Submit the request. You will get a JSON response back as shown below. WSO2 ESB will seamlessly forward JSON request to RESTful web service and forward the JSON response to soapUI.

NOTE:
In the previous versions of ESB (4.0.3 etc), you should add JSON message builders and formatters to ESB_HOME/repository/conf/axis2.xml in order to enable JSON message processing capabilities in ESB. (See http://docs.wso2.org/wiki/display/ESB403/ESB+and+JSON)
However, these builder and formatters are enabled by default in WSO2 ESB version 4.5.1 and later. In addition to that, you may need to set the following property in IN and OUT paths of proxy services and sequences in previous ESB versions.

Saturday, January 5, 2013

The automated tests are an absolute necessity in agile software development. However, the true benefits of test automation can only be achieved only through a systematic process which should consist of;

Focused automation strategy

Dedicated teams to maintain and manage test automation infrastructure

Firm commitment by everyone in engineering NOT specific to a separate testing team

For the past few years, we tried to build various types of automation test frameworks as part of WSO2 Carbon middleware platform. Our first attempt was to build a Selenium based test framework back in 2009. We were able to use that for four release cycles in that year. Later on, the drastic architectural and UI changes made the framework unmanageable hence we could not continue use it.

WSO2 System Test Framework (A.K.A WSO2 Clarity) came in to picture during 2011. The new test framework development was handled by a separate test automation team headed by Krishantha. The team overcame many challenges and worked like crazy to build a test framework which would serve not only for one or two release cycles but as a long-lasting test automation solution.

As I mentioned in many of my previous blog posts, it takes time to achieve the real advantages of test automation. The one most important thing is, everyone needs to be patient. You cannot achieve greater test coverage in overnight. WSO2 Clarity test framework is primarily driven through admin web service APIs. There is a little chance to break tests in between releases when comparing to traditional UI oriented automated tests.
The future releases of WSO2 middleware products and cloud services will evaluate the success or failure of the new WSO2 Clarity test framework. But personally, I'm experiencing the true value given by the new framework in day-to-day work which are carried out at WSO2.
WSO2 Clarity framework is an integral part of WSO2 continuous integration system (CI). The tests are automatically executed as part of the build process. However, we usually have many requirements to execute tests externally instead of gluing into build system. For example, we patch the products, we do configuration changes such as change the underlying OS, JDK or DBMS etc.. In such cases, a test framework which is tightly coupled with build system does not help much. Because of that, we wanted to have a mechanism to launch tests externally from the maven build. On the other hand, we wanted to have a simple mechanism to run tests without building massive Carbon code base.
Thanks to Krishantha and test automation team, binary deliverable of Clarity test framework has been provided as a solution for this long outstanding requirement. A preview version of it can be downloaded from https://svn.wso2.org/repos/wso2/people/krishantha/wso2clarity-1.0.5.zip

This will surely help anyone who uses WSO2 products/services not specific to internal testers and/or developers. How?
Suppose, you download the latest version of WSO2 ESB and want to customize default settings (e.g:- you simply want to deploy the product in IBM JDK and change the default H2 registry database to DB2). Now, you want to make sure there are no adverse effects due to those changes. You can download the Clarity binary and launch all ESB integration/system tests. The test runner is completely ANT based and you just need to have Apache ant. Update the clarity configuration file by modifying the host, IP etc (as mentioned in INSTALL.txt inside Clarity binary distribution) and run the tests you need.
Note that, we still have a preview version of Clarity binary. This will eventually be part of product downloads.

Friday, January 4, 2013

When you use log mediator inside sequences and proxy services in WSO2 ESB , the logs are shown by default in wso2carbon.file which can be found in CARBON_HOME/repository/logs directory. The same logs are viewable from "System Logs" page in ESB management console.
However, from ESB-4.5.X releases, you should do the following simple change in order to see these logs in "System Logs" UI in management console.

Web Services Testing with soapUI

About Charitha

Charitha Kankanamge possesses over 14 years of experience in various technological domains including software testing/QA and middleware technical support. Currently, he works as a Software Quality Assurance Manager at Amazon. Previously, he worked for an open source software company, WSO2 as Senior Manager, Technical Support. He is also a committer of the Apache Software Foundation. Charitha's strengths and key experiences include functional testing, SOA testing, test planning and agile/exploratory test mechanisms.