Social Icons

twitterfacebookgoogle pluslinkedinrss feed Online Resume

Featured Posts

Sunday, February 19, 2017

How to clean Registry log (REG_LOG) table

If you are using WSO2 Governance Registry or API Manager product, you might be already aware that all the registry related actions are being logged. This REG_LOG table being read for Solr indexing(store and publisher searching). Based on the REG_LOG table entries we are indexing artifact metadata. However, with the time this table size might grow. So as a maintain step you can clean up obsolete records from that table.

So you can use below query to delete obsolete records from REG_LOG table.

DELETE n1 FROM REG_LOG n1, REG_LOG n2 WHERE n1.REG_LOG_ID < n2.REG_LOG_ID AND n1.REG_PATH = n2.REG_PATH AND n1.REG_TENANT_ID = n2.REG_TENANT_ID;

DELETE FROM REG_LOG WHERE REG_ACTION = 7;

Saturday, February 04, 2017

WSO2 Governance Registry Lifecycle transition inputs

WSO2 Governance Registry (WSO2 G-Reg) is a fully open source product for governing SOA deployments, which provides many extension points to ensure your business policies. With G-Reg 5.0.0 release, we have introduced revolutionary UIs for enterprise asset management and discovery. 

The Lifecycle of an asset is one of the critical requirements of enterprise asset management and Lifecycle management is focused on various state changes in a given artifact through different phases. If you want to read more about this, please go through my article on "Governance Framework Extension Points."

So here I am going to talk about, one of the feature enhancements which we added for G-Reg 5.3.0. With G-Reg 5.3.0, we have introduced lifecycle transition input for G-Reg publisher. With lifecycle transition inputs, you will be able to parse custom inputs from a user who is doing lifecycle operation. 

As an example, you have integrated wso2 governance registry with API Management product using lifecycle executor. So when lifecycle transition happens  G-Reg executor will create an API in an external API management product. So instead of defining APIM username password in the lifecycle configuration, using lifecycle transition inputs, you can popup an UI to provide credentials. These inputs can be directly accessed via lifecycle executor class. 


Use of Lifecycle Inputs:

<data name="transitionInput">
        <inputs forEvent="Promote">
              <input name="url" label="URL" tooltip="URL of APIM server"/>
              <input name="userName" label="User Name" tooltip="User Name"/>
             <input name="availability" label="Availability" tooltip="Availability Type"/>
        </inputs>                           
 </data>

Output:


Friday, September 09, 2016

Java - String intern() Method

String Intern method returns an individual representation for the given String object. When the intern() method get invoked on a String object, it will look up the other interned strings, and if a String object exists in the memory with the same content, it will return the existing reference. Otherwise, it will return a new reference.

Example usage of String intern:

Think about a web application with a caching layer. If cache got missed, it would go to the Database. When the application is running with the high level of concurrency, we should not send all the request to the database. Such a situation we can check whether, multiple calls coming to the same reference by checking String intern.

Code: 

String name1 = "Value";
String name2 = "Value";
String name3 = new String("Value");
String name4 = new String("Value").intern();

if ( name1 == name2 ){
    System.out.println("name1 and name2 are same");
}
if ( name1 == name3 ){
    System.out.println("name1 and name3 are same" );
}
if ( name1 == name4 ){
    System.out.println("name1 and name4 are same" );
}
if ( name3 == name4 ){
    System.out.println("name1 and name4 are same" );
}

output:

name1 and name2 are same
name1 and name4 are same



You can see that name1, name2 and name4, objects have the same reference and name3 reference is different.

Wednesday, August 24, 2016

Service Discovery with WSO2 Governance Registry


This blog post explains about the service discovery capability of WSO2 Governance Registry. If you have heard about UDDI and WS-Discovery, we used those technologies to discover Services during 2009-2013 time.

What is UDDI:


UDDI stands for Universal Description, Discovery, and Integration. It is seen with SOAP and WSDL as one of the three foundation standards of web services. It uses Web Service Definition Language(WSDL) to describe the services.

What is WS-Discovery:


WS-Discovery is a standard protocol for dynamically discovering service endpoints. Using WS-Discovery, service providers multicast and advertise their endpoints with others.

Since most of the modern services are REST based, above two approaches are considered as dead nowadays. Both UDDI and WS-Discovery target for SOAP based services and they are very bulky. In addition to that, industry is moving from Service Registry concept to Asset Store(Governance Center), and people tend to use REST API and Discovery clients.

How Discovery Client works


So, here I am going to explain how to write discovery client in WSO2 Governance Registry(WSO2 G-Reg) to discover services which are deployed in the WSO2 Enterprise Service Bus(WSO2 ESB). This service discovery client will connect to ESB server and find the services which are deployed there and catalog those into the G-Reg server. In addition to service metadata(endpoint, name, namespace, etc.), discovery client will import the WSDLs and XSDs as well.

Configure Service Discovery Client:


Sample service discovery client implementation can be found from the below GitHub repo(Discovery Client).

1). Download WSO2 Governance Registry and WSO2 Enterprise Service Bus product and unzip it.

2). By default, both servers are running on 9443 port, so you have to change one of the server ports. Here I am changing port offset of the ESB server.

Open the carbon.xml file located in <ESB_HOME>/repository/conf/carbon.xml and find the “Offset” element and change its value as follows: <Offset>1</Offset>

3). Copy <ESB_HOME>/repository/components/plugins/org.wso2.carbon.service.mgt.stub_4.x.x.jar to <GREG_HOME>/repository/components/dropins.

4). Download or clone ESB service discovery client project and build it.

5). Copy build jar file into <GREG_HOME>/repository/components/dropins directory.

6). Then open the registry.xml file located in <GREG_HOME>/repository/conf/registry.xml and register service discovery client as a Task. This task should be added under “tasks” element.

<task name="ServiceDiscovery" class="com.chandana.governance.discovery.services.ServiceDiscoveryTask">
            <trigger cron="0/100 * * * * ?"/>
            <property key="userName" value="admin" />
            <property key="password" value="admin" />
            <property key="serverUrl" value="https://localhost:9444/services/"/>
            <property key="version" value="1.0.0" />
        </task>

7). Change the userName, password, serverUrl and defaultVersion according to your setup.

8). Now Start ESB server first and then start the G-Reg server. 

So, you can see “
# of service created :...” message in G-Reg console once server has discovered a service from the ESB server and mean time related WSDL and XSD has got imported into G-Reg. Above services are cataloged under “SOAP Service” asset type.