Turbocharge PuTTY with 12 Powerful Add-Ons

PuTTY is hands-down the best, free, and lightweight SSH client
for Windows. I have provided list of 12 powerful PuTTY add-ons with
screenshots, that will solve few shortcomings of the original PuTTY.  Play around with these add-ons and choose the one that suites your need.



1. PuTTY Connection Manager
PuTTYCM gives a
nice feature to arrange several PuTTY sessions in tabs .

JSON pass-through in WSO2 ESB

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:

• Download and extract the binary distribution of WSO2 ESB-4.5.1
• 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;

http://<wso2_application_server_hostname>:<wso2_application_server_port>/jaxrs_basic/services/customers/customerservice/customers

We will forward a message to the above URL from WSO2 ESB.

Step 4:

Now we have the backend web service, ready to process messages. Let's create a pass-through proxy service in ESB. Obviously, the endpoint URL will be the one mentioned above.

<proxy xmlns="http://ws.apache.org/ns/synapse" name="jsonproxy" transports="https,http" statistics="disable" trace="disable" startOnLoad="true">
   <target>
      <outSequence>
         <send/>
      </outSequence>
      <endpoint>
         <address uri="http://localhost:9764/jaxrs_basic/services/customers/customerservice/customers"/>
      </endpoint>
   </target>
   <description></description>
</proxy>

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.

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Server: WSO2 Carbon Server
Date: Sat, 12 Jan 2013 13:34:31 GMT
Transfer-Encoding: chunked

{"Customer":{"id":"125","name":"charitha"}}

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.

<property name="messageType" value="application/json" scope="axis2" />

Effective Test Automation and WSO2 System Test Framework

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.

TIP: How to view log statements generated by WSO2 ESB log mediator in System Logs UI?

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.

Step 1
Open CARBON_HOME/repository/conf/axis2/axis2.xml

Step 2
Uncomment the following element.

             <handler class="org.wso2.carbon.utils.logging.handler.TenantDomainSetter" name="TenantDomainSetter">

Now, restart the server. Send a request to ESB and see the logs in "System Logs" UI in management console.

TIP: Error handling in WSO2 ESB APIs when the requested API resource does not match with the given URL template or pattern

When you send a HTTP request to an API in WSO2 ESB, if the requested API resource URL does not comply with the API resource definition, ESB returns HTTP 202 accepted response to the user. Due to  this behavior, the client is unable to distinguish if they have made an error. We can use the following procedure to return a fault to the client in case of non-matching API resource is requested by client.

Step 1:

Suppose, we have an API similar to the following. Note that, the target web service is a JAXRS web application (jaxrs_basic) which is included in WSO2 Application Server by default.

<api xmlns="http://ws.apache.org/ns/synapse" name="jaxrs" context="/jaxrs">
   <resource methods="GET" uri-template="/customers/{id}">
      <inSequence>
         <send>
            <endpoint>
               <address uri="http://localhost:9764/jaxrs_basic/services/customers/customerservice"/>
            </endpoint>
         </send>
      </inSequence>
      <outSequence>
         <send/>
      </outSequence>
   </resource>
</api> 

Step 2:

Send the following HTTP GET request to the above API. (You can use a soapUI web testcase as instructed in one of my previous blog posts).

GET http://localhost:8280/jaxrs/customers-wrong/123

Step 3:

You will get HTTP 202 accepted response because the request URL does not match with the resource url-template defined in the API.

Step 4:

Now, add the following fault handling sequence in ESB. Once the API receives a request which does not match with any of the resource url patterns/templates, this sequence will be invoked. Make sure to name the sequence as _resource_mismatch_handler_

 <sequence xmlns="http://ws.apache.org/ns/synapse" name="_resource_mismatch_handler_">
   <payloadFactory>
      <format>
         <tp:fault xmlns:tp="http://test.com">
            <tp:code>404</tp:code>
            <tp:type>Status report</tp:type>
            <tp:message>Not Found</tp:message>
            <tp:description>The requested resource (/$1) is not available.</tp:description>
         </tp:fault>
      </format>
      <args>
         <arg xmlns:ns="http://org.apache.synapse/xsd" expression="$axis2:REST_URL_POSTFIX"/>
      </args>
   </payloadFactory>
   <property name="RESPONSE" value="true" scope="default"/>
   <property name="NO_ENTITY_BODY" action="remove" scope="axis2"/>
   <property name="HTTP_SC" value="404" scope="axis2"/>
   <header name="To" action="remove"/>
   <send/>
   <drop/>
</sequence>

Step 5:

Send the above HTTP GET request again. This time, you will get a proper error as shown below.

HTTP/1.1 404 Not Found
Content-Type: application/xml; charset=UTF-8
Accept-Encoding: gzip,deflate
Host: 10.100.3.37:8280
Date: Fri, 16 Nov 2012 06:06:51 GMT
Server: Synapse-HttpComponents-NIO
Transfer-Encoding: chunked 

How to enable mail transport for WSO2 data services

We can use mail transport to send and receive messages to and from web services using MIME complaint mail messages. We can configure mail transport for Axis2 services which are deployed in WSO2 Application Server by following the instructions given in the official documentation.
In there, you will notice that, a set of mail transport specific parameters need to be configured in the services.xml of Axis2 service in order to enable mail transport in Axis2 services.
How can we do the same for data services which are deployed in WSO2 Application Server?
This post summarizes the procedure of configuring mail transport for a data service.

Step 1:

Download and install WSO2 Application Server-5.0.0 or a later version. Configure mail transport sender and receiver in axis2.xml configuration file which can be found at CARBON_HOME/repositiry/conf/axis2/axis2.xml (see WSO2 Application Server official documentation on how to configure mail transport sender and receiver in axis2.xml)

After configuring axis2.xml, make sure to restart the server.

Step 2:

Once the server is started, you will see the existing services become faulty with the warnings similar to the following. 

WARN {org.apache.axis2.transport.mail.MailTransportListener} -  Unable to configure the service TestService for the MAILTO transport: Service doesn't have configuration information for transport mailto. This service is being marked as faulty and will not be available over the MAILTO transport.

The reason for this is, though we have configured mail transport globally in axis2.xml configuration file, we have not configured mail transport at individual service level. Thus, if you have Axis2 Services or data services or any other service type, the mail transport will not be enabled for them. You can configure mail transport for specific Axis2 services as instructed in here.

However, data services do not have a services.xml associated with it by default. Thus, we need to follow a different procedure for them.

Step 3:

Locate the *.dbs file in CARBON_HOME/repository/deployment/server/dataservices/ directory. Let's assume the data service is GUEST_T_DataService.dbs. Create a file GUEST_T_DataService_services.xml at the same directory. (Make a note of the name of the file which is in the format; _services.xml)

GUEST_T_DataService_services.xml can be similar to the following. Note the mail related parameters section.

<serviceGroup>
<service name="GUEST_T_DataService">
<Description>This sample demonstrates some of the main functionalities of a dataservice using an RDBMS data source
</Description>
 <!--mail related parameters-->
        <parameter name="transport.mail.Address">synapse.demo.1@gmail.com</parameter>
        <parameter name="transport.mail.Protocol">pop3</parameter>
        <parameter name="transport.PollInterval">5</parameter>
        <parameter name="mail.pop3.host">pop.gmail.com</parameter>
        <parameter name="mail.pop3.port">995</parameter>
        <parameter name="mail.pop3.user">synapse.demo.1</parameter>
        <parameter name="mail.pop3.password">mailpassword</parameter>

        <parameter name="mail.pop3.socketFactory.class">javax.net.ssl.SSLSocketFactory</parameter>
        <parameter name="mail.pop3.socketFactory.fallback">false</parameter>
        <parameter name="mail.pop3.socketFactory.port">995</parameter>
        <parameter name="transport.mail.ContentType">text/xml</parameter>


</service></serviceGroup>

Step 4:

Now, check the dashboard of your data service. You will see mail transport is enabled as shown below. (Restart server if the mail transport is still not enabled for data service).

 

Input/Output Redirection

Unix provides the capability to change where standard input comes from, or where output goes using a concept called Input/Output (I/O) redirection. I/O redirection is accomplished using a redirection operator which allows the user to specify the input or output data be redirected to (or from) a file. Note that redirection always results in the data stream going to or coming from a file.

The