11 min read

(Read more interesting articles on Liferay Portal 6 here.)

Federated search

Federated search is the simultaneous searching of multiple online databases or web resources, and it is an emerging feature of automated, web-based library, and information retrieval systems. Here, federated search refers to the portal. It is very useful to provide federated search abilities, such as searches for blog entries, users, organizations, Calendar entries, Bookmarks entries, Document Library documents, Image Gallery images, Message Boards messages, Wiki articles, Web Content articles, Directory, and so on. The portal provides a set of search portlets. In this section, we’re going to take an in-depth look at these portlets.

The Search portlet

The Search portlet (portlet ID 3) is a JSR-286-compliant portlet that can be used for federated search. By default, the portal itself is the search provider. As shown in following screenshot, Search Portlet provides a federated search against Blogs entries, users, organizations, Calendar entries, Bookmarks entries, Document Library documents, Image Gallery images, Message Boards message, Wiki articles, Web Content articles, Directory, and so on. In addition, the Search Portlet provides a federated search against plugin portlets like the Alfresco Content portlet.

Liferay Portal 6: Employ federated search, OpenSearch, CSZ search, maps search and web Content search

The following is an example of how to use the Search portlet:

  • Add the Search portlet to the page Home of the community Guest where you want to carry out a search, if the Search portlet isn’t already present
  • Enter the search criterion, for example My
  • Click on the Search icon

Note that when searching for assets, you will have the ability to specify the scope of the search results: Everything or This Community. Everything would generate search results that will come from any group in the current portal instance such as communities, organizations, and my community. This Community will generate search results that come from the current group in the portal instance such as community Guest, organization “Palm Tree Enterprise”, and My Community.

The search results would cover Blogs entries, users, organizations, Calendar entries, Bookmarks entries, Document Library documents, Image Gallery images, Message Boards messages, Wiki articles, Web Content articles, Directory, and so on. Additionally, search results will include assets from plugin portlets like Alfresco Content portlet.

As you can see, search results would be displayed as a title with a link. If you have the proper permission on an asset, you could click on the title of the asset (which is a link to it) and view the asset as well. But if you don’t have proper permission on an asset, clicking on the title would bring up a the permission error message.

What’s happening?

The portal provides many portlets to support OpenSearch framework such as Message Boards, Blogs, Wikis, Directory and Document Library, Users, Organizations, and so on. In addition, plugins like the Alfresco Content portlet also supports the OpenSearch framework. Normally, these portlets have the following OpenSearch framework configuration.

 <open-search-class>class-name </open-search-class>

The Search portlet obtains an OpenSearch instance from each portlet that has the tag &ltopen-search-class> definition. For example, the portlet Directory (portlet ID 11) allows users to search for other users, organizations, or user groups. OpenSearch has been specified for the portlet Directory in $PORTAL_ROOT_HOME/WEB-INF/liferayportlet. xml as follows:

 <open-search-class>
com.liferay.portlet.directory.util.DirectoryOpenSearchImpl
</open-search-class>

As shown in the preceding code, the open-search-class value must be a class that implements com.liferay.portal.kernel.search.OpenSearch, which is called to get search results in the OpenSearch standard.Besides the OpenSearch framework, the portal provides UI taglib to display search results. In$PORTAL_ROOT_HOME/html/portlet/search/view.jsp, you could find the following code.

<liferay-ui:search />

For more details on UI taglib <liferay-ui:search>, you would check JSP files start.jsp and end.jsp under the folder $PORTAL_ROOT_HOME/html/taglib/ui/ search. In addition, the portal scopes OpenSearch results through the UI taglib <liferay-ui:search>. For example, the scope of search results, namely, Everything or This Community has been specified in $PORTAL_ROOT_HOME/html/taglib/ui/search/start.jsp as follows:

<select name="<%= namespace %>groupId">
<!-ignore details -->
<option value="<%= group.getGroupId() %>" <%= (groupId != 0) ?
"selected" : "" %>><liferay-ui:message key='<%= "this-" +
(group.isOrganization() ? "organization" : "community") %>' />
</option>
</select>

As you can see, the value of This Community would be an organization or community. By default, the OpenSearch implementation in the portal supports both formats: ATOM and RSS. The default format would be ATOM. Therefore, the search results from plugin portlets must be returned in the format ATOM. For example, in the portlet Alfresco Content, the format of search results must be ATOM. Why? The portlet Search has specified the following code in $PORTAL_ROOT_HOME/html/ portlet/search/open_search_description.jsp.

<OpenSearchDescription >
<!-ignore details --><Url type="application/rss+xml" template="<%=
themeDisplay.getPortalURL() %><%= PortalUtil.getPathMain() %>/
search/open_search?keywords={searchTerms}&amp p={startPage?}&amp
c={count?}&amp format=rss" />
</OpenSearchDescription>

In addition, search results are displayed in pagination through the search container. Fortunately, search container is configurable. The portal has specified the following properties in portal.properties.

search.container.page.delta.values=5,10,20,30,50,75
search.container.page.iterator.max.pages=25

As shown in the preceding code, the property search.container.page.delta. values sets the available values for the number of entries to be displayed per page. An empty value, or commenting out the value, will disable delta resizing. The default of 20 will apply in all cases. Note that you need to always include 20 because it is the default page size when no delta is specified. The absolute maximum allowed delta value is 200. The property search.container.page.iterator.max.pages sets the maximum number of pages, which are available before and / or after the currently displayed page. Of course, you could override these properties anytime in portal-ext.properties.

Configuration

As mentioned previously, OpenSearch in the Search portlet covers the in-and-out of Blogs, Calendar, Bookmarks, Document Library, Image Gallery, Message Boards, Wiki, Web Content, Directory, and so on. Fortunately, the portal adds the ability to remove these portlets from the list of portlets searched by the portlet Search as follows:

com.liferay.portlet.blogs.util.BlogsOpenSearchImpl=true
## ignore details
com.liferay.portlet.wiki.util.WikiOpenSearchImpl=true

As shown in the preceding code, you can set any of these properties to false to disable the portlet from being searched by the Search portlet in portal-ext.properties.

Customization

In real cases, you may be required to use the portlet Search in different ways. You would be able to customize the portlet Search. Here we’re going to discuss how to use the Search portlet in Social Office and how to use the Search portlet in themes. The Social Office overrides the UI taglib <liferay-ui:search> in the portlet soportlet through JSP file hooks in $AS_WEB_APP_HOME/so-portlet/META-INF/ custom_jsps/html/taglib/ui/search/start.jsp as follows:

<liferay-util:include page="/html/taglib/ui/search/start.portal.jsp"
/>
<c:if test="<%= group.isUser() %>">
<script type="text/javascript">
var searchOptions = jQuery('select[name=<%= namespace %>
groupId] option')
searchOptions.each( //ignore details )
</script>
</c:if>

As shown in the preceding code, the Social Office overrides the look and feel of the portlet Search. For example, it will remove search options.

Of course, you can add the portlet Search as a runtime portlet in themes. You could add the Velocity template $theme.search() in the theme, specifically in the VM file portal_normal.vm or the VM file included in portal_normal.vm. For example,Social Office specified the following lines in the theme so-theme such as $AS_WEB_ APP_HOME/so-theme/templates/navigation_top.vm.

#if ($is_signed_in)
<div class="my-search">$theme.search()</div>
#end

As shown in the preceding code, when the user signs in, the Social Office will show the customized portlet Search in “my-search” style.

OpenSearch in plugins

In general, the portal provides an OpenSearch framework, so that a user can create an OpenSearch implementation in the plugin environment. The portal will try to call this OpenSearch implementation when you hit the Search portlet. The Search portlet goes through all registered implementations and tries to create an instance.

We could search content from the Alfresco repository, just as we did for Blogs, Bookmarks, Calendar, Directory, and so on via the OpenSearch framework of the portlet Search. How does it work?

How does it work?

First of all, we need to install the Alfresco Web Client, and then we need to deploy the portlet Alfresco Content. By following these three steps, you would bring the Alfresco Web Client into Tomcat as well:

  1. Download the latest Alfresco-Tomcat bundle from http://www.alfresco.com, and install it to the folder $ALFRESCO_HOME.
  2. Locate the Alfresco Web Client application alfresco.war under the folder $ALFRESCO_HOME, and drop it to the folder $TOMCAT_AS_DIR/webapps.
  3. Create a database alfresco in MySQL and restart Tomcat.
drop database if exists alfresco
create database alfresco character set utf8
grant all on alfresco.* to 'alfresco'@'localhost' identified by
'alfresco' with grant option
grant all on alfresco.* to 'alfresco'@'localhost.localdomain'
identified by 'alfresco' with grant option

Then we could deploy the plugin Alfresco Content portlet. The following is example of how to bring the portlet Alfresco Content into the portal.

  1. Download the WAR file ${alfresco.content.portlet.war} from http:// liferay.cignex.com/palm_tree/book/0387/chapter12/netvibeswidget- portlet-6.0.0.1.war.
  2. Drop the WAR file ${alfresco.content.portlet.war} to the folder$LIFERAY_HOME/deploy when the portal is running.

That’s it! When you search for content again in the portlet Search, you will be able to see assets coming from the Alfresco Web Client. In addition, you would see a message like “Searched Alfresco Content, Blogs …” in the portlet Search.

Web services

As you can see, the Alfresco Content plugin displays content from the Alfresco repository. Two kinds of services are involved—web services and RESTful services. A web service is a software system designed to support interoperable machine-tomachine interaction over a network. With the portlet Alfresco Content, you could search or navigate content of the Alfresco repository via web services.

You have to simply go to More | Configuration | Setup | Current of the portlet Alfresco Content first. Then you should enter a User ID like “admin” and a password like “admin”, and click on the Save button. Now, you will be able to see the root folder “Company Home”.

The following property is specified in the portlet Alfresco Content:

$AS_WEB_APP_HOME/alfresco-content-portlet/WEB-INF/classes/portlet.
properties
content.server.url=http://localhost:8080

As shown in the preceding code, the property content.server.url sets the location of the Alfresco server URL.

RESTful services

Representational State Transfer (REST) is a style of software architecture for distributed hypermedia systems. Alfresco not only provides the ability to expose its search engines via OpenSearch, but it also provides an aggregate OpenSearch feature in the Alfresco Web Client through RESTful services. To summarize, Alfresco RESTful services-based keyword search mimics the keyword search of the Alfresco Web Client.

The following search URL template is used for OpenSearch in the plugin Alfresco Content.

http://<host>:<port>/alfresco/service/api/search/keyword.atom?q={searc
hTerms}&p={startPage?}&c={count?}&l={language?}

In the preceding code, the URL will have the following values:

  • searchTerms: The keyword or keywords to search
  • startPage (optional): The page number of search results desired by the client
  • count (optional): The number of search results per page (the default is 10)
  • language (optional): The locale to search with (XML 1.0 Language ID, for example en-GB)

Besides RESTful APIs for OpenSearch, Alfresco provides the following RESTful APIs built as Web Scripts:

  • Repository API Reference: Remote services for interacting with the Alfresco Repository
  • CMIS API Reference: Content Management Interoperability Services
  • Portlets such as My Inbox and My Checked-Out for hosting in any portal
  • Office Integration for hosting in Microsoft Office

Moreover, in order to allow the Alfresco Content portlet to support OpenSearch, the portlet has set the value open-search-class at $AS_WEB_APP_HOME/alfrescocontent-portlet/WEB-INF/liferay-portlet.xml as follows:

<open-search-class>
com.liferay.portlet.alfrescocontent.util.AlfrescoOpenSearchImpl
</open-search-class>

Finally, the portlet has set the following values in $AS_WEB_APP_HOME/alfrescocontent-portlet/WEB-INF/classes/portlet.properties, which will be used to query Alfresco via OpenSearch.

open.search.enabled=true
## ignore details open.search.path=/alfresco/service/api/search/
keyword.atom

Of course, you could override the preceding properties according to your own environment’s, for example, server domain name, port number, search user name, search password, and so on.

CMIS

Besides web services and OpenSearch, Alfresco supports CMIS as well. Content Management Interoperability Services (CMIS) is a specification that defines how Enterprise Content Management (ECM) systems exchange content, defining a domain model and set of bindings, such as Web Service and RESTful Atom-Pub that can be used by applications to work with one or more content management repositories. Alfresco supports the CMIS REST API Binding, the CMIS web services API Binding, and Web Service WSDL.

The portal has specified the following properties for CMIS in portal.properties:

cmis.credentials.username=none
mis.credentials.password=none
cmis.repository.url=http://localhost:8080/alfresco/service/api/cmis
cmis.repository.version=1.0
cmis.system.root.dir=Liferay Home

As mentioned earlier, we could use CMIS hook to configure a repository. In addition, we could use these properties in the Alfresco Content portlet and provide OpenSearch capabilities based on CMIS.

Packt

LEAVE A REPLY

Please enter your comment!
Please enter your name here