Social Icons

twitterfacebookgoogle pluslinkedinrss feed

Featured Posts

Saturday, July 11, 2015

Configure External Solr server with Governance Registry

In WSO2 Governance Registry 5.0.0, we have upgraded Apache Solr version into 5.0.0 release. With that you can connect WSO2 Governance Registry into an external Solr server or Solr cluster. External Solr integration provides features to gain comprehensive Administration Interfaces, High scalability and Fault Tolerance, Easy Monitoring and many more Solr capabilities.

Let me explain how you can connect WSO2 Governance Registry server with an external Apache Solr server.

1). First, you have to download Apache Solr 5.x.x from the below location.
http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
Please note that we have only verified with Solr 5.0.0, 5.2.0 and 5.2.1 versions only.

2). Then unzip Solr Zip file. Once unzipped, it's content will look like the below.



The bin folder contains the scripts to start and stop the server. Before starting the Solr server, you have to make sure JAVA_HOME variable is set properly. Apache Solr is shipped with an inbuilt Jetty server.

3). You can start the Solr server by issuing "solr start" command from the bin directory. Once the Solr server is started properly, following message will be displayed in the console. "Started Solr server on port 8983 (pid=5061). Happy searching!"

By default, server starts on port "8983" and you can access the Solr admin console by navigating to "http://localhost:8983/solr/".

4) Next, you have to create a new Solr Core(In Solr Cloud mode this will be called as a Collection) which will be used in the WSO2 Governance Registry. To create a new Core, you have to execute "solr create -c registry-indexing -d basic_configs" command from the Solr bin directory. This will create a new Solr Core named "registry-indexing".



5). After creating "registry-indexing" Solr core, you can see it from the Solr admin console as below.



6). To integrate newly created Solr core with WSO2 Governance Registry, you have to modify registry.xml file located in <greg_home>/repository/conf directory. There you have to add "solrServerUrl" under indexingConfiguration as follows.

    <!-- This defines index cofiguration which is used in meta data search feature of the registry -->
  
    <indexingConfiguration>
        <solrServerUrl>http://localhost:8983/solr/registry-indexing</solrServerUrl> 
        <startingDelayInSeconds>35</startingDelayInSeconds>
        <indexingFrequencyInSeconds>3</indexingFrequencyInSeconds>
        <!--number of resources submit for given indexing thread -->
        <batchSize>50</batchSize>
         <!--number of worker threads for indexing -->
        <indexerPoolSize>50</indexerPoolSize>
        .................................
    </indexingConfiguration>


7). After completing external Solr configurations as above, you have to start the WSO2 Governance Registry server. If you have configured External Solr integration properly, you can notice below log message in the Governace Registry server startup logs(wso2carbon log).

[2015-07-11 12:50:22,306] INFO {org.wso2.carbon.registry.indexing.solr.SolrClient} - Http Sorl server initiated at: http://localhost:8983/solr/registry-indexing

Further, you can view indexed data by querying via Solr admin console as well.

Happy Indexing and Searching...!!!

Note: You can download G-Reg 5.0.0 Alpha pack from : Product-Greg GitHub repo

Thursday, February 19, 2015

Remove duplicate XML elements using XSLT

Today I faced an issue where I am receiving a XML message with duplicate elements. So I wanted to remove those duplicate elements using some condition . For that I came up with a XSLT which does that.

My XML input:

<OurGuestsCollection  xmlns="http://ws.wso2.org/dataservice">
   <OurGuests>
      <id>2</id>
      <firstname>Sample</firstname>
      <lastname>Sample</lastname>
      <email>One</email>
      <reg_date>2015-02-18T13:59:43.000+05:30</reg_date>
   </OurGuests>
   <OurGuests>
      <id>3</id>
      <firstname>Sample1</firstname>
      <lastname>Sample1</lastname>
      <email>One</email>
      <reg_date>2015-02-18T14:13:18.000+05:30</reg_date>
   </OurGuests>
   <OurGuests>
      <id>4</id>
      <firstname>Sample1</firstname>
      <lastname>Sample1</lastname>
      <email>One1</email>
      <reg_date>2015-02-18T14:16:21.000+05:30</reg_date>
   </OurGuests>
</OurGuestsCollection>

XSLT:

<xsl:stylesheet version="2.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output omit-xml-declaration="yes" indent="yes"/>

   <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>
   
   <xsl:template match="m0:OurGuests" xmlns:m0="http://ws.wso2.org/dataservice" >
        <xsl:if test="not(following::m0:OurGuests[m0:firstname=current()/m0:firstname])">
            <xsl:copy>
                <xsl:apply-templates select="@*|node()"/>
            </xsl:copy>
        </xsl:if>  
    </xsl:template>
</xsl:stylesheet>

XML Output :

<OurGuestsCollection xmlns="http://ws.wso2.org/dataservice">
   <OurGuests>
      <id>2</id>
      <firstname>Sample</firstname>
      <lastname>Sample</lastname>
      <email>One</email>
      <reg_date>2015-02-18T13:59:43.000+05:30</reg_date>
   </OurGuests>
 
   <OurGuests>
      <id>4</id>
      <firstname>Sample1</firstname>
      <lastname>Sample1</lastname>
      <email>One1</email>
      <reg_date>2015-02-18T14:16:21.000+05:30</reg_date>
   </OurGuests>
</OurGuestsCollection>

Tuesday, February 10, 2015

Writing a Create API Executor for API.RXT

One of the use cases of the WSO2 Governance Registry is storing metadata information of different artifacts. In an Organization, there can be different metadata of different artifacts such their REST APIs, SOAP Services etc. In such a scenario you can use API and Service RXT which are available in the WSO2 Governance Registry to store metadata information.

With the use of API metadata which is stored in the WSO2 Governance Registry, you can publish APIs into WSO2 API Manager without accessing the web interface of the API Manager. This API creation is handled through lifecycle executor of the WSO2 Governance Registry. Once lifecycle state of the api publisher is reached, the executor will invoke Publisher REST API of the WSO2 API Manager and create the API. "Integrating with WSO2 API Manager" documentation explains about how to create an API using SOAP service meta data information.

If you want to create an API using the REST API metadata information available in the WSO2 Governance Registry, you have to write your own executor to achieve this. So I have written an example Implementation of the lifecycle executor which can used to create API's in the API Manager.

Saturday, January 17, 2015

WSO2 API Manager - Changing the default token expiration time

In WSO2 API Manager, expiration period of all the access tokens is set to 60 minutes (3600 seconds) by default. However, you can modify the default expiration period value using identity.xml file located in <APIM_HOME>/repository/conf/ directory.

In the identity.xml file you can see separate configurations to modify default expirations of User tokens and application access tokens.

ApplicationAccessTokenDefaultValidityPeriod

If you are planning to modify the validity period of appliccation access token, then you have to modify the default value of the <ApplicationAccessTokenDefaultValidityPeriod> element in identity.xml file. Changing the value of <ApplicationAccessTokenDefaultValidityPeriod> will not affect for existing applications which have alreday generated application tokens. So when you regenerate the application token, it will pick the token validity time from the UI. Therefore, for applications which has already generated tokens, token validity period needs to be changed from the UI as well. However, when you are creating a new application or when you generating the token for the first time, it will pick the token validity period from the identity.xml file.

UserAccessTokenDefaultValidityPeriod

If you are planning to modify the validity period of user token, then you need to update value of the <UserAccessTokenDefaultValidityPeriod> element in identity.xml file. The User token validity period will get updated when user generating and refreshing the token.