Internship at WSO2: wso2 greg

Showing posts with label wso2 greg. Show all posts

Thursday, December 13, 2012

Axis 2 Handler for Custom Greg Email Notifications

What I needed to do.

We needed to use greg to help our support team. And we hosted all patch information in a greg instance. In greg we have subscription options any one who like to get updates on a specific artifact can subscribe to it. You can learn more on this subscription process in this article.

We needed to customize the emails sent via greg and we wanted to remove all unwanted details and give it a nice informative subject. I got to know it could be done with a axis 2 handler.

Process:

I followed this sample found in the wso2 product wiki. And I needed to change the code there. You can go though that sample and try the basics first. And when you do it remember to insert relevant dependencies, like axis. They are not in the pom.xml and sample does not ask you to add them. You will lead to a compiler error of not finding axis bundle. You can overcome this by removing the below exclusion from the pom.xml

               <exclusion>
                    <groupId>org.wso2.carbon</groupId>
                    <artifactId>org.wso2.carbon.context</artifactId>
               </exclusion>

Removing above form the pom will get rid of following error

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project org.wso2.carbon.registry.samples.handler: Compilation failure: Compilation failure:

[ERROR] /home/malinga/work/Servers/wso2greg-4.5.1/samples/handler/src/src/main/java/org/wso2/carbon/registry/samples/notifications/EmailTransformHandler.java:[6,23] package org.apache.axis2 does not exist

After you are done with this you can look at my code. I change the EmailTransformHandler.java to suit my needs. We are subscribed to ChangeLCState event, and we got a mail for all state changes.

Requirements:

We needed to Change the Subject to [QA] Patch <Artifact name>

We needed to Change the Massage Body

We needed to send the massage for some selected state changes only

How I did it:

We needed to Change the Subject to [QA] Patch <Artifact name>

You can get the transport headers like below and you can change the subject to what ever you need it to be, like below.

((Map<String, String>) msgContext.getOptions().getProperty(MessageContext.TRANSPORT_HEADERS)).put(MailConstants.MAIL_HEADER_SUBJECT, subject);

We needed to Change the Massage Body
It is same as how it is explained in the sample in the wso2 product wiki. Here the main problem is you only get the text body and you have to do lot of string manipulation to get what you need out of it. And if the original massage changes everything will go wrong. Below are some samples from my code

String sender = element.getText().substring(findStringInString(element.getText(), "This message"));

when you get the required information out you can create a string with the body you need and set it as the message body

if(element.getText().contains("'Development' to 'ReadyForQA'")){

                   element.setText(msgPromotedFromDev);

                }

We needed to send the massage for some selected state changes only

We can do a check on the message header, body and if it is not not needed massage you can use InvocationResponse.ABORT to stop the mail from sending, you can find the example from my code below.

if(element.getText().contains("'Development' to 'ReadyForQA'")){

                   element.setText(msgPromotedFromDev);

                }else if(element.getText().contains("'ReadyForQA' to 'Testing'")){

                    element.setText(msgPromotedFromQA);

                }else if(element.getText().contains("'Testing' to 'Released'")){

                    element.setText(msgPromotedFromTesting);

                }else{

                    return InvocationResponse.ABORT;

 }

Hope you got some understanding of Notification E-mail Customization and you can find more simple samples in http://docs.wso2.org/wiki/display/Governance451/Notification+E-mail+Customization+Sample

Wednesday, November 28, 2012

GReg Basic Filter Improvement - Continues

If you haven't read the first part of the project following links will help you.

GReg Basic Filter Improvement - Starting
GReg Basic Filter Improvement - Feedbacks

I completed the project for GReg generic artifacts (go to the bottom of the page if you don't know what are generic artifacts). Now I have to do the same thing with inbuilt basic artifacts like Service, WSDL, Policy, Schema. In future all the artifact types will be defined with RXTs and there my current implementation will work for all. Till then I have to do the same changes with other inbuilt types.
So I decided to add the filter by LC and name to all inbuilt artifacts. But for services being the most important one we decided to have the full basic filter as in generic artifacts. following are some screen shots from the current state of the project.

Life cycle Filter (Use of negative filtering 'NOT')

Life cycle Filter

Other 'filter by' criteria will be followed by a text-box

GReg generic artifacts - When you deploy a GReg instance you get some in built artifact types. But if you need to have your own Metadata type, you can define it yourself. WSO2 Governance Registry provides the flexibility to configure and extend its functionalities and capabilities. One of its configurable capabilities is its Metadata model, which can be extended in such a way that anyone can use it to store any custom type of data, such as Services, WSDLs, etc., which is already there. To do this, you only need to add an XML file (registry extension or .rxt file) which includes the new Metadata model artifact as a resource to the registry.
This section contains detailed information on how to create the registry extension file up to content element, how to create a content which describes the data model of the artifact, how to deploy your file in the WSO2 Governance Registry, and how to add a menu item by adding a menu element to the registry extension file. More information: http://docs.wso2.org/wiki/display/Governance411/Configurable+Governance+Artifacts

GReg Basic Filter Improvement - Feedbacks

As I said before projects get change with the feedback that they are getting. So I like to shear some comments I got from the other members

I got the below comment from Senaka (GReg - Team Lead)

Hi Malinga,
Looks good. Now, say I take a random RXT Foo, it has three columns (in addition to Lifecycle Status),
1. Name
2. Version
3. Domain
How will this work? Will it be an exact match for name? or will what you enter only need to match a portion of the name (i.e. starts with). Will the same work for Version/Domain?
Lifecycle piece looks good, but there can be assets without an LC. For those, I think the "Select LC" box needs to also have a "None" in addition to what you have. Also, if no asset has an LC we don't display the LC-status column at all. In such a situation, the Filter-By should also not have it. Is that accounted for already?

So I decided to use the advance filter within the GReg to filter by all other fields other than life-cycle. So how does it work, I don't have to think about. And I haven't taken those 2nd, and 3rd facts in to the account.

SO like above some more feed backs came in and project got changed according to the feedback. I have listed some more comments below

Vijitha: "Can we make the drop down (second form left) "Is" & "Is Not" ?"

Senaka: "So this would now read as "Lifecycle is PatchLifeCycle in Any". May be its better to change Any in the state dropdown to "Any State", which will make it clearer to the user. Or he/she will have to expand the dropdown to understand what we have got there. I'm talking about a first time user."

I am really thankful to each and everyone who gave me feedback and advice. Here I listed some I found in the mail thread. I got some feedback from other people too, when I met them face to face.
So I will blog on what I will build in the future posts.

GReg Basic Filter Improvement - Starting

Introduction:
Currently in GREG we have a basic filter that can be used to filter services using its name. This is used to filter services on the fly without going in to the advance filter. This project will improve its functionality of that basic search to search main few columns that is selected by the rxt (columns which is in the list artifact page, these columns are defined in the rxt). Here our main concern will be searching with life-cycles.

Below sketch will give you a idea on how UI will change after this project.

Search by life-cycle:
When you select life-cycle from the first drop down (to filter by life-cycle) it will change the text-box next to it to a drop down menu listing the available LCs. and when you select a LC it will create another drop-down containing the possible states within the selected LC. Both of these drop-downs will have <any> item that will filter without considering the subject drop-down.

Search by other fields:
Where you select search by any other field it will show a text-box or a drop-down according to the selected column.

This is only the start:

This is only the start, this designs and functionality change with the feedback of the others. I might complete with a one that is not even close to what you see here. Keep in touch to know what happens.

Comment with any ideas you have, your ideas might get reflected in the next GReg release.

Friday, November 2, 2012

End of the quite October to hopeful November

It was a really quite October, when you look in to the blog, nothing is written. Actually it was a busy October, that is why I didn't had time to write articles to the blog. I worked with BAM and hive summarization scripts for BAM. So I am thinking about writing on "hive and summarization scripts for BAM". Next project I worked in was to improve the basic filter functionality of GREG basic filter and add filter by LC(life-cycle) to it.

What you should expect in the up coming month
About Hive
About BAM summarization scripts
About Bandwidth usage data summarization
About Greg Basic Filter improvement
About Greg LC filtering feature.

Looking for lot of articles in this November! Hopefully :)

Tuesday, August 14, 2012

Things that you should remember when test automating(best practices)

Less Hard-coding

We are always tempted to hardcode things. It make our life easy. But this can make maintaining that code a big issue. I had to change some of the places that I did hardcode due to different reasons.

Dates and times

When working with date and times you might forget that, those things are changing. I did this mistake ones in the testing. I was asked to test the service locking functionality. We can lock a service for a specific time. I just hard-corded the dates and times and did the testing. Soon I realized that, if we are going to use them in the future, test going to fail. You might think that is foolish from me, but believe me we miss those little things while cording.

Use of Constants

If you really need to hardcode something do it through a constant, at the bigging of the code. So if it get changed, it is easy for someone else to find and change it

Do not leave thing behind

When you create any objects for testing and if you have done any configuration changes to the product for testing, make sure you undone them before you leave. Those objects and changes can break other tests by other users. You can use @AfterClass for that purpose.

Avoid Test anti-patterns

Just search for the test anti-patterns and you will find lot of them that you should avoid, or at least try to avoid.

Coverage Vs Stable Product

When we are testing, we normally get blinded by the coverage. But always our goal should be to build a stable product. No matter what is the test coverage if our product is failing, all the hard work is for nothing. This is told to me by our team lead Krishantha ayya.

Good Articles

http://schneide.wordpress.com/2012/08/07/testing-antipatterns/

http://jasonrudolph.com/blog/testing-anti-patterns-how-to-fail-with-100-test-coverage/

http://blog.james-carr.org/2006/11/03/tdd-anti-patterns/

Clarity Framework

Based on the training session and the slide-set provided by Dharshana, and Krishantha.

Clarity is a easy and optimized way to do the integration testing. It can automate platform-wide scenarios , execute tests against stratos and private clouds, adopt tooling(Selenium , SoapUI , Jmeter , Ravana, WSO2 Ravana is an opensource benchmark test framework that aims to facilitate performance benchmarks of different servers. ) support to automation , do reporting and keeping historical records.

Architecture

Work similar to TestNG.

from: http://www.ibm.com/developerworks/java/library/j-testng/workflow.gif

This is the component level view of the architecture.

More information:

OT article : http://www.ibm.com/developerworks/java/library/j-testng/workflow.gif

TestNg documenation : http://testng.org/doc/documentation-main.html

SVN Location : https://svn.wso2.org/repos/wso2/carbon/platform/trunk/platform-integration/system-test-framework

Internship at WSO2